Related
Hi to everyone,
I would like to reply to this post about a force close entering the UsbSettings in broodRom RC5 rev 1 & 2(prerelease).
Specifically the exception is this: java.lang.RuntimeException: Unable to start activity ComponentInfo{com.android.settings/com.android.settings.UsbSettings}: java.lang.NumberFormatException: unable to parse '' as integer
Unfortunately I'm not able to post there since I've just registered my accout; I hope this is the best section to post and that someone will notice it anyway.
After a couple of hours of serious digging I found that the problem depends on the fact that build prop lacks:
Code:
persist.service.usb.setting=0
which sets the default mode (kies) for usb.
that value is requested by com.android.settings.UsbSettings.onCreate of Settings.apk
Code:
protected void onCreate(Bundle paramBundle)
{
super.onCreate(paramBundle);
int i = Integer.parseInt(SystemProperties.get("persist.service.usb.setting"));
this.mUSB_mode = i;
---cut---
restoring the above line in build prop fixes the issue!
yota73 said:
Hi to everyone,
I would like to reply to this post about a force close entering the UsbSettings in broodRom RC5 rev 1 & 2(prerelease).
Specifically the exception is this: java.lang.RuntimeException: Unable to start activity ComponentInfo{com.android.settings/com.android.settings.UsbSettings}: java.lang.NumberFormatException: unable to parse '' as integer
Unfortunately I'm not able to post there since I've just registered my accout; I hope this is the best section to post and that someone will notice it anyway.
After a couple of hours of serious digging I found that the problem depends on the fact that build prop lacks:
Code:
persist.service.usb.setting=0
which sets the default mode (kies) for usb.
that value is requested by com.android.settings.UsbSettings.onCreate of Settings.apk
Code:
protected void onCreate(Bundle paramBundle)
{
super.onCreate(paramBundle);
int i = Integer.parseInt(SystemProperties.get("persist.service.usb.setting"));
this.mUSB_mode = i;
---cut---
restoring the above line in build prop fixes the issue!
Click to expand...
Click to collapse
Thanks! , I saw it before but didn't knew if this was the right fix^^
thanks for the solution..im sorry but im newbie but where to locate that in the script manager?im still learning about this android..thanks
The file is /system/build.prop, you need to be root to edit it and to mount /system read write.
Both things are enabled by default in broodrom, and any detail can be easily found by searching the forum.
Please note that this has nothing to do with scriptmanager and is best achieved though ADB.
If you have not the android SDK installed, maybe it would be better if you just wait Rev 2, which hopefully will integrate the fix
Colors fixes
Hi brood,
still posting here until I (if ever) reach 10 posts.
I've managed to fix color-issue (at least for most colors) in your rom by editing the twframework-res.apk.
It seems that samsung apps are using it instead of framework-res.apk.
The quickest way to improve the situation is modify .xmls that are using tw_color002 to use tw_color001 instead.
As you can see in /res/values/colors.xml tw_color002 is black while tw_color001 is white.
Obviously there is not one unique solution, but is more a matter of choosing the right palette to fit with the dark theme, either by changing color reference in each xml or by changing them all at once in /res/values/colors.xml
I hope this can help!
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
You can use this link to find your model:
http://opensource.lge.com/osSch/list?types=NAME&search=G710 <<< Find your model, you must use Linux to compile this code.
Models:
LMG710N - USA model (Carrier unlocked model)
LMG710PM - Pre-release codename Judy
LMG710PS - ?
LMG710AWM - Likely this was the AT&T model that was changed to the V35 ThinQ
LMG710TM - T-Mobile model
LMG710VM - Verizon model
The files are coded with R, P, & X which I am guessing is Release Candidate, Production, and scrapped version.
The readme files are really helpful in explaining how to compile the software.
Under the bootloader section:
This product includes cryptographic software written by "EDITED for Psuedo Privacy". This product includes software written by "EDITED for Psuedo Privacy".
I figured that we could either create a custom bootloader that's NOT encrypted, but still follows the same boot up process. If bootup requires an encryption, then we could set the the process to accept anything, for example: if encryption = 1 or 0 then proceed to bootup.
I hope this helps development on this phone in creating a kernel, custom roms, etc...
But your links are about LG G7, and we are speaking here on Q7
Searching for the 610I at that sure produces a result for the Q 610ta10s that I am on.
source Q7+ Japan http://opensource.lge.com/osSch/list?types=NAME&search=03K
One of my favorite features of the S8 is the Dex feature, that lets me use the phone as a basic computer. I was very disappointed when I saw that the Linux on Dex (LoD) beta is only available for the Note 9 and Tab S4.
This is a stupid software limitation, I don't see any other reason why the S8 - even with Android Pie - wouldn't run LoD. It was even used for the first demos (around one year ago)!
The aim of this thread is to try to remove this limitation and run Linux on Dex on our Galaxy S8.
We already managed to remove the limitation for the need of the Dex dock, hope this will also be a success!
As I'm not an experienced Java developer, I won't be able to solve this thing alone. Hope that other developers will also join this project!
Ok, here are my first steps:
- Downloaded, installed and ran the latest APK (1.0.49): https://forum.xda-developers.com/showpost.php?p=78734115&postcount=226
Error message: Your device is not supported. Please visit www.linuxondex.com for more details.
- Modified the model in build.prop to SM-N960
Error message: Linux on DeX requires your device to have the latest software to support some features.
So there is a change, but not enough.
Now, I decompiled the APK with apktool. The source is in smali bytecode format, but it can be transformed to java.
The device detection code is in the file smali/com/samsung/android/lxd/a/i.smali. It checks the device name for TABS4, CROWN (Note9), STAR2 (S9+*), WINNER (Fold), BEYOND (S10). Can someone add the DREAMLTE/DREAM2LTE and recompile?
* Why only the S9+ (star2) and not the S9 (star)? This is just stupid.
I am using customs rom, with Android PIE
I can load into the apps and while i click the "create" button to build .img file, it just shows me "please wait" and no response.
alan9820 said:
I am using customs rom, with Android PIE
I can load into the apps and while i click the "create" button to build .img file, it just shows me "please wait" and no response.
Click to expand...
Click to collapse
What custom ROM and LoD version are you using?
BTW, you can find prebuilt IMG files in the Note9 LinuxOnDex thread.
kbarni said:
Ok, here are my first steps:
- Downloaded, installed and ran the latest APK (1.0.49): https://forum.xda-developers.com/showpost.php?p=78734115&postcount=226
Error message: Your device is not supported. Please visit www.linuxondex.com for more details.
- Modified the model in build.prop to SM-N960
Error message: Linux on DeX requires your device to have the latest software to support some features.
So there is a change, but not enough.
Now, I decompiled the APK with apktool. The source is in smali bytecode format, but it can be transformed to java.
The device detection code is in the file smali/com/samsung/android/lxd/a/i.smali. It checks the device name for TABS4, CROWN (Note9), STAR2 (S9+*), WINNER (Fold), BEYOND (S10). Can someone add the DREAMLTE/DREAM2LTE and recompile?
* Why only the S9+ (star2) and not the S9 (star)? This is just stupid.
Click to expand...
Click to collapse
I've tried to modify i.smali to return "STAR2" (for any device) but it fails on another check and returns:
Error message: Linux on DeX requires your device to have the latest software to support some features.
3mpty said:
I've tried to modify i.smali to return "STAR2" (for any device) but it fails on another check and returns:
Error message: Linux on DeX requires your device to have the latest software to support some features.
Click to expand...
Click to collapse
Yep...it seems that there are other limitations too. This "latest software" is just stupid; for example the S8 Pie has newer software than the Note9 had when the first LoD beta was released (1.0.38, in last November), still it complains for old software. I wonder if it will work when devs will integrate S10 APKs in S8 rom...
kbarni said:
Yep...it seems that there are other limitations too. This "latest software" is just stupid; for example the S8 Pie has newer software than the Note9 had when the first LoD beta was released (1.0.38, in last November), still it complains for old software. I wonder if it will work when devs will integrate S10 APKs in S8 rom...
Click to expand...
Click to collapse
This 'latest software' may be caused by other issue - SELinux. After running self build & signed version my logcat is full of such entries:
Code:
2019-02-27 13:19:32.590 5156-5156/? E/audit: type=1400 audit(1551269972.589:3628): avc: denied { read } for pid=6318 comm="ung.android.lxd" name="u:object_r:lxd_prop:s0" dev="tmpfs" ino=3505 scontext=u:r:untrusted_app:s0:c168,c258,c512,c768 tcontext=u:object_r:lxd_prop:s0 tclass=file permissive=0 SEPF_SM-G950F_9_0001 audit_filtered
2019-02-27 13:19:32.590 5156-5156/? E/audit: type=1300 audit(1551269972.589:3628): arch=c00000b7 syscall=56 success=no exit=-13 a0=ffffff9c a1=7fe33851f8 a2=88000 a3=0 items=0 ppid=5167 pid=6318 auid=4294967295 uid=10680 gid=10680 euid=10680 suid=10680 fsuid=10680 egid=10680 sgid=10680 fsgid=10680 tty=(none) ses=4294967295 comm="ung.android.lxd" exe="/system/bin/app_process64" subj=u:r:untrusted_app:s0:c168,c258,c512,c768 key=(null)
2019-02-27 13:19:32.590 5156-5156/? E/audit: type=1327 audit(1551269972.589:3628): proctitle="com.samsung.android.lxd"
2019-02-27 13:19:32.591 6318-6318/? E/libc: Access denied finding property "lxd.vmdebugmode"
And because those properties cannot be read it fallbacks to default values.
Unfortunately I'm using official Pie rom for S8 without root etc.
3mpty said:
This 'latest software' may be caused by other issue - SELinux. After running self build & signed version my logcat is full of such entries:
Unfortunately I'm using official Pie rom for S8 without root etc.
Click to expand...
Click to collapse
I'm not sure it's SELinux. It should run on stock rom. In the message you posted, it complains also for untrusted app.
I tried LoD 1.0.38, which also stops with "Update your software", and didn't find anything similar in Logcat.
Can you share your modded LoD APK, so I can test it? I have rooted S8 with Pie and Alexis 7.4 rom.
kbarni said:
I'm not sure it's SELinux. It should run on stock rom. In the message you posted, it complains also for untrusted app.
I tried LoD 1.0.38, which also stops with "Update your software", and didn't find anything similar in Logcat.
Can you share your modded LoD APK, so I can test it? I have rooted S8 with Pie and Alexis 7.4 rom.
Click to expand...
Click to collapse
I'm also not sure if it was SELinux but orginal apk doesn't throw such logs into logcat. Checkout attached apk.
3mpty said:
I'm also not sure if it was SELinux but orginal apk doesn't throw such logs into logcat. Checkout attached apk.
Click to expand...
Click to collapse
Thanks!
I checked it, I don't have the untrusted app message, I have several of these:
Code:
libc [E] Access denied finding property "lxd_vmdebugmode"
However I find this part of the logcat more interesting:
Code:
LxD_o [I] isSupportedBinary: binary version: 1, required version: 4
LxDEntryActivity [E] NonSupportedBinary:
Taking a look at o.smali, the "binary version" is given by the function: com.samsung.android.lxd.processor.utils.Utils.getNstVersion ( );
This points to Utils.smali where it returns android.os.SemSystemProperties .getInt ( "linux_on_dex_version",1); if I understand correctly.
And that leads us to the kernel, probably related to /include/linux/linux_on_dex.h
Can you check this? Do you agree?
I'll investigate the kernel part. I suspect that the kernel has LoD support, but it reports LoD version 1, and the beta won't start unless this number is higher or equal to 4. I don't know if there are other kernel differences, have to dig myself in the Note9 kernel too.
Can you check what happens if you modify the o.smali file, to compare the result of getNstVersion with 1 (set v2 to 0x01 in .line 634)? If you can do this, rebuild the APK, repost it and report back please!
I feel we are getting closer to soething!
I've changed `getNstVersion` default result to 4 instead 1 and it will allow to continue. This method is called later in o.smali:
Code:
/**
* This method checks if device supports LoD, it compares linux_on_dex_version system var with
* 5 (tablet) and 4 (phone). If linux_on_dex_version value is smaller than 5 or 4 this device
* will not support LoD.
*
* @return true if device is supported
*/
public static boolean isSupportedBinary() {
boolean isAlreadyAuthorized = g();
boolean isSupportedBinary = true;
if (isAlreadyAuthorized) {
return true;
} else {
int deviceNstVersion = Utils.getNstVersion();
byte requiredNst;
if (isTablet()) {
requiredNst = 5;
} else {
requiredNst = 4;
}
String var4 = a;
StringBuilder var5 = new StringBuilder();
var5.append("isSupportedBinary: binary version: ");
var5.append(deviceNstVersion);
var5.append(", required version: ");
var5.append(requiredNst);
Log.i(var4, var5.toString());
if (deviceNstVersion < requiredNst) {
isSupportedBinary = false;
}
return isSupportedBinary;
}
}
Unfortunately is not enough. App crashes in few moments when it tries to modify system properties:
Code:
Caused by: java.lang.RuntimeException: failed to set system property
at android.os.SystemProperties.native_set(Native Method)
at android.os.SystemProperties.set(SystemProperties.java:183)
at android.os.SemSystemProperties.set(SemSystemProperties.java:111)
at com.samsung.android.lxd.EntryActivity.R(EntryActivity.java:294)
at com.samsung.android.lxd.EntryActivity.P(EntryActivity.java:183)
at com.samsung.android.lxd.EntryActivity.S(EntryActivity.java:329)
at com.samsung.android.lxd.EntryActivity.onCreate(EntryActivity.java:150)
at android.app.Activity.performCreate(Activity.java:7327)
at android.app.Activity.performCreate(Activity.java:7318)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1271)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3088)
Looks like it's the same issue that doesn't allow to read those properties first (at least it's my guess). I've attached apk after 2nd modification.
3mpty said:
Looks like it's the same issue that doesn't allow to read those properties first (at least it's my guess). I've attached apk after 2nd modification.
Click to expand...
Click to collapse
I confirm, I have the same error.
I think it wants to set a system property in file EntryActivity.smali (linux_on_dex.LoD_image and linux_on_dex.LoD_image_P_initial) that's not implemented (maybe in kernel?).
BTW, I'm really curious about reports of LoD working on S8/Note8 etc; @alan9820 and others: what ROM/kernel/LoD version are you using?
Hey guys! I made some interesting progress!
Installing the NX 22.1 kernel allowed me to start the (modified) app! After the welcome page, I could get to the "Create container" page, but when I select the .IMG file, it stays blocked at the "Please wait..." screen. So I guess I'm stuck in the same position as alan9820 (post #3 in the topic).
If I restart the creation of the container, it gives "Unexpected error: Something went wrong. Please close Linux on Dex and try again".
The only LoD related error messages from logcat are:
Code:
LxD_NstControlChannelV1 [E] Failed to connect to server!
LxD_NstControlChannelV1 [E] ControlThread: com.samsung.lxd.processor.LxdEception: Failed to connect to server!, socket status: false
kbarni said:
BTW, I'm really curious about reports of LoD working on S8/Note8 etc; @alan9820 and others: what ROM/kernel/LoD version are you using?
Click to expand...
Click to collapse
I used S8 exynos version G950F
With android customs rom of Hades PIE ROM v3.0
I just google linux on dex apk from apkmirror and download
Repeat that i am able to open the app and choose image
But i am failed to create image just giving me "please wait" msg.
---------- Post added at 07:10 AM ---------- Previous post was at 07:08 AM ----------
kbarni said:
What custom ROM and LoD version are you using?
BTW, you can find prebuilt IMG files in the Note9 LinuxOnDex thread.
Click to expand...
Click to collapse
I alrrady flashed back to Oreo rom, PIE rom is not as smooth as 8.0 currently ... haha
Some more progress: There is a switch in the kernel parameters cooncerning LinuxOnDex: CONFIG_LOD_SEC. I enabled it and recompiled the NX kernel.
Unfortunately it's the same error, the container cannot be built, it gives only an unspecified error. Nothing in Logcat.
I checked the Note9 kernels, but there is no important difference (especially in LoD part).
The unpatched APK files still give the Unsupported software error.
I wonder if the error occurs because of insufficient RAM for building the container??? The main difference between the S9+, Note9, Tab S4 vs. S8 and S9 is that the first group has 6GB of RAM.
[edit] Tried to increase the memory size by 2GB by adding swap, still doesn't work.
kbarni said:
Some more progress: There is a switch in the kernel parameters cooncerning LinuxOnDex: CONFIG_LOD_SEC. I enabled it and recompiled the NX kernel.
Unfortunately it's the same error, the container cannot be built, it gives only an unspecified error. Nothing in Logcat.
I checked the Note9 kernels, but there is no important difference (especially in LoD part).
The unpatched APK files still give the Unsupported software error.
I wonder if the error occurs because of insufficient RAM for building the container??? The main difference between the S9+, Note9, Tab S4 vs. S8 and S9 is that the first group has 6GB of RAM.
[edit] Tried to increase the memory size by 2GB by adding swap, still doesn't work.
Click to expand...
Click to collapse
I have a S8+ Korean version (with 6gb ram) willing to test your modified version to see if it works.
brick5492 said:
I have a S8+ Korean version (with 6gb ram) willing to test your modified version to see if it works.
Click to expand...
Click to collapse
You can install the kernel below (modified NX 22.1) and the apk from 3mpty's post (the modified_v2).
The app should start, the question is if you can create the container or if it gives an unspecified error.
Thanks for testing and please report back your results!
kbarni said:
You can install the kernel below (modified NX 22.1) and the apk from 3mpty's post (the modified_v2).
The app should start, the question is if you can create the container or if it gives an unspecified error.
Thanks for testing and please report back your results!
Click to expand...
Click to collapse
I'm really sorry, but my S8+ is not rooted and on the factory image (still Oreo, didnt recieve Pie yet) and I wish to leave it stock since it's my primary (work) device. I guess I can't install that kernel with the locked bootloader on Oreo right? And I do need the kernel for that modified Dex to work?
I did install the apk and after it granting permissions, it just force closes. I'm on the October security patch.
brick5492 said:
I'm really sorry, but my S8+ is not rooted and on the factory image (still Oreo, didnt recieve Pie yet) and I wish to leave it stock since it's my primary (work) device. I guess I can't install that kernel with the locked bootloader on Oreo right? And I do need the kernel for that modified Dex to work?
I did install the apk and after it granting permissions, it just force closes. I'm on the October security patch.
Click to expand...
Click to collapse
LoD related changes were introduced in Pie kernel, so this won't work on Oreo.
What is this tutorial?
This tutorial will:
Creating an unofficial build of LineageOS 19.1 suitable for using to re-lock the bootloader on a Google Pixel 5
Take you through the process of re-locking your bootloader after installing the above
This tutorial will NOT:
Remove *all* warning messages during boot (the yellow "Custom OS" message will be present though the orange "Unlocked bootloader" message will not)
Allow you to use official builds of LineageOS 19.1 on your device with a re-locked bootloader (more details near the end of the tutorial)
This tutorial will assume you are working on an Ubuntu 20.04 installation, if you are using Windows or another Linux distro, the commands may be different or not work at all.
Supported devices:
The following devices have been tested and confirmed to work:
OnePlus 5T (dumpling)
OnePlus 6 (enchilada)
OnePlus 6T (fajita)
OnePlus 7 (guacamoleb)
OnePlus 7 Pro (guacamole)
Google Pixel 4 (flame)
Google Pixel 5 (redfin)
Note: As of OxygenOS 12, OnePlus no longer supports bootloader relocking with custom keys, as such, any OnePlus device that receives official Android 12 and has LineageOS 19.1 based on it (which include the 8/8T/9 models) cannot be supported.
For simplicities sake, all further references will only be to the Google Pixel 5 (redfin).
Pre-requisites:
a mid level knowledge of terminal commands and features
a supported phone
a PC with enough CPU/RAM to build LineageOS 19.1 (recommended 8 cores, 32g of RAM)
a working USB cable
fastboot/adb installed and functional
LineageOS 19.1 source code downloaded
at least one successful build of LineageOS
at least one successful signing of your build with your own keys
Misc. notes:
the basics of building/signing of LineageOS is outside the scope of this tutorial, refer to the LineageOS Wiki (https://wiki.lineageos.org/devices/redfin/build) for details on how to complete these tasks
if you have generated your signing keys at some significant time in the past, you may have generated 2048 bit keys. 4096 bit keys are now supported and recommended, so you may want to generate new keys for LineageOS 19.1. If you decided to continue to use the 2048 bit keys make sure to make the appropriate changes in step 2 and 3 below.
signing with keys that have passwords set can cause problems, the easiest way around this is to *not* set a password when you generate your signing keys, however this does add risk that if your key files are stolen, no password is required to use them.
you'll be modifying some code in LineageOS, so if you are not comfortable using basic editing utilities as well as patch, do not proceed any further
the path to your LineageOS source code is going to be assumed to be ~/android/lineageos, if it is somewhere else, substitute the correct path in the tutorial
the path to your private certificate files is going to be assumed to be ~/.android-certs, if it is somewhere else, substitute the correct path in the tutorial
*** WARNING ****
This process may brick your device. Do not proceed unless you are comfortable taking this risk.
*** WARNING ****
This process will delete all data on your phone! Do not proceed unless you have backed up your data!
*** WARNING ****
Make sure you have read through this entire process at least once before attempting, if you are uncomfortable with any steps include in this guide, do not continue.
And now on with the show!
Step 1: Basic setup
You need a few places to store things, so create some working directories:
Code:
mkdir ~/android/redfin
mkdir ~/android/redfin/patches
mkdir ~/android/redfin/pkmd
You also need to add "~/android/lineageos/out/host/linux-x86/bin" to your shell's profile path. Make sure to close and restart your session afterwards otherwise the signing will fail later on with a "file not found" error message (this may no longer be required).
Step 2: Update the signing keys to use & enable AVB
The Pixel 5 device files are mostly contained in the shared "redbull" device for the Pixel 5 and 5 Pro. You will need to add a few parameters to the shared make file found here: ~/android/lineageos/device/google/redbull/BoardConfigLineage.mk, they are:
Code:
BOARD_AVB_ALGORITHM := SHA256_RSA4096
BOARD_AVB_KEY_PATH := /home/<userid>/.android-certs/releasekey.key
Note you cannot use "~" in the path names above to signify your home directory, so give the full absolute path to make sure the files are found.
LineageOS by default disables Android Verified Boot's partition verification, but you can enable it now as all the required parts will be in place.
To enable partition verification do the following:
Code:
cd ~/android/lineageos/device/google/redbull
sed -i 's/^BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS += --flags 3/#BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS += --flags 3/' BoardConfigLineage.mk
Step 3: Set the AVB key to use
To set the correct signing key to use for AVB, do the following:
Code:
cd ~/android/lineageos/device/google/redbull
sed -i 's/external\/avb\/test\/data\/testkey_rsa2048.pem/\/home\/<userid>\/.android-certs\/releasekey.key/' BoardConfig-common.mk
sed -i 's/SHA256_RSA2048/SHA256_RSA4096/' BoardConfig-common.mk
Don't forget to replace your <userid> in the first sed command above with your current logged in user id.
Step 4: Patch the AOSP and Device Makefile
You also need to patch the Makefile included with AOSP as it will otherwise fail during the build.
The required patch can be found here:
https://raw.githubusercontent.com/Wunderment/build_tasks/master/source/core_Makefile-19.1.patch
Download it and store in ~/android/redfin/patches.
Now apply it with the following command:
Code:
cd ~/android/lineageos/build/core
patch Makefile ~/android/redfin/patches/core-Makefile-fix-19.1.patch
If you would like to know more about this patch, see the additional info at the bottom of this post.
Step 5: Build LineageOS
You are now ready to build:
Code:
cd ~/android/lineageos
source build/envsetup.sh
breakfast redfin
croot
mka target-files-package otatools
Step 6: Sign the APKs
You are now ready to sign the apks with sign_target_files_apks:
Code:
./build/tools/releasetools/sign_target_files_apks -o -d ~/.android-certs $OUT/obj/PACKAGING/target_files_intermediates/*-target_files-*.zip signed-target_files.zip
Step 7: Build the OTA
Now it is time to complete the OTA package:
Code:
./build/tools/releasetools/ota_from_target_files -k ~/.android-certs/releasekey --block signed-target_files.zip lineage-19.1-[date]-UNOFFICIAL-redfin-signed.zip
Note, replace [date] with today's date in YYYYMMDD format.
Step 8: Create pkmd.bin for your phone
Before you can lock your phone, you have to tell it what your public key is so it knows it can trust your build.
To do this you need to create a pkmd.bin file:
Code:
~/android/lineageos/external/avb/avbtool extract_public_key --key ~/.android-certs/releasekey.key --output ~/android/redfin/pkmd/pkmd.bin
Note: if you don't have a releasekey.key file in your certificate directory, use the following command to generate one:
Code:
openssl pkcs8 -in releasekey.pk8 -inform DER -out releasekey.key -nocrypt
Step 9: Flashing your LineageOS build
It's time to flash your build to your phone. The following steps assume you have already unlocked your phone and have flashed an official version of LineageOS to it. You don't need to have flashed LineageOS yet, you could use TWRP through "fastboot boot" if you prefer. Or, if you want to use the recovery that was just created, it is located in ~/android/lineageos/out/target/product/redfin and is called vendor_boot.img.
Reboot your phone in to recovery mode
In LineageOS Recovery return to the main menu and select "Apply update", then "Apply from ADB".
From your PC, run:
Code:
adb sideload ~/android/lineageos/lineage-19.1-[date]-UNOFFICIAL-redfin-signed.zip
When the sideload is complete, reboot into LineageOS. Make sure everything looks good with your build.
You may also need to format your data partition at this time depending on what you had installed on your phone previously, it's best to do so anyway. In LineageOS Recovery return to the main menu and select "Factory reset", then "Format data/factory reset", then confirm with "Format data".
Step 10: Flashing your signing key
Now it's time to add your signing key to the Android Verified Boot process. To do so, do the following:
Reboot your phone in to fastboot mode
From your PC, run:
Code:
fastboot flash avb_custom_key ~/android/redfin/pkmd/pkmd.bin
fastboot reboot bootloader
fastboot flashing lock
On your phone, confirm you want to re-lock and it will reboot
Note: If you have already flashed a custom avb key you must erase it before flashing the new one, use "fastboot erase avb_custom_key" to do so.
Your phone will then factory reset and then reboot in to LineageOS.
Which of course means you have to go through the first time setup wizard, so do so now.
Step 11: Disable OEM unlock
Congratulations! Your boot loader is now locked, but you can still unlock it again using fastboot, so it's time to disable that as well.
Unlock you phone and go to Settings->About phone
Scroll to the bottom and find "Build number"
Tap on it you enable the developer options
Go to Settings->System->Advanced->Developer options
Disable the "OEM unlocking" slider
Reboot
Step 12: Profit!
Other things
The above will build a standard USERDEBUG version of LineageOS, however this will still allow LineageOS Recovery to sideload non-signed files as well as give you root shell access through ADB. Step 3/4 above protects your system/vendor/boot/dtbo/etc. partitions, but none of the others. Likewise USERDEBUG builds will allow for rolling back to a previous builds/versions of LineageOS. To increase security and disallow both of these scenarios you may want to build a USER version of LineageOS to install. However this brings in other issues, such as flashing newer firmware from OnePlus so make sure you understand the implications of both choices. For more details on build types, see https://source.android.com/setup/develop/new-device#build-variants.
The above build will not include other items like GAPPS or Magisk. Those are outside the scope of this tutorial.
If you want to remove you signing key from your phone, you can do it by running "fastboot erase avb_custom_key".
The changes you made to the AOSP Makefile may conflict with future updates that you pull from LineageOS through repo sync, if you have to reset the file to get repo sync to complete successfully, you'll have to reapply the changes afterwards.
So why can't I do this with official LineageOS builds?
You can! See https://forum.xda-developers.com/t/...ustom-rom-such-as-lineageos-official.4260825/ for more details.
For Android Verified Boot (AVB) to work, it must have the hash values for each of the system/vendor/boot/dtbo/etc. partitions stored in vbmeta. Official LineageOS builds for redfin do include the vendor.img in them along with everything else that is needed, however that is not true for all phones.
An "issue" that might stop someone from using the official redfin builds is that AVB is enabled in the official LineageOS builds but does not validate the hash trees during boot which limits the protection offered.
Ok, what messages do I see during the boot process then?
During a boot you will of course see the standard OnePlus power up screen, followed by the yellow "custom os" message and then the standard LineageOS boot animation.
For more details on AVB boot messages, see https://source.android.com/security/verifiedboot/boot-flow
So what does that patch to the Makefile do?
AOSP's default Makefile makes an assumption that when AVB is enabled, that all the img files will be available well before vbmeta.img is created. This is simply NOT true and AOSP seems to know this as well from the following comment in the Makefile:
Code:
# Not using INSTALLED_VBMETA_SYSTEMIMAGE_TARGET as it won't be set yet.
ifdef BOARD_AVB_VBMETA_SYSTEM
$(eval $(call check-and-set-avb-args,vbmeta_system))
endif
ifdef BOARD_AVB_VBMETA_VENDOR
$(eval $(call check-and-set-avb-args,vbmeta_vendor))
endif
These two calls eventual evaluate to returning the path to the partitions based upon the INSTALLED_*IMAGE_TARGET variable, which isn't created until later in the build process.
Because of this, the command to build vbmeta.img gets corrupted due to the missing make variable being empty and an invalid command line is passed to avbtool near the end of the build.
The corruption happens due to the fact that the following line from the original Makefile:
Code:
--include_descriptors_from_image $(call images-for-partitions,$(1))))))
Gets added to the avbtool call even if "$(call images-for-partitions,$(1))" turns out to be an empty string. Avbtool then throws an error message as it is expecting a parameter after the "--include_descriptors_from_image" flag that is added for the "empty" partition path.
The fix is to call "$(call images-for-partitions,$(1))" earlier, set it to a variable and check to make sure it isn't an empty string before letting the "--include_descriptors_from_image" be added to the avbtool command line to be used later.
This technically generates an incomplete vbmeta.img file during the build process, but since the signing process recreates it from scratch anyway; no harm, no foul.
Thank-Yous
Obviously to all of the members of the LineageOS team!
aleasto & mikeioannina for supporting redfin
optimumpro for the OnePlus 5/5t re-locking guide which inspired this one
Quark.23 for helping with the process and testing on enchilada
Related guides
OnePlus 5/5t re-locking guide (https://forum.xda-developers.com/oneplus-5/how-to/guide-relock-bootloader-custom-rom-t3849299)
Re-locking the bootloader with a pre-built custom ROM, such as LineageOS official (https://forum.xda-developers.com/t/...ustom-rom-such-as-lineageos-official.4260825/)
Re-locking the bootloader on the OnePlus 6t with a self-signed build of LOS 17.1 (https://forum.xda-developers.com/t/...s-6t-with-a-self-signed-build-of-los.4113743/)
Re-locking the bootloader on the OnePlus 8t with a self-signed build of LOS 18.1 (https://forum.xda-developers.com/t/...with-a-self-signed-build-of-los-18-1.4259409/)
A discussion about bootloader locking/unlocking... AKA I want to relock my bootloader, should I? (over on [reddit]/ r/LineageOS/comments/n7yo7u/a_discussion_about_bootloader_lockingunlocking/) (link broken on purpose to avoid the linked post being embedded here)
Thank you for your guides on bootloader relocking. They have helped to enable bootloader relocking on other devices.
After "all further references will only be to the Google Pixel 5 (redfin)" but before the "Thank-Yous", there are a few (typos?) that refer to the oneplus. In particular, beneath "Other things" and "under what messages do I see during the boot process then?"
HTH
If anyone is interested, I made a tool to automate all this using Hetzner Cloud. This tool's client can pretty much run on anything, including android itself on Termux(since it's a terminal app). You can make the tool upload the finished builds to your private repo so no need to worry about letters from Google for using GAPPS.
Bash:
wget -O ham "https://github.com/antony-jr/ham/releases/download/stable/ham-linux-amd64"
chmod a+x ham
./ham init # Init with your Hetzner Cloud API (Only Once)
./ham get [email protected]/enchilada-los19.1:gapps
# Without gapps
./ham get [email protected]/enchilada-los19.1
# You can close the terminal app after it starts tracking remote build
# the build continues to run on the cloud until finishes or errors out,
# in both cases the server destroys itself to save you a lot of cost.
# It cost me 0.30 euros for single build which ran for about 3 hours.
Thanks for the OP though, I copied a lot of scripts from WundermintOS.
Now the output of the build can be flashed like the OP described for OnePlus 6 and the pkmd.bin file will be included in the recovery zip file along with the boot/recovery image. The tool will ask you question before it starts the build for the variables, like the path to Android Certs in a zip file which will be used for signing.
For anyone that is interested, I've posted an updated guide for LineageOS 20.0 on the Pixel 6 here.