Database Info

[GUIDE] Proxyme - Android System Access Tool

The purpose of this thread is to provide a guide for users who have Proxyme preloaded in their device's firmware and want to find out how to use it effectively. Ideally, this will be a place to share experiences and ideas to further improve the tool and provide solutions to problems that people may have.
Introduction
Proxyme ( proc-zahym ) represents a system access solution comprised of the following components:
System service - provides access to privileged system environment
SSH daemon - provides secure shell (ssh) and file (scp) access (based on dropbear)
proxyme.apk - user interface module
This solution is offered as a preloaded option in firmware images and consequently cannot (should not) be installed as a regular app, either from the Play Store or being side loaded. The reason for pre-loading stems from the requirements of the system service component to be able to integrate at system level and not be bound by operating restrictions within the Android application and framework platform environment (Zygote and Dalvik sandbox). The Play Store has been enlisted as the primary and preferred source in providing updates to the user interface component; the actual app you will be interacting with.
Proxyme offers the following functionality through its user interface:
Installation/de-installation of the su binary to provide/remove root access
(useful only for other applications which require root level access)
The persistent behaviour of the su binary can be controlled by a one-shot switch
Register/de-register tag-along scripts for su enable and disable actions
(more details on this below)
Control availability and location of busybox toolbox
Start/Stop SSH daemon
Configure listening port for the SSH daemon
Configure user accounts for the SSH daemon
Submit and execute a shell script
SU Binary
The option to enable or disable the su binary switch (on/off) in the user interface is the equivalent of rooting and unrooting the device. When enabled, you are providing root access to apps which require it to perform correctly. Currently, Proxyme does not have built-in support for monitoring and 'policing' the actual access to root.
Auto Root @ Boot
This switch in the Proxyme app allows you to indicate whether the su binary should be installed or removed during a reboot or startup of the device. Setting it to the 'on' position will make the su binary persistent throughout reboot cycles and leave your phone permanently 'rooted'.
Registering Tag-along Scripts
Whenever you enable or disable the su binary with the on/off switch in the user interface, there exists an option to execute a user script just prior to and one unique to each action. This is possible by pre-registering a script for one of or both enable/disable actions. A script can virtually perform anything and is always executed within root context. Note that you must be very cautious about the scripts you are registering and be certain about their intentions, because a rogue script could cause irreparable damage to you device.
Each script has the option to override, and thus block, the intended action (enable or disable) by setting a system property named proxyme.override to anything but blank.
One purpose of having tag-along scripts would be to 'freeze' and 'unfreeze' specific root-shy apps, which do not 'like' rooted systems. This is one area where we can share the experience of pre-coded scripts for certain target apps and I do hope it will be put to good use.
To submit a script file, tap on one of the SU Enable Script or SU Disable Script text elements to start browsing for a file.
Busybox
Busybox is just that, busybox. Options are available to determine one of two hard-configured locations where it can be installed and to enable or disable it.
More to follow later...
SSH Daemon
The SSH daemon is based on dropbear. It has been modified to support logon accounts in Android, which are configured with the following parameters:
username
password
home directory
which shell to use
user ID
group ID
For whatever reasons, you can restrict access by specifying non-root user and group (0:0) IDs. The IDs you can choose from are derived from a system list which was used and known within Android at the moment of booting the device. If you have installed new apps in the meantime and would like to use their newly assigned IDs, then please reboot the phone to update this list.
Executing Shell Scripts
The ability to submit and execute a shell script from the user interface can be considered a convenient and quick way to get some tasks done. Take note however that your scripts are run in a privileged environment under the root account and that there are risks involved. A rogue or insufficiently tested script can cause major problems if/when it makes changes to key system partitions, which are normally mounted read only for obvious reasons.
Most rom images will include a sample de-bloating script,which removes ROM specific branding apps. The script. /sdcard/Proxyme/debloat.sh, shows how this is done and could serve as a base for more extensive clean-up of firmware components, if you so desire.
Operational Notes
Whenever a device boots from a factory reset condition (i.e. after wiping data), there will be no UID/GID list available in the user management screen. The reason for this is that the SuMeD setup process will complete before the app data store, the location where aforementioned list is stored. has been initialised. Restart the device in order to make this list available.
Behind The Scenes
For details regarding how Proxyme's system service components are integrated in a firmware image, please follow this trail...
Device Support
Before taking the next step to flash your phone/device, please be aware of the risks involved with performing such an operation. Prepare the device properly, i.e. sufficient battery charge, and be well informed of the correct flashing procedure(s) for your device's make and model. On Samsung devices, rooting will probably trigger 'custom' flag(s) and consequently render the warranty void. No matter how adventurous you may feel, it is always a bad idea to try to flash a firmware image which is not intended for your device. Having said all that, note that you will be flashing your phone at your own risk. You are solely responsible for anything you do to your phone/device, so make sure you are well informed and well prepared before deciding to flash or install anything on it.
The following list will be updated as soon as new firmware images are prepared for new and old devices.
Samsung Galaxy Note 10.1 2014
SM-P600 - (reference post)
Samsung Galaxy J
SC-02F (Docomo) - (reference thread)
SGH-N075T (Taiwan) - (reference thread)
Samsung Note 3
SM-N9005 - (reference post)
SM-N900A - (reference post - unconfirmed)
Samsung Galaxy S4
SHV-E330K - (reference thread)
SHV-E330L - (reference thread)
SHV-E330S - (reference thread)
SGH-I337 - (reference post - unconfirmed)
SC-04E - (reference post)
Samsung Galaxy Grand 2
SM-G710L - (reference post)
Samsung Galaxy S3
GT-I9300 - (reference post)
SC-03E - (reference thread)
SHV-E210K - (reference thread)
SHV-E210L - (reference thread)
SHV-E210S - (reference post)
SHW-M440S - (reference post)
Samsung Galaxy S2 LTE
SHV-E110S - (reference thread)
Samsung Galaxy S2
SHW-M250K - (reference post)
Planned Changes
built-in control of su access (much like what Superuser currently does)
choice of built-in simple file browser or use intents to initiate external app(s) for browsing and selecting files
...

Proxyme - Behind The Scenes
This section details how Proxyme's system service components are integrated in a firmware image.
If you are not up to speed with how a typical Android system is constructed, then I would like to suggest you at least make yourself familiar with this topic in order to fully understand what to do with the following text.
The system service components are integrated in the /system partition (mount point) in Android. In the case of changing a live system this will require mounting the appropriate partition read/write before applying the updates. If a static firmware image is to be updated, then extract the component which represents the /system partition from the package and apply the updates before re-packing the firmware image.
The following list describes the major system service components:
hijacker - this is a module you need to write, which has the role of initiating the system service in a privileged environment.
hjprepper - this module is started by the hijacker to prepare the environment prior to starting SuMeD
SuMeD - this one is what it's all about. The Proxyme app relies on this daemon to be up and running in order to perform any of its privileged functions
SSHD - the SSH daemon is represented by an updated implementation of dropbear on Android
Hijacker
The hijacker is a program you would normally have to write to replace an existing program in your rom, which is started during the boot process by for example initd. This part of the integration process requires your (creative) input, since you need to analyse the rom you are working on and figure out how and where to position the hijacker module. If you do find an existing module to hijack, make sure to always call that original module from your hijacker once it has managed to execute the hjprepper program. In some roms it suffices to start hjprepper from a shell script, which is run with root access... they exist, you just have to look for them.
This is what your hijacker could look like in C
Code:
#define PROP_HIJACK "proxyme.hijack.system"
#define HIJACKEE "/system/bin/original-program"
#define PREPPER "/system/xbin/hjprepper"
int main( int argc, char *argv[] )
{
char *lArgv[5];
char **lArgList;
int lArgCnt;
pid_t pid;
lArgList = (char **)malloc( sizeof(void *) * (argc + 1) );
for ( lArgCnt = 0; lArgCnt < argc; lArgCnt++ )
{
lArgList[ lArgCnt ] = argv[ lArgCnt ];
}
lArgList[ lArgCnt ] = NULL;
/* Fork parent process */
pid = fork();
if ( pid < 0 )
{
property_set( PROP_HIJACK, (char *)"Hijacker Startup... spawning failed, prep first before xfer" );
system( "/system/xbin/hjprepper" );
execv( HIJACKEE, lArgv );
exit( EXIT_SUCCESS );
}
else if ( pid > 0 )
{
property_set( PROP_HIJACK, (char *)"Hijacker startup... spawned, parent ascends phase 2" );
execv( HIJACKEE, lArgv );
exit( EXIT_SUCCESS );
}
if ( execl(PREPPER, PREPPER, (char *)NULL) < 0 )
{
property_set( PROP_HIJACK, (char *)"Hijacker startup... failed to call prepper" );
}
exit( EXIT_SUCCESS );
}
hjprepper
This program is responsible for setting up an operating environment for the SuMeD daemon. If you have full control over a rom's boot image, then include a call in your init process to start this module once during boot. If not, then use a hijacker program or look for existing and suitable scripts to initiate hjprepper.
hjprepper starts the SuMeD daemon once it completes the setup and configuration procedure.
SuMeD
This bad boy is responsible for the user requested actions through interaction with the Proxyme app.
Prebuilt Packages
To get you started, there are pre-built modules available,which you can download here. Currently, availability is limited to Android 4.3 and 4.4.2 only. The following zip archives are organized in a folder tree structure,which serves as a guide for where to place the modules within the /system path.
4.3 Prebuilts
4.4.2 Prebuilts

Filler 2
Filler 2

Filler 3
Filler 3

Please add support in latest SHV-E110S 4.1.2 rom(s)
Title says/asks it all...

Can You guide build pre-rooted rom by proxyme? Thank you very much.

linhbs said:
Can You guide build pre-rooted rom by proxyme? Thank you very much.
Click to expand...
Click to collapse
Behind The Scenes section has been added to the OP.

Can this method be used to prebuilts S3, S4, Note3 not Korea? Thanks so much.

linhbs said:
Can this method be used to prebuilts S3, S4, Note3 not Korea? Thanks so much.
Click to expand...
Click to collapse
Yes. You need to figure out how to get the SuMeD daemon started and that depends on the rom you want to integrate it in. The Behind The Scenes post highlights what areas to focus on when doing this.
Note that the first post includes 2 firmware images (both Android 4.3 and 4.4.2) for the international Note3 (SM-N9005). It's a no-brainer to copy the files from the appropriate directories to an equivalent and same level version firmware for another region of the same device.

Please add support N900A 4.4.2. Thank you very much.

linhbs said:
Please add support N900A 4.4.2. Thank you very much.
Click to expand...
Click to collapse
Has 4.4.2 been released on that device? If yes, a download link for the official stock firmware will help speed up the process. If not, then we wait or you could send a PM to davidcsv with the 10 or 11 digit s/n and he will monitor and download the latest release as soon as it becomes available...after that your new firmware image will be uploaded within a day.

Link: http://www.androidfilehost.com/?fid=23321874045862490. Thank you for your interest!

linhbs said:
Link: http://www.androidfilehost.com/?fid=23321874045862490. Thank you for your interest!
Click to expand...
Click to collapse
N900AUCECMLG (preloaded with Proxyme) (2014-01-04)
This rom implicitly performs a factory reset, so backup your data before flashing it. Unpack the zip archive and specify the resulting .tar.md5 filename in the PDA/AP section of the latest version of Odin.
Use Proxyme to execute the /sdcard/Proxyme/debloat.sh script to get rid of the k n o x messages.
mega.co.nz
torrent, mirror
Apparently, this firmware image is a pre-release/leaked image and not the final deal. It includes an updated bootloader and related components, meaning that it will not be straightforward to revert back to an older version of the firmware. If you encounter problems with this Proxyme preloaded image, then I'd suggest flashing the image from the original download link.
All feedback is welcome and will be appreciated. Enjoy!

Thank you very much. I ask you to add proxyme in I337 4.4.2 rom. Thank you very much.
Link: http://www.androidfilehost.com/?fid=23329332407566813

linhbs said:
Thank you very much. I ask you to add proxyme in I337 4.4.2 rom. Thank you very much.
Link: http://www.androidfilehost.com/?fid=23329332407566813
Click to expand...
Click to collapse
I337UCUFMLD (preloaded with Proxyme) (2014-01-02)
This rom implicitly performs a factory reset, so backup your data before flashing it. Unpack the zip archive and specify the resulting .tar.md5 filename in the PDA/AP section of the latest version of Odin.
Use Proxyme to execute the /sdcard/Proxyme/debloat.sh script to get rid of the k n o x messages.
mega.co.nz
torrent, mirror
Apparently, this firmware image is also a pre-release/leaked image and not the final deal. It too includes an updated bootloader and related components, meaning that it will not be straightforward to revert back to an older version of the firmware. If you encounter problems with this Proxyme preloaded image, then I'd suggest flashing the image from the original download link. A Google search shows that this image does have a few minor issues, so beware.
All feedback is welcome and will be appreciated. Enjoy!

Thank so much. I find the phone test. Will respond to you.

SC-04E Stock Firmware Proxyme Rooter images
Root Ready Stock Images
(Unfortunately, flashing these ROMs will trigger KNOX)
Kitkat 4.4
SC04EOMUFNI3 (Proxyme) (Build Date 2014-09-19)
This zip archive contains an Odin flashable file. It is not the complete stock image, so you MUST have OMUFNI3 already running on your phone or you will need to download it from the above reference sites, which carry complete stock firmware images, and flash it before continuing with this file. Instructions are included in the zip archive.
uploaded.net
mediafire
torrent, mirror2

I337:
- Before flash rom: I337UCUEMK2 version 4.3
- After flash rom I337UCUFMLD (preloaded with Proxyme) fail.

Good.

linhbs said:
I337:
- Before flash rom: I337UCUEMK2 version 4.3
- After flash rom I337UCUFMLD (preloaded with Proxyme) fail.
Click to expand...
Click to collapse
Please post the complete log from the message box in Odin. One more question, is your phone 16GB or 32GB model?
update: and also try again with newer version of Odin v3.09 instead of v3.07

[ROM][UNOFFICIAL] LineageOS 17.1 for Unihertz Atom L (20200828)

Introduction
This thread contains the LineageOS 17.1 custom firmware images for the Unihertz Atom L, a rugged Android phone released by Unihertz in July 2020, and the accompanying LineageOS Recovery used for flashing the firmware.
Please note that this ROM is one of my side projects, for which I could provide zero warranty. By installing this ROM, you acknowledge that you take all the risks that come with installing custom firmwares on your devices, including but not limited to bricking your device, losing your data, etc. You are always suggested to keep backups and make sure you know how to flash back to official ROM before trying any custom ROMs.
Please find the download links in the Download section. The following sections are guides to installing the ROM.
WARNING: DO NOT try to install this on Atom XL. This is ONLY for the Atom L.
Working Features
- All basic features (Telephony, VoLTE, Audio, Camera, NFC, WiFi, Bluetooth, ....)
- Programmable PTT (red) button (Functionality can be set in Settings - System - Buttons, under the "Search Button" section)
- 48MP camera seems to be working (unlike on many other super resolution devices)
Known Issues
- VoLTE is working (at least for me) but sometimes quirky. If you find it somehow stopped working, usually turning it off and back on again (in Settings - Network - Mobile Network) will fix it. Putting the device to SELinux Permissive mode also fixes most of the VoLTE quirks but this is not recommended (a few quirks in Enforcing mode is better than having the whole device Permissive)
Unlocking
1. Boot your Atom L to the official OS
2. Go into Settings - About phone, tap "build number" several times to enable developer settings
3. Go to Settings - System - Developer Settings, enable OEM unlocking and ADB debugging
4. Run `adb reboot bootloader` on your PC (there is no way to enter bootloader directly, only possible through adb)
5. Run `adb flashing unlock` and comfirm unlock on device (THIS WILL WIPE ALL DATA)
6. Reboot and now you should see an unlocked warning during boot screen.
Installing LineageOS Recovery
For now the only working recovery is the LineageOS Recovery, because the device's kernel does not load the touch driver in recovery mode for whatever reason, rendering TWRP useless.
1. Download `lineage_recovery_XXX.img` and `vbmeta.zip`, unpack `vbmeta.zip` to get three .img files starting with `vbmeta`
2. Run `adb reboot bootloader` to put your device in bootloader mode
3. Run `fastboot flash --disable-verification --disable-verity vbmeta vbmeta.img`
4. Run `fastboot flash --disable-verification --disable-verity vbmeta_system vbmeta_system.img`
5. Run `fastboot flash --disable-verification --disable-verity vbmeta_vendor vbmeta_vendor.img`
6. Run `fastboot flash recovery lineage_recovery_XXX.img`
7. Run `fastboot reboot recovery` to reboot into the newly-installed LineageOS Recovery
The LineageOS Recovery is operated by volume keys as selection and power as confirmation (or entering sub-menus). To return to upper levels of menus from sub-menus, press volume up until the selection goes to the first item and then disappears, then press power (i.e. there's a hidden "Go Back" item at the very top of each sub-menu).
The recovery will show a verification failed prompt for most packages that are not signed with the AOSP keys. This is safe to ignore.
Installing LineageOS 17.1
The LineageOS image must be installed via LineageOS recovery.
1. Download `lineage-17.1-Atom_L-XXX.zip`
2. Reboot your device into recovery (`adb reboot recovery` or simply hold volume up while turning power on)
3. Wipe all data (factory reset) (THIS DELETES EVEN INTERNAL STORAGE)
4. Choose Apply Update, then Apply Update from ADB
5. Run `adb sideload lineage-17.1-Atom_L-XXX.zip` from your PC
6. Wait for the process to finish. (The recovery might prompt something about verification failure, just ignore it and continue anyway)
7. At this point, you can then sideload the LATEST Magisk and OpenGAPPS Nano at your will (note that the size of the system partition might only be enough for the `nano` variant of OpenGAPPS) (If installing Magisk / OpenGAPPS fails, you can try rebooting into recovery again in advanced menus, then try installing them again)
8. Reboot into system and enjoy (Note that Magisk might cause your device to boot loop once or two but it will eventually boot)
When updating to a newer build, you have to flash the new zip, and then re-flash whatever mod you have installed previously (Magisk / GAPPS).
Download Links
LineageOS:
lineage-17.1-Atom_L-20200828-peter-signed.zip: https://mega.nz/file/bAgh1BZA#jzMs_0e9NUR9NcALXWp51ZeWttM5rl_3K5T8Or9hAW0
- Synchronized updates from LineageOS upstream.
lineage-17.1-Atom_L-20200728-peter-signed.zip: https://mega.nz/file/vBwlmL5D#wpw8RovBHyVFCLFlhQ2H5QAIb0ECXkT4of0FRijiP6A
LineageOS Recovery:
lineage_recovery_20200728.img: https://mega.nz/file/yc4Dnbyb#yx0Ci9p3q9_lfAiXkGfgWDFnRJI-JSGrv3kyawkU3fw
vbmeta:
vbmeta.zip: https://mega.nz/file/nF51mBoY#ZNY4j92wc_6a1dXch3l5r-w4VFl9QjN7YJaRMKRoEGk
XDA:DevDB Information
LineageOS 17.1 for Unihertz Atom L, ROM for the Android General
Contributors
PeterCxy
Source Code: https://cgit.typeblog.net/android/device/unihertz/Atom_L/
ROM OS Version: Android 10
Version Information
Status: Alpha
Created 2020-07-28
Last Updated 2020-07-28

How different is the Atom XL?
PeterCxy said:
Introduction
WARNING: DO NOT try to install this on Atom XL. This is ONLY for the Atom L.
Unfortunately I've got the XL version which I thought only varied from the L by the presence of a UHF radio! Can you explain to me why its not a suitable candidate for your mods which sound very good!?
And before you ask, I only got this radio for hacking so I don't mind experimenting if that is required. Please let me know if I can help.
The Bitfarmer
Click to expand...
Click to collapse

tvroman said:
PeterCxy said:
Introduction
WARNING: DO NOT try to install this on Atom XL. This is ONLY for the Atom L.
Unfortunately I've got the XL version which I thought only varied from the L by the presence of a UHF radio! Can you explain to me why its not a suitable candidate for your mods which sound very good!?
And before you ask, I only got this radio for hacking so I don't mind experimenting if that is required. Please let me know if I can help.
The Bitfarmer
Click to expand...
Click to collapse
Because Unihertz publishes completely different firmware files for the L and XL, so the safest assumption is that there is more difference than just the UHF radio. If you want to risk it, then you CAN try using this ROM on the XL, as long as you know how to revert back to official if things go wrong. (But I cannot guarantee if the kernel image from L that this ROM uses will not cause serious issues like corrupted baseband or something on the XL)
My suggestion is that instead of trying this ROM directly on the XL, someone with XL can try to modify my device tree for L, replacing the kernel, dtbo images and other vendor blobs from the ones from XL, and then re-compile the ROM for XL. This would be the proper way to handle these two devices.
Click to expand...
Click to collapse

Going XL
Hi.
Great work. :good:
I want to built a ROM for the Atom XL myself. And because I'm no expert on this (for now) I'm in search of guides and hints on how to achieve my goal.
As far as I know the biggest problem with Unihertz is that they use a Mediatek chipset with which they are not allowed to provide the sourcecode of the kernel. Or at least you have to pay for it from Mediatek.
But there are some variants of the chipset (Helio P60; mt6771) used in other mobile phones (e.g. Nokia X5) for which I was able to find kernelsources on Github. Using these and the latest Android kernel from google I tried to compile a kernel as a starting point. I was able to extract the build.config directly from the phone which helped tremendously. This should at least get me to the point where I'm able to assemble a TWRP build. But I believe that I'm still missing some (vital?) drivers which are specific to the actual device. This includes I think the missing touchscreen driver that you mentioned is preventing the recovery to be useful.
So now I'm a little bit stuck, because most of the guides to arrange a LineageOS (or any other custom ROM) build tree I found require the sourcecode from the manufacturer which we don't have. All other guides to build from scratch were too generic for my current level of expertise.
Can you please share your approach to create this build?
If you don't want to do this in the open you could also PM me.
With kind regards
ADT

a-dead-trousers said:
Hi.
Great work. :good:
I want to built a ROM for the Atom XL myself. And because I'm no expert on this (for now) I'm in search of guides and hints on how to achieve my goal.
As far as I know the biggest problem with Unihertz is that they use a Mediatek chipset with which they are not allowed to provide the sourcecode of the kernel. Or at least you have to pay for it from Mediatek.
But there are some variants of the chipset (Helio P60; mt6771) used in other mobile phones (e.g. Nokia X5) for which I was able to find kernelsources on Github. Using these and the latest Android kernel from google I tried to compile a kernel as a starting point. I was able to extract the build.config directly from the phone which helped tremendously. This should at least get me to the point where I'm able to assemble a TWRP build. But I believe that I'm still missing some (vital?) drivers which are specific to the actual device. This includes I think the missing touchscreen driver that you mentioned is preventing the recovery to be useful.
So now I'm a little bit stuck, because most of the guides to arrange a LineageOS (or any other custom ROM) build tree I found require the sourcecode from the manufacturer which we don't have. All other guides to build from scratch were too generic for my current level of expertise.
Can you please share your approach to create this build?
If you don't want to do this in the open you could also PM me.
With kind regards
ADT
Click to expand...
Click to collapse
You don't need the kernel source code to build a working ROM -- just look at my device tree for Atom L. I think you can build a working ROM for the XL by just replacing the prebuilt kernel in my device tree with the one from Atom XL and also re-extracting the vendor blobs from XL using the script in my devcie tree, then rename everything to Atom XL instead of L. I don't know if the integrated amateur radio would still work though.

PeterCxy said:
You don't need the kernel source code to build a working ROM -- just look at my device tree for Atom L. I think you can build a working ROM for the XL by just replacing the prebuilt kernel in my device tree with the one from Atom XL and also re-extracting the vendor blobs from XL using the script in my devcie tree, then rename everything to Atom XL instead of L. I don't know if the integrated amateur radio would still work though.
Click to expand...
Click to collapse
I'm already on to that.
But I seem to have trouble extracting the prebuilt kernel. None of the tools I found gave me the exact files you have got (dtb.img, dtbo.img, Image.gz). What did you use?
The best I could get were "dtb", "kernel" and "dtborecovery" (without extensions) which roughly had the same size as yours.
Also, as far as I understand it, with your initial commit (without the modifications for Lineage itself) I should be able to at least compile a recovery image but I got an error regarding a missing dtb.img file in the "out" directory.
Something seems to be missing because, my dtb file is in the "device" directory and not being transfered into "out" during building.
I'm not sure that is because I have got a different naming scheme (renamig it didn't help) or I did something wrong with the extraction.
---------- Post added at 07:30 ---------- Previous post was at 07:14 ----------
Another question I have:
Are the vbmeta-files you used to flash the recovery the ones from the original firmeware zip from unihertz or did you get them from the lineage built?
And reguarding the rather smallish system partition:
I have an idea to bypass that by using the SPFlash Tool from Mediatek. As far as I understand the settings in the scatter-file this tool does a repartitioning of the internal storage. So we only need to "decrease" the userdata, "move" some partitions inbetween and "increase" the system. Only problem is, I couldn't find a partition designated as "system" in the scatter-file, only one big "super" and a "vbmeta-system" (which for my understaning is for verified boot) partition.
What do you think?

a-dead-trousers said:
I'm already on to that.
But I seem to have trouble extracting the prebuilt kernel. None of the tools I found gave me the exact files you have got (dtb.img, dtbo.img, Image.gz). What did you use?
The best I could get were "dtb", "kernel" and "dtborecovery" (without extensions) which roughly had the same size as yours.
Also, as far as I understand it, with your initial commit (without the modifications for Lineage itself) I should be able to at least compile a recovery image but I got an error regarding a missing dtb.img file in the "out" directory.
Something seems to be missing because, my dtb file is in the "device" directory and not being transfered into "out" during building.
I'm not sure that is because I have got a different naming scheme (renamig it didn't help) or I did something wrong with the extraction.
---------- Post added at 07:30 ---------- Previous post was at 07:14 ----------
Another question I have:
Are the vbmeta-files you used to flash the recovery the ones from the original firmeware zip from unihertz or did you get them from the lineage built?
And reguarding the rather smallish system partition:
I have an idea to bypass that by using the SPFlash Tool from Mediatek. As far as I understand the settings in the scatter-file this tool does a repartitioning of the internal storage. So we only need to "decrease" the userdata, "move" some partitions inbetween and "increase" the system. Only problem is, I couldn't find a partition designated as "system" in the scatter-file, only one big "super" and a "vbmeta-system" (which for my understaning is for verified boot) partition.
What do you think?
Click to expand...
Click to collapse
> None of the tools I found gave me the exact files you have got (dtb.img, dtbo.img, Image.gz). What did you use?
There is a tool called `unpack_bootimg` in the Android source code. Just run `make unpack_bootimg` in the root directory of the Android source tree and you will get one in the output directory. (btw I have renamed those extracted files so the names won't exactly match, but you need this tool to extract the correct images. All other tools won't work properly).
> my dtb file is in the "device" directory and not being transfered into "out" during building.
Because most tools other than `unpack_bootimg` extracts dtb incorrectly.
> Are the vbmeta-files you used to flash the recovery the ones from the original firmeware zip from unihertz or did you get them from the lineage built?
Those don't matter. Either will work as long as you flash it with the correct parameters as given in my post.
> And reguarding the rather smallish system partition
No don't do that. Android 10 does not use a separate system partition anymore, instead both system, vendor and product are sub-partitions in a huge super partition. When flashing a new ROM, the partitions are automatically resized to match the new image exactly, instead of leaving free space unused like before Android 10. That's why I need to reserve space in BoardConfig.mk for gapps to be installed correctly.

Still not able to build.
PeterCxy said:
There is a tool called `unpack_bootimg` in the Android source code. Just run `make unpack_bootimg` in the root directory of the Android source tree and you will get one in the output directory. (btw I have renamed those extracted files so the names won't exactly match, but you need this tool to extract the correct images. All other tools won't work properly).
Click to expand...
Click to collapse
I'm still getting an error:
Code:
FAILED: ninja: 'out/target/product/Atom_XL/dtb.img', needed by 'out/target/product/Atom_XL/boot.img', missing and no known rule to make it
Comparing your BoardConfig.mk with mine shows a slight difference in the offset and size values which could be associated with the different kernels of the phones.
But using "unpack_bootimg" I didn't get a value for "BOARD_KERNEL_OFFSET" like you have it in your config. Could this be the problem?
Your BoardConfig.mk
My BoardConfig.mk
Do you see anything else out of the ordinary?
(Because I'm doing everything what you did step-by-step the links point to the best matching commits)
Despite not being able to compile right now I tried to press on with integrating your changes in the hopes that it will be fixed somehow later on
So I'm currently stuck on this commit of yours:
Atom_L: import overlay from official vendor
Where did you get the "config.xml" and "power_profile.xml" from? The best thing I could find was a "power_profile.xml" inside "/vendor/overlay/FrameworkResOverlay/FrameworkResOverlay.apk" which seems to be a "compiled" version of the aforementioned xml-file.

a-dead-trousers said:
I'm still getting an error:
Code:
FAILED: ninja: 'out/target/product/Atom_XL/dtb.img', needed by 'out/target/product/Atom_XL/boot.img', missing and no known rule to make it
Comparing your BoardConfig.mk with mine shows a slight difference in the offset and size values which could be associated with the different kernels of the phones.
But using "unpack_bootimg" I didn't get a value for "BOARD_KERNEL_OFFSET" like you have it in your config. Could this be the problem?
Your BoardConfig.mk
My BoardConfig.mk
Do you see anything else out of the ordinary?
(Because I'm doing everything what you did step-by-step the links point to the best matching commits)
Despite not being able to compile right now I tried to press on with integrating your changes in the hopes that it will be fixed somehow later on
So I'm currently stuck on this commit of yours:
Atom_L: import overlay from official vendor
Where did you get the "config.xml" and "power_profile.xml" from? The best thing I could find was a "power_profile.xml" inside "/vendor/overlay/FrameworkResOverlay/FrameworkResOverlay.apk" which seems to be a "compiled" version of the aforementioned xml-file.
Click to expand...
Click to collapse
> Comparing your BoardConfig.mk with mine shows a slight difference in the offset and size values which could be associated with the different kernels of the phones.
TARGET_KERNEL_OFFSET should normally always be 0x00008000. Also, your other offset values seem to be wrong too -- those values from `unpack_bootimg` cannot be filled in directly to BoardConfig.mk. Instead, you need to subtract BOARD_KERNEL_BASE from them (e.g. BOARD_RAMDISK_OFFSET should be 0x55000000 - 0x40078000, which is 0x14f88000, the same as mine). In fact, I think those parameters should be exactly the same for XL and L. Other than that, I don't think I can see much of a problem about your makefiles.
However, note that not all of my historical commits represent a compilable state of the device tree. I'd suggest you start directly from the latest state and just replace whatever is relevant instead of starting over. And there should not be much that needs changing at all except device names, fingerprints and the proprietary vendor files.
> Where did you get the "config.xml" and "power_profile.xml" from
Exactly from those apks. Just decompile them using apktool.

PeterCxy said:
TARGET_KERNEL_OFFSET should normally always be 0x00008000. Also, your other offset values seem to be wrong too -- those values from `unpack_bootimg` cannot be filled in directly to BoardConfig.mk. Instead, you need to subtract BOARD_KERNEL_BASE from them (e.g. BOARD_RAMDISK_OFFSET should be 0x55000000 - 0x40078000, which is 0x14f88000, the same as mine). In fact, I think those parameters should be exactly the same for XL and L. Other than that, I don't think I can see much of a problem about your makefiles.
Click to expand...
Click to collapse
Still giving me errors.
So I tried a very unconventional approach: I just copied the file myself into the mentioned "out/target/product/Atom_XL" folder.
For now it's still compiling. Fingers crossed.
PeterCxy said:
However, note that not all of my historical commits represent a compilable state of the device tree. I'd suggest you start directly from the latest state and just replace whatever is relevant instead of starting over. And there should not be much that needs changing at all except device names, fingerprints and the proprietary vendor files.
Click to expand...
Click to collapse
I just reached your biggest commit yet.
Can you tell me how you got the list of needed files? I hope it's not through trial-and-error.
Except for the values in "setup-makefiles.sh" only the "proprietary-files.txt" seems to be device specific. Is there anything else I need to be aware of in this commit?
P.S.: I know it is tedious to go through your commits one by one but I want to learn something of it not just simply copying what you did. To get a feeling where the biggest pitfalls are and what you did to circumvent them.

a-dead-trousers said:
Still giving me errors.
So I tried a very unconventional approach: I just copied the file myself into the mentioned "out/target/product/Atom_XL" folder.
For now it's still compiling. Fingers crossed.
I just reached your biggest commit yet.
Can you tell me how you got the list of needed files? I hope it's not through trial-and-error.
Except for the values in "setup-makefiles.sh" only the "proprietary-files.txt" seems to be device specific. Is there anything else I need to be aware of in this commit?
P.S.: I know it is tedious to go through your commits one by one but I want to learn something of it not just simply copying what you did. To get a feeling where the biggest pitfalls are and what you did to circumvent them.
Click to expand...
Click to collapse
> Still giving me errors.
Looks like that dtb.img error was totally my fault -- it was due to my jerry-rigged solution of using prebuilt dtb image that conflicted with one of Lineage's update in August and I haven't built the ROM for a month. Now I have fixed it in the latest commit.
> Can you tell me how you got the list of needed files?
All of those files are for VoLTE support and I started with the list from a commit in Redmi Note 7 Pro's device tree that imported those VoLTE blobs, and then added what was missing one by one (when something is missing the Phone process will crash and you can see what got missing in the logs). I don't think the list will be any different on Atom XL so you can just use the one in my device tree.

Hi.
Thanks to you everything is running smoothly here. But what bugs me is that TWRP is not working on our devices.
Although for the Atom there is a possibility: https://forum.xda-developers.com/android/development/twrp-modded-to-unihertz-atom-t3885793
Before I want to go public with my build I wanted to solve this last "mystery".
So I tried to include it in my current source tree according to the (official?) guide but some errors prevented me from a successful build.
Naturally I asked for some guidance at the most reasonable places I know of but got nothing so far:
https://forum.xda-developers.com/showpost.php?p=83443611&postcount=4622
https://forum.xda-developers.com/showpost.php?p=83455271&postcount=4623
https://github.com/TeamWin/android_bootable_recovery/issues/70
I even tried different repositories (omnirom/android_bootable_recovery) and revisions (android-9.0) but these resulted in missing library "type" (static vs. shared) errors so I assume these are too old for LineageOS 17.1
What I want to know is how you managed to get TWRP to built for your device even though the touchscreen wasn't working?
Did you use your LineageOS source tree or one of the many "minimal" manifests? If so, which one would be the "best" to use?
wkr ADT

@PeterCxy and @a-dead-trousers
Thanks for all the work on this so far. I've got an Atom L and have gotten the ROM's PeterCxy posted running on them as in the OP. Do either of you have a quick step-by-step workflow of how you got all the Lineage sources set up and built into the various ROMs? I'd like to be able to build the ROMs from scratch and understand the process.
If I can get caught up to where you two are at with the builds, I can help debug, test and work through issues.

dirtylimerick said:
[MENTION=5351691] Do either of you have a quick step-by-step workflow of how you got all the Lineage sources set up and built into the various ROMs? I'd like to be able to build the ROMs from scratch and understand the process.
If I can get caught up to where you two are at with the builds, I can help debug, test and work through issues.
Click to expand...
Click to collapse
I documented my steps to setup up the build environment in the readme of my repo:
https://github.com/ADeadTrousers/android_device_Unihertz_Atom_XL
But leave out the TWRP part. It isn't working yet mostly because TeamWin/android_bootable_recovery and LineageOS/android_bootable_recovery are too similar.
To figure out all the bits and pieces needed for the device I followed the commit log of @PeterCxy build.

Hi, @PeterCxy.
Finally I was able to build a TWRP recovery and surprise, surprise the touchscreen isn't working.
But during my attempts to get a working TWRP build I came acros a guide that explains how to patch the kernel to get the touchscreen to work.
https://forum.hovatek.com/thread-27132.html
So I tried to follow it but failed to identify the "end" of the zipped Image-file (step 18) to remove the payload from the gz-file. Regardless of which of the null-bytes I use for cutting I always get a warning from 7-zip that there is still data at the end.
Do you know a better approach to achieve this whole patching? Maybe even come up with a scripting solution to easily apply this patch in later builds?
wkr ADT

a-dead-trousers said:
Hi, @PeterCxy.
Finally I was able to build a TWRP recovery and surprise, surprise the touchscreen isn't working.
But during my attempts to get a working TWRP build I came acros a guide that explains how to patch the kernel to get the touchscreen to work.
https://forum.hovatek.com/thread-27132.html
So I tried to follow it but failed to identify the "end" of the zipped Image-file (step 18) to remove the payload from the gz-file. Regardless of which of the null-bytes I use for cutting I always get a warning from 7-zip that there is still data at the end.
Do you know a better approach to achieve this whole patching? Maybe even come up with a scripting solution to easily apply this patch in later builds?
wkr ADT
Click to expand...
Click to collapse
There is no sane way to solve the problem without kernel source code. Basically the stock kernel just does not load the touch screen driver in recovery mode. That patching guide is pretty out of date and I imagine it won't work on most recent kernels. The only proper way is to pressure Unihertz to actually obey GPLv2 and release their kernel source code. Or maybe someone can try reverse-engineering the kernel, but at least I won't do it because it'll just be too much of a hassle.

PeterCxy said:
There is no sane way to solve the problem without kernel source code. Basically the stock kernel just does not load the touch screen driver in recovery mode. The only proper way is to pressure Unihertz to actually obey GPLv2 and release their kernel source code.
Click to expand...
Click to collapse
I'm with you on this one, but as long as we don't have the source code we need to resort to other means to achieve our goals.
PeterCxy said:
That patching guide is pretty out of date and I imagine it won't work on most recent kernels.
Click to expand...
Click to collapse
Yeah it's from way back in 2019
Anyway, with a little bit of tinkering I was able to modify my kernel to load the touchscreen driver in recovery mode.
Here is the device tree and the manifest i used.
I wouldn't recommend to use it in it's current state at all though because the fstab needs a little bit of tinkering. Everything seems to be either unordered or not mounted properly and I fear anything you do in there now will mess up the whole device. BUT I got the touchscreen goin for me which is nice.
PeterCxy said:
Or maybe someone can try reverse-engineering the kernel, but at least I won't do it because it'll just be too much of a hassle.
Click to expand...
Click to collapse
As soon as I have everything sorted out that needs to be fixed on my build (e.g. signing, radio, included gapps working properly, TWRP) I want to dig deeper into the kernel.
There are some devices with Helios P60 out there from other vendors which offer kernel sources.
P.S.: I also uploaded a HOW-TO in my device tree.
If you or someone else wants to try it. Also if you want to you can send me a "symbl.txt" (see to the HOW-TO) extracted from your device then I can do the patching for the Atom_L too.

a-dead-trousers said:
I'm with you on this one, but as long as we don't have the source code we need to resort to other means to achieve our goals.
Yeah it's from way back in 2019
Anyway, with a little bit of tinkering I was able to modify my kernel to load the touchscreen driver in recovery mode.
Here is the device tree and the manifest i used.
I wouldn't recommend to use it in it's current state at all though because the fstab needs a little bit of tinkering. Everything seems to be either unordered or not mounted properly and I fear anything you do in there now will mess up the whole device. BUT I got the touchscreen goin for me which is nice.
As soon as I have everything sorted out that needs to be fixed on my build (e.g. signing, radio, included gapps working properly, TWRP) I want to dig deeper into the kernel.
There are some devices with Helios P60 out there from other vendors which offer kernel sources.
P.S.: I also uploaded a HOW-TO in my device tree.
If you or someone else wants to try it. Also if you want to you can send me a "symbl.txt" (see to the HOW-TO) extracted from your device then I can do the patching for the Atom_L too.
Click to expand...
Click to collapse
Happy to hear that you were able to figure the touchscreen out. I tried to port TWRP at the very beginning when I started tinkering with the device but quickly grew frustrated and just ported Lineage Recovery instead. I guess I might try patching the kernel image too at some point later.
BTW, for TWRP to work with devices released after Android 10, I'm pretty sure you need an extra set of patches that are not yet fully merged to the main TWRP repository. I remember there's some guy providing another manifest with all the patches applied but I couldn't remember the name.

Hi.
I just officially announced my build for the Atom XL:
https://forum.xda-developers.com/android/development/rom-lineageos-17-1-unihertz-atom-xl-t4171407
Could you please put a link in your first post for those in search of the Atom XL and found your thread instead. Thanks.
wkr ADT

hi @PeterCxy.
During my daily usage of the phone I encountered a strage problem:
The audio jack isn't working. Plugging in some headphones I get this slight click in the earpieces when the circuits connect but nothing else happens. Neither a "headphone" icon in the status bar nor hearing anything coming from the headphones itself. The main speaker of the phone keeps playing the music. Using bluetooth everything is working as expected though. So I used logcat to see if something is coming up during plugging in but nothing "catchy" shows up in the logs. My guess is that some (vendor?) service is missing or not started during booting. Next I checked If something shows up on logcat during boot but I'm not sure for what to look exactly. There are quite a few errors and warnings though. In my despair I started to "fix" the "avc: denied" (SEPolicy) entries. Thats when I found a specific error reguarding VoLTE. Maybe this would fix the problems you had with VoLTE in enforcing mode:
https://github.com/ADeadTrousers/an..._Atom_XL/blob/master/sepolicy/private/init.te
(The line with "socket_device:sock_file")
My provider doesn't support VoLTE so I'm not sure if this helps or not. Maybe you could check it.
Anyway can you please tell me if your device's audio jack is working or not?
If you're (by some mysterious coincidence) not affected by this, can you at least give me some pointers for what to look for to get this fixed on my side.
The Internet Is not very helpful when searching for "android audio jack" or something similiar.
Thanks in advance.
wkr ADT

[ROM] [Unofficial] [Stable] GrapheneOS 10 Pre-Rooted

**** Disclaimer: I'm not responsible if you destroy your device. Use at your own risk!!! ****
GrapheneOS is an open source privacy and security focused mobile OS with Android app compatibility. It's focused on the research and development of privacy and security technology including substantial improvements to sandboxing, exploit mitigations and the permission model. Currently it is based on AOSP.
Link: (Mod Edit: Link removed)
Important information:
1. This ROM does NOT include Gapps or Google Play Service and hasn't Signature Spoofing Support. If you rely on the mentioned things this Rom isn't for you.
2. I take the official releases, modify the install script and include a pre-patched Magisk boot image. I'm not in contact with the GrapheneOS dev which is the reason why i mark this ROM as Unofficial.
3. Due of point two: Please don't ask questions on the official channels as reddit. Leave comments etc here on this thread.
4. You need a unlocked bootloader to flash this rom and must have adb+fastboot installed on your computer. If this is not the case download it from here: https://developer.android.com/studio/releases/platform-tools
I plan to make unofficial releases when new official builds are available.
Features:
AOSP 10
Built-in Firewall
Built-in local backup function (it's not working on all Apps; some doesn't support it)
Improved MAC Randomization
Hardened Kernel
Expanded Permissions (sensors)
Force calls to 4G only
Bugs
- Receiving text over verizon sim doesn't work reliable. Thx @wolfu11 for reporting.
Download: (Mod Edit: Link removed)
Installation:
Notice 1: The First-time installation will wipe your data. Backup first (i recommend this too when you follow the update instructions to be safe)
Notice 2: I recommend to have the newest stock firmware before the First-time installation
First-time installation:
1. Download the zip from the linked download page and unzip it on your computer
2. Copy the following files into the plattform-tools folder:
-> coral zip
-> bootloader img
-> radio img
-> flash-all_first_install.bat for Windows or flash-all_first_install.sh for Linux
3. Boot your phone into fastboot mode and verify that the phone is recognized from your computer
4. In Terminal (Linux) or Powershell (Windows): Run the appropriate script
5. Install the Magisk Manager App
10. Be happy with a rooted GrapheneOS
Update:
Notice: I assume that fastboot+adb is still installed on your computer.
1. Download the newest zip from the linked download page and unzip it on your computer
2. Copy the following files into the plattform-tools folder:
-> coral zip
-> bootloader img
-> radio img
-> flash-all.bat for Windows or flash-all.sh for Linux
If your computer asks you to overwrite the current files in the plattform-tools folder, confirm it.
3. Boot your phone into fastboot mode and verify that the phone is recognized from your computer
4. In Terminal (Linux) or Powershell (Windows): Run the appropriate script
5. Start the system once. This need a few more time than the first installation cause the data partition remains. Be patient.
6. Install the Magisk Manager App
7. Be happy with a rooted GrapheneOS
Sources:
https://github.com/GrapheneOS
https://grapheneos.org/releases
https://github.com/GrapheneOS/kernel_google_coral
https://github.com/GrapheneOS/device_google_coral-kernel
All Credits go to:
- The GrapheneOS team
- wolfu11 for reporting the verizon bug and testing the windows scripts
- and topjohnwu for his amazing Magisk
Created: 09.08.2020
Based on: Android 10
Updated: 21.08.2020
Current Version: 2020.08.07.01

Changelog from 09.08.2020
New Release: 2020.08.03.22
SHA3-512 Hash for Complete zip:
Code:
773c67b8571927c6f884a98ee67a10f96c3a759e34f925f7a8aaab7c19a4ca6b1ff53bb6dc500b4fe7c306b73853189a1c559889df6d9b4f2e8a90258d3d26c9
SHA3-512 Hash for Unpatched boot.img:
Code:
9b584f6941d37f60a7ed17ec4108b7bf484c3cbf1b63f2be6af1e59f452ed1d06e1b64704785d6ca3b38a3c09c8f29657f88c757bda993df509ef001d9842f00
Changes:
full 2020-08-01 security patch level
full 2020-08-05 security patch level
rebased onto QQ3A.200805.001 release
fix secondary stack hardening when a non-page-size multiple stack size is specified
fix picking up previous build date when doing incremental builds
Vanadium: update Chromium base to 84.0.4147.89
Vanadium: update Chromium base to 84.0.4147.105
Vanadium: update Chromium base to 84.0.4147.111
Vanadium: remove Chromium logo in chrome://version
kernel (Pixel 4, Pixel 4 XL): read-only data expansion

Changelog from 11.08.2020:
Updated the OP with some more informations
Rewrite the instruction cause i believe that they were not fully correct.
Reupload the 2020.08.03.22 unofficial release with new structure. I patched the boot.img which come with GrapheneOS in the zip with Magisk and then replaced the original GrapheneOS boot.img in the zip with the patched version.

Hi good evening to all,
Can somebody try to install this Rom with the updated instructions? I think they should work now (at least on Linux) but i would appreciate a confirmation to be safe.

dhacke said:
Changelog from 11.08.2020:
Updated the OP with some more informations
Rewrite the instruction cause i believe that they were not fully correct.
Reupload the 2020.08.03.22 unofficial release with new structure. It isn't needed anymore to flash Magisk separately from the zip. I replaced the stock boot.img in the zip with the pre-patched one.
Click to expand...
Click to collapse
Just a heads up - you really aren't meant to pre-patch a boot image for Coral/Flame, as you are only meant to patch the boot image from your own individual device, as per the man topjohnwu himself
See: https://twitter.com/topjohnwu/status/1272136975022084097?s=19

Can you supply the unpatched boot img?
Thank you

wolfu11 said:
Can you supply the unpatched boot img?
Thank you
Click to expand...
Click to collapse
Done. Look here: (Mod Edit: Link removed)
I added an SHA3-512 Hash for file checking,too (see changelog from 11.08.2020).

Changelog from 15.08.2020
New Release: 2020.08.07.01
SHA3-512 Hash for Complete zip:
Code:
f3a2b088e0ec503296d5a2527a3766951cb2a3ccd1955ced14d304222e76ed3f341dd9d84b6e186a534eddac335065b756c1fdc89d0f1db3985314424e7f9eea
SHA3-512 Hash for unpatched boot image:
Code:
11abb901511ce8e39911bc951be4b1a349158c5d8389e74766942159c0f83aa9730ed39d8c8ae6c3cc66be559e3c165b5d4f35e0962d20a7be0b1532673a0287
Changes:
SELinux policy: fix executing apk libraries as executables for third party applications
Installation Notices:
From 2020.08.03.22 => No wipe needed. Just take the update scripts and let the right one running (see OP).
From Stock Rom => Use the install_first scripts. Be aware: This will wipe your data
Apart from that i recommend to make a backup first always (to be safe).

Wireguard Kernel integration
dhacke said:
Hi good evening to all,
Can somebody try to install this Rom with the updated instructions? I think they should work now (at least on Linux) but i would appreciate a confirmation to be safe.
Click to expand...
Click to collapse
Hi, great work!! It was exactly what I was looking for, GrapheneOS with root. Are you able to integrate wireguard into the kernel?

[email protected] said:
Hi, great work!! It was exactly what I was looking for, GrapheneOS with root. Are you able to integrate wireguard into the kernel?
Click to expand...
Click to collapse
Hi Cryptt33,
first thx for your praise.
Regarding wireguard integration:
You should be able to use Wireguard independently from the kernel if i understand the description from the wireguard f-droid app right (https://f-droid.org/en/packages/com.wireguard.android/).
Then Wireguard runs in a userspace version. Apart from that i have found a xda thread already regarding wireguard integration. I guess i will at least try it and mayby i will be successful with the help of the thread. But i can't give a eta. I built roms from sources in the past but i until now i didn't try to modify them before the compiling step.
Best regards
dhacke

dhacke said:
Hi Cryptt33,
first thx for your praise.
Regarding wireguard integration:
You should be able to use Wireguard independently from the kernel if i understand the description from the wireguard f-droid app right (https://f-droid.org/en/packages/com.wireguard.android/).
Then Wireguard runs in a userspace version. Apart from that i have found a xda thread already regarding wireguard integration. I guess i will at least try it and mayby i will be successful with the help of the thread. But i can't give a eta. I built roms from sources in the past but i until now i didn't try to modify them before the compiling step.
Best regards
dhacke
Click to expand...
Click to collapse
Just need to add this to local_manifest for WG support
If unfamiliar with local_manifest, it's located in /.repo/local_manifests/ - it'll be the only file in that dir, often it's called room service.xml but it could be something like graphene_manifest.xml. Either way, it'll be the only file there and it'll be an XML - add those lines above to it and sync and you should have WireGuard support.
<remote name="zx2c4" fetch=https://git.zx2c4.com/>
<project remote="zx2c4" name="android_kernel_wireguard" path="kernel/wireguard" revision="master" sync-s="true" />

dhacke said:
Hi good evening to all,
Can somebody try to install this Rom with the updated instructions? I think they should work now (at least on Linux) but i would appreciate a confirmation to be safe.
Click to expand...
Click to collapse
I've tried this several time with a windows computer with no luck the shell opens briefly with red writing on the top and closes.
i must be doing something wrong but can't put my finger on it..... i run windows ltsb but i don't have any issues up and downgrading my p4 xl on it i am running the latest platform tools but get this message:
C:\Users\Wolf's laptop\Desktop\platform-tools_r30.0.4-windows\platform-tools>flash-all_first_install
fastboot : The term 'fastboot' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:10
+ $version=fastboot --version; try { $verNum = $version[0].substring(17 ...
+ ~~~~~~~~
+ CategoryInfo : ObjectNotFound: (fastboot:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
fastboot too old; please download the latest version at https............

wolfu11 said:
I've tried this several time with a windows computer with no luck the shell opens briefly with red writing on the top and closes.
i must be doing something wrong but can't put my finger on it..... i run windows ltsb but i don't have any issues up and downgrading my p4 xl on it i am running the latest platform tools but get this message:
C:\Users\Wolf's laptop\Desktop\platform-tools_r30.0.4-windows\platform-tools>flash-all_first_install
fastboot : The term 'fastboot' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:10
+ $version=fastboot --version; try { $verNum = $version[0].substring(17 ...
+ ~~~~~~~~
+ CategoryInfo : ObjectNotFound: (fastboot:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
fastboot too old; please download the latest version at https............
Click to expand...
Click to collapse
Hi wolfu11,
i know this message in similar way on Linux. To fix it on linux i need to run all fastboot commands and scripts with './' before.
So for example:
./fastboot devices instead of fastboot devices or ./flash-all.sh instead of flash-all.sh.
I done this in the scripts for linux already cause i know it is needed there but didn't thought that it is needed on windows, too.
So please go into the script and make this before all fastboot commands:
./
Save it and execute it in the plattform-tools folder with ./ again in the shell. Hopefully it runs then.
If this fixes your issue, i will update the windows scripts.

dhacke said:
Hi wolfu11,
i know this message in similar way on Linux. To fix it on linux i need to run all fastboot commands and scripts with './' before.
So for example:
./fastboot devices instead of fastboot devices or ./flash-all.sh instead of flash-all.sh.
I done this in the scripts for linux already cause i know it is needed there but didn't thought that it is needed on windows, too.
So please go into the script and make this before all fastboot commands:
./
Save it and execute it in the plattform-tools folder with ./ again in the shell. Hopefully it runs then.
If this fixes your issue, i will update the windows scripts.
Click to expand...
Click to collapse
I will try it when I get home today thank you

wolfu11 said:
I will try it when I get home today thank you
Click to expand...
Click to collapse
that didn't work either i downloaded the latest platform tools so im at a loss about the fastboot issue.
I'm going keep trying
Update: I was able to get the official Graphene to work via putting the image into a working stock update platform tools folder and renaming it to the stock image. it wouldn't work per instruction on the website very strange.

wolfu11 said:
that didn't work either i downloaded the latest platform tools so im at a loss about the fastboot issue.
I'm going keep trying
Update: I was able to get the official Graphene to work via putting the image into a working stock update platform tools folder and renaming it to the stock image. it wouldn't work per instruction on the website very strange.
Click to expand...
Click to collapse
Well it was worth a shot texts don't work on verizon so i guess i'll just give up.
thank you

wolfu11 said:
Well it was worth a shot texts don't work on verizon so i guess i'll just give up.
thank you
Click to expand...
Click to collapse
Hi wolfu11,
i tested the bat script (more precisely flash-all.bat) with './' on my dedicated gaming machine with win 10 2004 education, too. First i got the same problem as you: It didn't run whether i made './' before all fastboot commands in the scripts.
Then i removed all the './' before all fastboot command except at this line:
Code:
$version= fastboot --version; ^
So the line looks now:
Code:
$version=./fastboot --version; ^
And hurray the script worked without problems on my machine (see attached screenshots).
Only as reminder: The bat scripts are from the 2020.08.07.01 unofficial release so you need the radio, bootloader and image files from that release.
i attached the new scripts with my mentioned modification, too. Xda doesn't allow bat files so i made them into a zip file. Please test once more. Thx in advance.

dhacke said:
Hi wolfu11,
i tested the bat script (more precisely flash-all.bat) with './' on my dedicated gaming machine with win 10 2004 education, too. First i got the same problem as you: It didn't run whether i made './' before all fastboot commands in the scripts.
Then i removed all the './' before all fastboot command except at this line:
Code:
$version= fastboot --version; ^
So the line looks now:
Code:
$version=./fastboot --version; ^
And hurray the script worked without problems on my machine (see attached screenshots).
Only as reminder: The bat scripts are from the 2020.08.07.01 unofficial release so you need the radio, bootloader and image files from that release.
i attached the new scripts with my mentioned modification, too. Xda doesn't allow bat files so i made them into a zip file. Please test once more. Thx in advance.
Click to expand...
Click to collapse
That script worked thanks

wolfu11 said:
That script worked thanks
Click to expand...
Click to collapse
Yeah finally. I'm happy to read that. Then i will update the OP & scripts in the next days and take you on the credit section. Thx very much for your windows testing.
Now the next on the to-do list is the building of this rom from source and adding Wireguard support into the kernel

dhacke said:
Yeah finally. I'm happy to read that. Then i will update the OP & scripts in the next days and take you on the credit section. Thx very much for your windows testing.
Now the next on the to-do list is the building of this rom from source and adding Wireguard support into the kernel
Click to expand...
Click to collapse
No problem i'm happy to test. unfortunately the still is an issue with texting on verizon which is what i use this phone on. the texts send but receiving them is not reliable. I tested on an att sim and it didn't have an issue so it's something on verizon's end.

Question [ROOT] A52 device setup for TS.43 testing

I want to test the TS.43 flow by changing some of the carrier configuration (cc) parameters as described in: IMS Service Entitlement | Android Open Source Project
For that, I use:
Samsung Galaxy A52
AP: A525FXXS4BVE1
CP: A525FXXU4BVC2
CSC: A525FOXM4BVC3
Model: SM-A525F/DS
According to documentation, for that, I require the root access and I actually managed to set this up with Magisk and Odin (following this guide: https://www.samsungsfour.com/tutorials/root-galaxy-a52.html , except for some minor deviations like downloading Magisk from official github page).
However, I would still get the error message “cc: Permission denied.” when running the cc command in shellin mode.
I have tried to find information about it but the best I could find was the following:
https://android.googlesource.com/pl.../com/android/phone/TelephonyShellCommand.java
Here on lines 908 and 1481, I can see the check for whether we are running in root mode AND also validation for whether we have a non-"user" build type.
From TelephonyUtils - boolean IS_USER = “user”.equals(android.os.Build.Type);
From Build.TYPE - /** The type of build, like “user” or “eng”. */
public static final String TYPE = getString(“ro.build.type”);
I am not too familiar with Android development, so I would like to ask the following.
How do I get the ro.build.type as something other than “user”?
As I understand, I would need to download the Samsung firmware for my phone which has the ro.build.type=eng OR ro.build.type=userdebug ? Where can I get such ROM? As eng and userdebug are for testing, does Samsung even provides such firmware?
If I am mistaken, could you please generally advise me on such issues and propose some possible solutions?
Note: I understand that what I do might void my phone of warranty and block some applications. This device is for testing purposes only and it is not going to be used in common user activities.
P.S. And yes I decided to try (out of desperation rather than sane mind) and change the build props with BuildProp Editor app (had to reset to factory, I'm not the brightest man around)

[Android 12 / LineageOS 19.1] Manual patch to services.jar for signature spoofing

I haven't seen this shared anywhere but it's really quite straightforward if you know what you're doing. Maybe it helps someone to post it here. The next section is only for completeness, feel free to skip past it to get to the gist of it.
Background
Android by design depends for full functionality on Google services. These are normally provided by a proprietary application package com.google.android.gms. MicroG is an open-source replacement for Google services, allowing the user to take advantage of working notifications, location backends, installer, and other essential services, without compromising privacy and giving Google a backdoor to your device.
To operate properly, MicroG needs the ability to pretend it is the actual Google services application package, signed by Google. Hence the need for signature spoofing.
Official LineageOS builds do not include the ability to spoof signatures. Thus, using LineageOS with MicroG takes extra steps such as building patched LineageOS locally (a resource-consuming endeavor), or taking advantage of the LineageOS for MicroG builds helpfully provided in collaboration with the MicroG team (which however, due to resource constraints, are updated less often and lag behind the official builds).
A third solution is to patch an already-built system at installation time. This was initially implemented with Needle by souramoo, forked and improved upon as Tingle by @ale5000, which eventually inspired a wholly different approach with DexPatcher by @Lanchon, a tool allowing flexible patching of Dalvik executables, in particular services.jar, where signature spoofing is commonly implemented. Relevant patches for DexPatcher were authored by Lanchon himself up to Android 9. Later on, @oF2pks picked up the work to provide patches for Android 11.
Unfortunately, no such patch to be used with DexPatcher has existed from Android 12 onwards. One other option includes installing the FakeGApps Xposed module as forked and updated by whiz-inc. While it's great it exists, and the author's work should be appreciated, it's a complication and an unnecessary burden in many scenarios to depend on Xposed (and thus Magisk and LSPosed or the like) as a prerequisite for the patch to work. It's also worth it to be aware that the implementation makes it less secure than the traditional signature spoofing method.
The DexPatcher approach has several advantages. The patch can be more flexible and continues to apply as the underlying code changes. In comparison, the simple approach presented here is much more primitive and might require readjustment as new versions emerge over time. However it might still be good to know it works.
This way you can use the latest official LineageOS with MicroG, and update at will, as soon as new builds become available.
Patching
This is not a walkthrough, and I'm not going to explain everything step-by-step. Rather, the purpose is to give you the general idea what to do, which you can then adjust to your specific use case.
Obtain the file services.jar to patch. For example:
Pull it from your device: adb pull /system/framework/services.jar – or –
Extract it from a LineageOS image: payload-dumper-go -p system payload.bin and imgextractor system.img
Extract the file with APK Tool: apktool2 d -o services services.jar
Make the changes that allow signature spoofing. Either:
Apply the patch attached to this post: patch -i services.diff -p0 – or –
As of current LOS 19.1 builds (Nov 2022), you can just replace the single file: smali_classes2/com/android/server/pm/PackageManagerService$ComputerEngine.smali with the one attached to this post.
Note: this might not always hold in the future. You might even need to apply the patch manually if the source changes too much. Either approach works for now.
Recompile the modified framework: apktool2 b -c -f -o services.jar services
Note: This will overwrite the original services.jar. The -c flag to APK Tool is important as it keeps all the original META-INF inside it intact.
Copy services.jar over to the device: adb push services.jar /system/framework/ and you probably also have to adjust the permissions accordingly
This approach should work for any Android version in principle, although the exact patch might differ. However, since better options exist for Android 11 and below, you are probably interested in applying this to Android 12 or higher only.
One More Thing
For Android 12, an extra step is critical to ensure no bootloop on subsequent boot (2nd and then on), since oat_file_manager.cc now includes a check if OAT (.odex/.vdex) files are loaded from "trusted" locations only (effectively, the /system partition). You have to generate the optimization files and place them in the correct location, which is /system/framework/oat/arm64/:
dex2oat --dex-file=/system/framework/services.jar --instruction-set=arm64 --oat-file=/system/framework/oat/arm64/services.odex
The .vdex file will be created as well (these files already exist but should be overwritten, check the timestamps or you might want to delete them beforehand just to be sure). If you skip this step, the device will boot the 1st time but then the optimization files will be generated and saved in /data/dalvik-cache/. On any subsequent boot, an attempt to load these files from an "untrusted" location by the system will throw a fatal error and the Zygote process will die with the message: "Executing untrusted code from [...]". If you somehow find yourself in this predicament, delete the following files and reboot to temporarily make it work one more time:
/data/dalvik-cache/arm64/[email protected][email protected]@classes.dex
/data/dalvik-cache/arm64/[email protected][email protected]@classes.vdex
Further Steps
These are not all the required steps to install MicroG on an official LineageOS installation. You still want to, in particular:
Install at least the main MicroG app (GmsCore) and a dummy signature spoofing APK (also attached to this post) as priv-apps
Set up the priv-app permissions accordingly – otherwise you'll get a bootloop
Likely also install FakeStore, Aurora Store/F-Droid, and location backends of your choice, etc.
However: this is a simple solution to perhaps the most cumbersome aspect of signature spoofing. It's not necessary to resort to Xposed modules to get it working on Android 12, or to depend on a special build with the spoofing patched in at compilation time.
Credit: The patch .smali code has been reverse-engineered from the spoofing patch for LineageOS for MicroG builds.

Aqq123 said:
Patching
This is not a walkthrough, and I'm not going to explain everything step-by-step. Rather, the purpose is to give you the general idea what to do, which you can then adjust to your specific use case.
Obtain the file services.jarto patch. For example:
Pull it from your device: adb pull /system/framework/services.jar – or –
Extract it from a LineageOS image: payload-dumper-go -p system payload.bin and imgextractor system.img
Click to expand...
Click to collapse
can i do this method for android 12 one ui 4.1 s10e? it says extract lineage os from system image but how do i do that in one ui?

kullanici32 said:
can i do this method for android 12 one ui 4.1 s10e? it says extract lineage os from system image but how do i do that in one ui?
Click to expand...
Click to collapse
I don't know anything about Samsung but try here:
[TUTORIAL] How to Edit Unpack & Repack Samsung system.img or system.img.ext4
Follow https://stackoverflow.com/questions/58541074/how-to-unpack-modify-pack-and-flash-system-img-ext4-file-using-odin a) Modifying With simg2img system.img.ext4 system.img, you will get a raw image file named system.img With mkdir system...
forum.xda-developers.com
Alternatively you can just take services.jar from a live (running) system.

kullanici32 said:
can i do this method for android 12 one ui 4.1 s10e? it says extract lineage os from system image but how do i do that in one ui?
Click to expand...
Click to collapse
There are many good custom Rom for s10e. Why do you want to start with one UI ?

kurtn said:
There are many good custom Rom for s10e. Why do you want to start with one UI ?
Click to expand...
Click to collapse
due to some dysfunctions and design change, I will debloat one UI 4.1 and turn off google and samsung services in the back and make it like lineage os as much as possible, but the main services I use will be samsung applications. so i have a dream

kullanici32 said:
due to some dysfunctions and design change, I will debloat one UI 4.1 and turn off google and samsung services in the back and make it like lineage os as much as possible, but the main services I use will be samsung applications. so i have a dream
Click to expand...
Click to collapse
I've seen people doing similar things on android 12
Signature Spoofing on unsuported Android 11 (R) Roms
How to get Signature Spoofing working on Android 11 (R) Roms that have no support for Signature Spoofing? In my Case here I use a Samsung Galaxy S8 with an unofficial LineageOS 18.1 (Android 11) by stricted I use TWRP recovery but this should...
forum.xda-developers.com

kurtn said:
I've seen people doing similar things on android 12
Signature Spoofing on unsuported Android 11 (R) Roms
How to get Signature Spoofing working on Android 11 (R) Roms that have no support for Signature Spoofing? In my Case here I use a Samsung Galaxy S8 with an unofficial LineageOS 18.1 (Android 11) by stricted I use TWRP recovery but this should...
forum.xda-developers.com
Click to expand...
Click to collapse
because once you use samsung software, you can't quit. (of course debloated) I have used my phone without root until now, only by disabling system applications. now I'm trying to remove as much samsung/google as possible from the system or whatever services are unnecessary for me, I will do just like micro g for lineage os, the only difference is by using quality applications such as gallery phone application, because lineage os is very lousy.

Aqq123 said:
As of current LOS 19.1 builds (Nov 2022), you can just replace the single file: smali_classes2/com/android/server/pm/PackageManagerService$ComputerEngine.smali with the one attached to this post.
Note: this might not always hold in the future. You might even need to apply the patch manually if the source changes too much. Either approach works for now
Click to expand...
Click to collapse
How can I manually edit this file? because the attached file is 288kb and the one in samsung is 390kb.
so how do i open this file and where do i patch it?

kullanici32 said:
How can I manually edit this file? because the attached file is 288kb and the one in samsung is 390kb.
so how do i open this file and where do i patch it?
Click to expand...
Click to collapse
Of course. The patch is against current LOS 19.1, and this is the only situation where you can replace the whole .smali file instead of reapplying the patch. On other flavors of Android you'd have to redo the equivalent manually. In some cases it might even take a different patch altogether.
These are all text files. Just use any text editor, preferably with syntax highlighting, such as Notepad++. First look at services.diff. This is the code you want to add.
Now, in the APK you decompiled, look for where .method public final generatePackageInfo(Lcom/android/server/pm/PackageSetting;II)Landroid/content/pm/PackageInfo; is defined. The patch works by adding two private methods:
.method private static applyFakeSignature(Lcom/android/server/pm/parsing/pkg/AndroidPackage;Landroid/content/pm/PackageInfo;Ljava/util/SetLandroid/content/pm/PackageInfo;
.method private static getRequestedFakeSignature(Lcom/android/server/pm/parsing/pkg/AndroidPackageLjava/lang/String;
These can really be added anywhere but preferably within the same .smali file.
Finally, you change the code for generatePackageInfo(...) accordingly so that: (1) signature faking is added (OR-ed) to computed permissions for apps that have this permission granted, and the fake signature is returned where applicable instead of the actual one with applyFakeSignature(...).
Maybe it's easier to understand if you look at the original code, not the decompiled one: https://github.com/lineageos4microg..._patches/android_frameworks_base-S.patch#L128 This is why I linked to it in the top post.
Again, I don't know anything about Samsung One UI. The implementation might be different. So another approach would be to find a version of Samsung's services.jar patched for signature spoofing (possibly for an earlier version of Android) and decompile it to see how it's done there.

Aqq123 said:
Now, in the APK you decompiled, look for where .method public final generatePackageInfo(Lcom/android/server/pm/PackageSetting;II)Landroid/content/pm/PackageInfo; is defined.
Click to expand...
Click to collapse
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
.method private static applyFakeSignature(Lcom/android/server/pm/parsing/pkg/AndroidPackage;Landroid/content/pm/PackageInfo;Ljava/util/SetLandroid/content/pm/PackageInfo;
.method private static getRequestedFakeSignature(Lcom/android/server/pm/parsing/pkg/AndroidPackageLjava/lang/String;
I just write this code you say?
Or should I search for the code you provided in services.diff and copy the places marked in blue and copy the entire blue one into my original compiled file?
Aqq123 said:
Finally, you change the code for generatePackageInfo(...) accordingly so that: (1) signature faking is added (OR-ed) to computed permissions for apps that have this permission granted, and the fake signature is returned where applicable instead of the actual one with applyFakeSignature(...).
Click to expand...
Click to collapse
I hardly understand what you mean here.
i'm a bit of a novice
EDİT:
I added the blue parts after I found the red part, now I'll compile and test (I've probably missed something, but I'll have a look)
EDİT2:
generatePackageInfo
I searched for the code you said, but there were 3-4 (there was 1 that continued as L, and I deleted the one in this picture)
and i replaced it with this
I'll compile it now, probably won't, but...
This is the first time I've been in such a complicated business.
EDİT3: (FİXED EDİT 4 I went inside the extracted folder and solved this problem now it keeps compiling)
It gives such an error, why? (apktool2 command didn't work when extracting the file, it worked when I made apktool, ignore it) but now when recompiling it gives an error as in the picture.
EDİT5:
such an error???
EDİT6:
now that this did not happen, after extracting the jar file, I packed it again without making any changes, the original 30 mb file decreased to 20 mb and transferred to the device with mtp, then I copied it with root browser, the device system ui restarted and opened, the permissions were something like rw rw rw, maybe rw rw is Then I rebooted but the phone bootlooped. that is, if I decompile the original file and repackage it without doing anything else, it breaks down. :/

Aqq123 said:
I haven't seen this shared anywhere but it's really quite straightforward if you know what you're doing. Maybe it helps someone to post it here. The next section is only for completeness, feel free to skip past it to get to the gist of it.
Background
Android by design depends for full functionality on Google services. These are normally provided by a proprietary application package com.google.android.gms. MicroG is an open-source replacement for Google services, allowing the user to take advantage of working notifications, location backends, installer, and other essential services, without compromising privacy and giving Google a backdoor to your device.
To operate properly, MicroG needs the ability to pretend it is the actual Google services application package, signed by Google. Hence the need for signature spoofing.
Official LineageOS builds do not include the ability to spoof signatures. Thus, using LineageOS with MicroG takes extra steps such as building patched LineageOS locally (a resource-consuming endeavor), or taking advantage of the LineageOS for MicroG builds helpfully provided in collaboration with the MicroG team (which however, due to resource constraints, are updated less often and lag behind the official builds).
A third solution is to patch an already-built system at installation time. This was initially implemented with Needle by souramoo, forked and improved upon as Tingle by @ale5000, which eventually inspired a wholly different approach with DexPatcher by @Lanchon, a tool allowing flexible patching of Dalvik executables, in particular services.jar, where signature spoofing is commonly implemented. Relevant patches for DexPatcher were authored by Lanchon himself up to Android 9. Later on, @oF2pks picked up the work to provide patches for Android 11.
Unfortunately, no such patch to be used with DexPatcher has existed from Android 12 onwards. One other option includes installing the FakeGApps Xposed module as forked and updated by whiz-inc. While it's great it exists, and the author's work should be appreciated, it's a complication and an unnecessary burden in many scenarios to depend on Xposed (and thus Magisk and LSPosed or the like) as a prerequisite for the patch to work. It's also worth it to be aware that the implementation makes it less secure than the traditional signature spoofing method.
The DexPatcher approach has several advantages. The patch can be more flexible and continues to apply as the underlying code changes. In comparison, the simple approach presented here is much more primitive and might require readjustment as new versions emerge over time. However it might still be good to know it works.
This way you can use the latest official LineageOS with MicroG, and update at will, as soon as new builds become available.
Patching
This is not a walkthrough, and I'm not going to explain everything step-by-step. Rather, the purpose is to give you the general idea what to do, which you can then adjust to your specific use case.
Obtain the file services.jarto patch. For example:
Pull it from your device: adb pull /system/framework/services.jar – or –
Extract it from a LineageOS image: payload-dumper-go -p system payload.bin and imgextractor system.img
Extract the file with APK Tool: apktool2 d -o services services.jar
Make the changes that allow signature spoofing. Either:
Apply the patch attached to this post: patch -i services.diff -p0 – or –
As of current LOS 19.1 builds (Nov 2022), you can just replace the single file: smali_classes2/com/android/server/pm/PackageManagerService$ComputerEngine.smali with the one attached to this post.
Note: this might not always hold in the future. You might even need to apply the patch manually if the source changes too much. Either approach works for now.
Recompile the modified framework: apktool2 b -c -f -o services.jar services
Note: This will overwrite the original services.jar. The -c flag to APK Tool is important as it keeps all the original META-INF inside it intact.
Copy services.jar over to the device: adb push services.jar /system/framework/ and you probably also have to adjust the permissions accordingly
This approach should work for any Android version in principle, although the exact patch might differ. However, since better options exist for Android 11 and below, you are probably interested in applying this to Android 12 or higher only.
One More Thing
For Android 12, an extra step is critical to ensure no bootloop on subsequent boot (2nd and then on), since oat_file_manager.cc now includes a check if OAT (.odex/.vdex) files are loaded from "trusted" locations only (effectively, the /system partition). You have to generate the optimization files and place them in the correct location, which is /system/framework/oat/arm64/:
dex2oat --dex-file=/system/framework/services.jar --instruction-set=arm64 --oat-file=/system/framework/oat/arm64/services.odex
The .vdex file will be created as well (these files already exist but should be overwritten, check the timestamps or you might want to delete them beforehand just to be sure). If you skip this step, the device will boot the 1st time but then the optimization files will be generated and saved in /data/dalvik-cache/. On any subsequent boot, an attempt to load these files from an "untrusted" location by the system will throw a fatal error and the Zygote process will die with the message: "Executing untrusted code from [...]". If you somehow find yourself in this predicament, delete the following files and reboot to temporarily make it work one more time:
/data/dalvik-cache/arm64/s[email protected][email protected]@classes.dex
/data/dalvik-cache/arm64/[email protected][email protected]@classes.vdex
Further Steps
These are not all the required steps to install MicroG on an official LineageOS installation. You still want to, in particular:
Install at least the main MicroG app (GmsCore) and a dummy signature spoofing APK (also attached to this post) as priv-apps
Set up the priv-app permissions accordingly – otherwise you'll get a bootloop
Likely also install FakeStore, Aurora Store/F-Droid, and location backends of your choice, etc.
However: this is a simple solution to perhaps the most cumbersome aspect of signature spoofing. It's not necessary to resort to Xposed modules to get it working on Android 12, or to depend on a special build with the spoofing patched in at compilation time.
Credit: The patch .smali code has been reverse-engineered from the spoofing patch for LineageOS for MicroG builds.
Click to expand...
Click to collapse
I followed your steps for my OnePlus 8T on Lineage 19.1 and the signature spoofing app says disabled. When recompiling the system.jar with the new file copy and pasted in classes 2 the new system.jar is smaller than the original. Perhaps there is the issue with spoofing. Any information on this matter is much appreciated. Thank you for a great post btw.
Below is the attachment recompiled, perhaps some one else maybe interested in giving it a try or to just examine and find where the error may exist or to conclude it's my own error in recompiling.

JedidroidX said:
I followed your steps for my OnePlus 8T on Lineage 19.1 and the signature spoofing app says disabled. When recompiling the system.jar with the new file copy and pasted in classes 2 the new system.jar is smaller than the original. Perhaps there is the issue with spoofing. Any information on this matter is much appreciated. Thank you for a great post btw.
Below is the attachment recompiled, perhaps some one else maybe interested in giving it a try or to just examine and find where the error may exist or to conclude it's my own error in recompiling.
Click to expand...
Click to collapse
Don't use signature spoofing app. The only relevant measure of success is microG self-check. Use an installer to make microG a system app.

JedidroidX said:
I followed your steps for my OnePlus 8T on Lineage 19.1 and the signature spoofing app says disabled. When recompiling the system.jar with the new file copy and pasted in classes 2 the new system.jar is smaller than the original. Perhaps there is the issue with spoofing. Any information on this matter is much appreciated. Thank you for a great post btw.
Below is the attachment recompiled, perhaps some one else maybe interested in giving it a try or to just examine and find where the error may exist or to conclude it's my own error in recompiling.
Click to expand...
Click to collapse
I don't see any attachment (seems you edited your post) but I guess you recompiled it fine. If you didn't, the device would have ended up in a bootloop (Zygote process wouldn't start), so you'd definitely know. It should be services.jar though, not * system.jar, so maybe you didn't install it properly? Smaller file size is expected, since the repackaged version uses stronger compression as a ZIP file, so nothing to worry about. Again, if there's any problem with the modified services.jar, the device wouldn't get past the boot animation.
I'm not sure what you mean exactly by "signature spoofing app says disabled." It's not an actual app: it doesn't have any code, and won't show up in Launcher. Its only purpose is to add this permission. That being said, if you go into: Settings → Apps → See all ... apps → ⋮ → Show system → Signature Spoofing, there should be a button saying Disable (meaning it's enabled now), and not Enable (which would mean it were disabled at the time). Also, if you go further from that screen into Permissions → Additional permissions → Signature spoofing it should say Allow for this app, and when you click See all apps with this permission, it should show microG Services Core there as Allowed. If you set it up well this is all done automatically with the configuration files, you shouldn't have to go through the settings to change anything via the UI.
As I wrote in the original post, additional steps are required to fully set up MicroG, which is really outside the scope of this thread. These are, for the most part, the same steps as if you were using oF2pks's patch for Android 11 with Lanchon's DexPatcher except more recently you also have to add android.permission.MANAGE_USB to com.gooogle.android.gms (that is, MicroG Services Core) privapp-permissions, or you'll end up with a bootloop for a wholly different reason.
This topic is vast, and there are multiple ways to do it. Note that these should be installed as system apps, some of them as priv-apps, so there are many things that can go wrong. If you don't grant a priv-app all the required permissions through the configuration, now (as of Android 9 I think) you'll get a bootloop. For system apps, you also have to extract libraries (if any) from APKs and place them separately on the filesystem, and make sure you get the details right for the architecture: if you don't, you get... guess what (a bootloop). It's good to have a script automating all this: I have my own flashable ZIP specific to my needs but there are other more general solutions. Or, if you want to learn how to do this manually, one way would be to compare a vanilla LineageOS image with LineageOS for MicroG for the same device around the same build date and see what they are doing extra. On Windows you can use WinMerge to compare files and entire directory structures easily. But again, this is really outside the scope of this thread, which is about patching services.jar for signature spoofing support. No matter how you implement signature spoofing, you still have to figure out those other steps separately.

kurtn said:
Don't use signature spoofing app.
Click to expand...
Click to collapse
Actually, with this approach, Signature Spoofing app has to be used. This is to keep the patch as lean as possible (since it's easier to install a separate app rather than keep maintaining a more complicated patch).
It's not needed with LineageOS for MicroG, where it's already incorporated into the system (lines 1-82 in the patch): https://github.com/lineageos4microg...atches/android_frameworks_base-S.patch#L1-L82

Aqq123 said:
I don't see any attachment (seems you edited your post) but I guess you recompiled it fine. If you didn't, the device would have ended up in a bootloop (Zygote process wouldn't start), so you'd definitely know. It should be services.jar though, not * system.jar, so maybe you didn't install it properly? Smaller file size is expected, since the repackaged version uses stronger compression as a ZIP file, so nothing to worry about. Again, if there's any problem with the modified services.jar, the device wouldn't get past the boot animation.
I'm not sure what you mean exactly by "signature spoofing app says disabled." It's not an actual app: it doesn't have any code, and won't show up in Launcher. Its only purpose is to add this permission. That being said, if you go into: Settings → Apps → See all ... apps → ⋮ → Show system → Signature Spoofing, there should be a button saying Disable (meaning it's enabled now), and not Enable (which would mean it were disabled at the time). Also, if you go further from that screen into Permissions → Additional permissions → Signature spoofing it should say Allow for this app, and when you click See all apps with this permission, it should show microG Services Core there as Allowed. If you set it up well this is all done automatically with the configuration files, you shouldn't have to go through the settings to change anything via the UI.
As I wrote in the original post, additional steps are required to fully set up MicroG, which is really outside the scope of this thread. These are, for the most part, the same steps as if you were using oF2pks's patch for Android 11 with Lanchon's DexPatcher except more recently you also have to add android.permission.MANAGE_USB to com.gooogle.android.gms (that is, MicroG Services Core) privapp-permissions, or you'll end up with a bootloop for a wholly different reason.
This topic is vast, and there are multiple ways to do it. Note that these should be installed as system apps, some of them as priv-apps, so there are many things that can go wrong. If you don't grant a priv-app all the required permissions through the configuration, now (as of Android 9 I think) you'll get a bootloop. For system apps, you also have to extract libraries (if any) from APKs and place them separately on the filesystem, and make sure you get the details right for the architecture: if you don't, you get... guess what (a bootloop). It's good to have a script automating all this: I have my own flashable ZIP specific to my needs but there are other more general solutions. Or, if you want to learn how to do this manually, one way would be to compare a vanilla LineageOS image with LineageOS for MicroG for the same device around the same build date and see what they are doing extra. On Windows you can use WinMerge to compare files and entire directory structures easily. But again, this is really outside the scope of this thread, which is about patching services.jar for signature spoofing support. No matter how you implement signature spoofing, you still have to figure out those other steps separately.
Click to expand...
Click to collapse
Yes sir, I meant the services.jar, silly me I was writing in a rush. Sorry about that confusion.
I will try again and post the result. I guess I will use the same services.jar, however the issue with optimization. I did reboot several times after flashing a cache optimization module for magisk after I adb the services.jar because I'm not familiar on how to do the optimization manually.
The optimization module did lead to magisk not loading the modules and only booted successfully due to magisk bootloop protector module.
Also to adjust permissions to 644 I presume is already in the recompiled services.jar? As I could not view what permission with mixplorer that it had.
Btw, the signature spoofing app is an app I downloaded from f- droid that just displays the signature spoofing status, if disabled or enabled and it says disabled. Again sorry about the confusing and thank you again for your great feedback.

Hi,
would like to try on AOSP 12 GSI, installed over stock OOS10 On Nord (avicii).
@Aqq123 Do you think i can make it ? Any suggestion before starting ?
What about if i get service.jar from a GSI AOSP with google apps ? Maybe signature spoofing is altredy implemented there ?

kidronvalley said:
Hi,
would like to try on AOSP 12 GSI, installed over stock OOS10 On Nord (avicii).
@Aqq123 Do you think i can make it ? Any suggestion before starting ?
What about if i get service.jar from a GSI AOSP with google apps ? Maybe signature spoofing is altredy implemented there ?
Click to expand...
Click to collapse
Most gsi have signature spoofing feature.

Hi @kurtn
thanks,
heh, this AOSP 12 vanilla from PHH treble seems not, at least, microg is not detecting it, and one specific banking app is failing to work.
EDITED: I solved all installing PHH trebvle A12 "floss" that has signature spoofing up and running.

hi, @Aqq123 i applied the guide you wrote for lineage os 19.1 s10e (or so I think),
your attached:
I opened the PackageManagerService$ComputerEngine.smali file with notepad++,
.method private static applyFakeSignature(Lcom/android/server/pm/parsing/pkg/AndroidPackage;Landroid/content/pm/PackageInfo;Ljava/util/SetLandroid/content/pm/PackageInfo;
.method private static getRequestedFakeSignature(Lcom/android/server/pm/parsing/pkg/AndroidPackageLjava/lang/String;
I copied the code to where it says .end method and pasted it anywhere in my services.jar.
I deleted the next text where it says generatePackageInfo( and added the code that says applyFakeSignature( after it), and saved it and repackaged it as you said above.
I put it in the phone's memory and gave rw r r permissions in the system fremework with root explorer and restarted it. but the system went into bootloop.
I did a lineage os install from scratch after failing here.
I copied the PackageManagerService$ComputerEngine.smali file you provided,
I deleted the original PackageManagerService$ComputerEngine.sma in services.jar.
I pasted yours and repackaged it with the packaging code you wrote above (only apktool2 does not work for me, it works as apktool, does that cause the problem?) and I added the system to fremework and restarted the device once the device turned on but micro g and spoofing checker apk shows signature patch not applied .
and on the 2nd reboot, it naturally enters the bootloop as you said.
i didn't understand how to implement the following path, if i did that it wouldn't go into bootloop.
QUOTE: You have to generate the optimization files and place them in the correct location, which is /system/framework/oat/arm64/:
dex2oat --dex-file=/system/framework/services.jar --instruction-set=arm64 --oat-file=/system/framework/oat/arm64/services.odex
now i have 3 questions:
1. why did my patch to original smali fail (bootloop even on first boot)?
2. Why isn't the smali file you provided spoofing?
3. The file you gave does not bootloop the 1st time, but it does it for the 2nd time. What should I do to fully understand the above fix code?

ahmadmahmood2048 said:
hi, @Aqq123 i applied the guide you wrote for lineage os 19.1 s10e (or so I think),
your attached:
I opened the PackageManagerService$ComputerEngine.smali file with notepad++,
.method private static applyFakeSignature(Lcom/android/server/pm/parsing/pkg/AndroidPackage;Landroid/content/pm/PackageInfo;Ljava/util/SetLandroid/content/pm/PackageInfo;
.method private static getRequestedFakeSignature(Lcom/android/server/pm/parsing/pkg/AndroidPackageLjava/lang/String;
I copied the code to where it says .end method and pasted it anywhere in my services.jar.
I deleted the next text where it says generatePackageInfo( and added the code that says applyFakeSignature( after it), and saved it and repackaged it as you said above.
I put it in the phone's memory and gave rw r r permissions in the system fremework with root explorer and restarted it. but the system went into bootloop.
I did a lineage os install from scratch after failing here.
I copied the PackageManagerService$ComputerEngine.smali file you provided,
I deleted the original PackageManagerService$ComputerEngine.sma in services.jar.
I pasted yours and repackaged it with the packaging code you wrote above (only apktool2 does not work for me, it works as apktool, does that cause the problem?) and I added the system to fremework and restarted the device once the device turned on but micro g and spoofing checker apk shows signature patch not applied .
and on the 2nd reboot, it naturally enters the bootloop as you said.
i didn't understand how to implement the following path, if i did that it wouldn't go into bootloop.
QUOTE: You have to generate the optimization files and place them in the correct location, which is /system/framework/oat/arm64/:
dex2oat --dex-file=/system/framework/services.jar --instruction-set=arm64 --oat-file=/system/framework/oat/arm64/services.odex
now i have 3 questions:
1. why did my patch to original smali fail (bootloop even on first boot)?
2. Why isn't the smali file you provided spoofing?
3. The file you gave does not bootloop the 1st time, but it does it for the 2nd time. What should I do to fully understand the above fix code?
Click to expand...
Click to collapse
Use lineage.microg.org