Related
Force-Encrypt Toggler
Disclaimer: I have no experience in Android/ROM development. This is the first time i decided to share something (that i initially made for myself). Flash at your own risk. I am not responsible for boot loops, unexpectedly encrypted partitions, data loses, etc. Make sure you have a backup first!
Click to expand...
Click to collapse
Now that CyanogenMod developers stated that they are going to follow Google's guidelines about forced encryption in their ROM for Nexus 9, those of us who want their tablets unencrypted will have to flash a modified boot image every time they update CM. I hate doing such things manually every time, so i created a patch that disables forced encryption the right way - flash once and forget forever.
force-encrypt-toggler reads and unpacks your boot image, patches the ramdisk, creates a new boot image and flashes it back to the boot partition. And all that is done right on your tablet. Than it uses CM's addon.d framework, so that each time you flash a new CM zip, force-encrypt-toggler is invoked automatically to patch the newly flashed boot image. Thus, you can just upgrade through CM's built-in updater and everything will be patched automatically every time . Also, the script itself can be used on any Linux computer to patch (probably) any boot.img you have.
Thus far i have used it on my Nexus 9 to stay unencrypted starting from 20150216 through 20150224 nightlies. It seems to be quite stable, i believe . See some notes in the second post.
Download
force-encrypt-toggler-1.1-flounder.zip : https://goo.gl/bw7YDq
force-encrypt-toggler-1.1-flounder-dbg.zip : https://goo.gl/95JN34 - this one creates log files in /cache every time
force-encrypt-toggler-1.1-linux.tar.gz : https://goo.gl/3PF6ru - to be used on a desktop to patch arbitrary boot.img
old versions (for CM12): https://goo.gl/125eey
Sorry, it looks like i can not post clickable links yet. Remove space between "https" and colon.
Compatibility
I have tested this script only on my Nexus 9 Wi-Fi with TWRP recovery and CM stock boot image. However, i believe that it should be possible to make it work on other devices (e.g. Nexus 6) by just changing a few constants at the beginning.
Version 1.1 requires TWRP version >= 2.8.7.1 and a CM13 nightly >= 20160110. Version 1.0 will work for CM12.x (but not for recent CM13 nightlies).
Known issues
The addon.d script uses a dirty hack to trick the recovery. While this never happened to me, if you ever encounter a strange recovery behavior regarding installation or backup of boot images after flashing CM zip over CM with this mod, this might be it. Just reboot and it should be ok. See the second post for more info.
If CM changes something in their updater or if something changes in the recovery, this mod may easily break due to the hack mentioned above. Read the disclaimer.
Each time you flash a CM zip over a CM installation with this mod installed, TWRP recovery will hang for 5-10 seconds after reporting successful completion and before showing buttons at the bottom (or before rebooting in case of open recovery script execution). It is possible to fix this easily, but than this mod might be much easier to break.
Installation
First, you should read the disclaimer above and backup your data. Than you just have to flash the zip you downloaded with TWRP recovery. CyanogenMod must be installed first. If your /data is currently encrypted, you will have to do a full factory reset to decrypt it (backup your data first!).
Your current boot image will be patched during installation process (it should not hurt, if it's already patched). In case if something goes wrong, installation script will tell you. In any case you can get force-encrypt-toggler debug output by something like:
Code:
adb pull /tmp/fet.log
Be sure to do this before you reboot, because that file is created in the RAM.
Removal
In order to remove force-encrypt-toggler you have to delete the following files from your /system partition:
Code:
/system/xbin/mkbootimg (v1.1)
/system/xbin/unpackbootimg (v1.1)
/system/bin/force-encrypt-toggler
/system/addon.d/90-force-encrypt-toggler.sh
/system/bin/mkbootimg (v1.0)
/system/bin/unpackbootimg (v1.0)
And than restore your original boot image. You can also just format /system and flash CM again, but that is such an overkill .
Usage
Normally you will not need to run force-encrypt-toggler yourself, but in case you need, you should be able to run it both in Android and in recovery via adb shell. Just run it with --help option to see what it can do. In case you will have to debug some glitches, this command may be useful:
Code:
force-encrypt-toggler --set-not-forced --debug --dry-run --no-cleanup
If you use it on a Linux computer, this is what you will probably need:
Code:
sudo ./force-encrypt-toggler --set-not-forced [ --input path/to/boot.img --output path/to/new/boot.img ]
Note that Android and computer versions are functionally equivalent, so you can theoretically patch boot images for one Android device on another one...
Changelog
Code:
v1.1
+ use toybox instead of busybox because CM now ships only the later
+ mkbootimg and unpackbootimg are now installed to /system/xbin
+ the --help option can now be used without root privileges
v1.0 - initial release
Credits
mkbootimg is built from AOSP source
unpackbootimg is taken from this GitHub page: https://github.com/Dees-Troy/unpackbootimg
update-binary is taken from a CM zip
There is one problem with patching the new boot image from an addon.d script: CM's updater-script flashes boot image after it invokes all addon.d scripts. Therefore at a time, when the script is called, it is possible to patch only the old boot image, and than it will still be overwritten anyway. In order to overcome this, i used a very dirty hack. In short, i replace the device node with a fifo and let the updater write new boot image into it, and than... Ok, so, i think there must be a cleaner solution, so i will appreciate if a more experienced developer takes a look at my code and proposes a better solution.
As for the 5-10 second hang, it is (unexpectedly) caused by that line with "sleep 15" at the end of addon.d script. If it really annoys you, you can comment it out along with the line, where force-encrypt-toggler is called directly (not through the helper script). Updating will be a bit faster than, but if CM devs ever decide to flash boot image prior to calling addon.d scripts, you /data will be silently encrypted.
Download :: For the lazy
force-encrypt-toggler-1.0-flounder.zip : http://goo.gl/N4rZDk
force-encrypt-toggler-1.0-flounder-dbg.zip : http://goo.gl/4nXmkD - this one creates log files in /cache every time
force-encrypt-toggler-1.0-linux.tar.gz : http://goo.gl/hDFNOY - to be used on a desktop to patch arbitrary boot.img
While there was zero discussion in this thread, goo.gl tells me that there was some downloads, so someone might be actually using my small mod. If so, they might notice that it got broken around one month ago. So i decided to share a fixed version. See updated links in the description (links in the USBhost's post above are for the old version, if you wonder).
If you currently have v1.0 installed, you can just flash v1.1 over it. Note however, that if you was flashing recent nightlies while using v1.0, you /data probably have been silently re-encrypted. Also, if you current boot image is patched by v1.0, the initial patching by v1.1 during zip installation will fail, but it should work during system updates afterward. Flash stock boot image and try again if you want to be sure.
The reason for v1.0 malfunction was that around a month ago CM13 stopped shipping busybox in favor of toybox. New version is only compatible with CM nightlies >= 20160110. Also you need TWRP >= 2.8.7.1.
I never took notice to this thread before until your post in the FED thread. I am going to keep an eye on it as I have been issued lately with the FED patch saying that my device is not supported (Nexus 9 Wi-Fi). Hopefully I will have better luck with this. Thank you for sharing your.
I've just got a new Samsung Galaxy TAB A 7.0 LTE SM-T285, For some reason I can't seem to find any resources for this hardware yet in this forum, anyone know where I could find one? I'll try to find out if the current methods (custom recovery and root) for other tab versions work on this.
CUSTOM ROMS
============
Android 5.1.1 Lollipop (Stock)
Tinker V5 Edition based on the Samsung Stock Rom SM-T280/T285
Android 6.0 Marshmallow
Cyanogenmod 13 for the SM-T285 Only
OMNIRom for the SM-T285 Only
Android 7.1 Nougat
Cyanogenmod 14.1 for the SM-T285 Only (Experimental, things are broken, depcrated in favor of LOS 14.1)
LineageOS 14.1 for the SM-T285 Only
Other Operating systems
Porting for Sailfish OS is currently in progress for the SM-T285, stay tuned
TWRP RECOVERY AND ROOT
=======================
TWRP is available for both the T280 and T285. You should find the relevant threads in this Galaxy Tab A forum.
If you want to root stock, easiest way is to install TWRP and go for SuperSU. Please see the TWRP threads for SM-T280/T285 on how to root after TWRP is installed.
KERNEL
======
Custom kernel with working sources for the SM-T285 can be found Here
DEVELOPMENT
============
If you want to build LineageOS 14.1 on your SM-T285 LTE device, you can use this manifest, not that this is still a work in progress:
https://github.com/jedld/android.git
UPDATE 10/06/2016
================
After a couple of weeks of trial and error and tinkering, I've been able to compile a kernel for the SM-T285 from source and so far it seems to work flawlessly!
Screenshot here: http://imgur.com/a/HRgsq
link to my kernel sources here: https://github.com/jedld/kernel_samsung_gtexslte.git
You can also thank samsung for giving us a "broken by default" kernel source. I had to mix and match defconfigs from their other kernel releases just to make this thing work. Download modified boot.img here:
http://forum.xda-developers.com/galaxy-tab-a/development/kernel-galaxy-tab-7-0-2016-lte-sm-t285-t3474967
UPDATE 09/20/2016
================
This device is now ROOTED!
http://forum.xda-developers.com/galaxy-tab-a/help/resources-samsung-galaxy-tab-7-0-2016-t3431022/post68777842#post68777842
Download Pre-rooted Tinker Edition V5 in this thread: Tinker Edition Thread
Post Root Post Mortem Analysis for the SM-T285 (09/21/2016)
=========================
Q: How were you able to find root? What did you do?
A: Surprisingly the SM-T285 bootloader isn't actually locked like we thought it was (Once you OEM unlock of course and disable FRP). The bottomline is that
we simply needed patches to mkbootimg to properly package a boot image for this device as there were additional fields and sections not found on a normal boot image. There were even minor breaking difference between the tab 4 and the boot image for this device.
Q: I thought the bootloader was locked?? Why did it take so long?
A: I blame it on the really vague errors the bootloader shows when loading an improperly packaged boot image. What helped was my faith to open up a hex editor when I needed to, and really look at the stock images and the images we were making. What really pushed me to investigate further was the fact that I was able to make a really small modification to the ramdisk and use the abootimg -u update function instead of the create options.
Q: So the bootloader doesn't really check the image?
A: Yup, The bootloader doesn't do any check. I haven't checked if that is the case for the recovery partition though. Even without the SELINUXENFORCE headers at the end it still continues like other samsung devices do.
Q: So the mkbootimg patches are all that we need?
A: Yup, if you have CM, AOSP build env ready you can simply add the modified mkbootimg to system/core:
https://github.com/jedld/degas-mkbootimg/commit/b63ae38e2ab7040cc7ddaef777652a56b2e48322
Sample usage below:
Code:
degas-mkbootimg -o boot.img --base 0 --pagesize 2048 \
--kernel boot.img-zImage --cmdline "console=ttyS1,115200n8" --ramdisk boot_kitchen/boot.img-ramdisk-new.gz --dt boot.img-dt
Next challenge will be getting Cyanogenmod on this device as well as TWRP.
You won't because it has a locked bootloader, therefore not currently rootable and certainly no custom recovery.
jaritico said:
any idea to unlock bootloader?
Click to expand...
Click to collapse
Not unless Samsung provides one.
jaritico said:
any idea to unlock bootloader?
Click to expand...
Click to collapse
Probably no hope for root. the PIT, boot and recovery are basically untouchable, selinux enforcing enabled also does not help. You can still debloat and customize the system partition though:
http://forum.xda-developers.com/android/development/guide-samsung-galaxy-tab-7-0-sm-t285-t3438296
I'm working on getting CM 12.1 to run on this device.
jedld said:
Probably no hope for root. the PIT, boot and recovery are basically untouchable, selinux enforcing enabled also does not help. You can still debloat and customize the system partition though:
http://forum.xda-developers.com/android/development/guide-samsung-galaxy-tab-7-0-sm-t285-t3438296
I'm working on getting CM 12.1 to run on this device.
Click to expand...
Click to collapse
Yes at least the saving grace is that Samsung left Dm-verity off for this device.
If only they'd have left out the root restriction in the kernel too we'd have a rootable device.
I have an idea for this that I haven't tried yet.
Basically Samsung sends out security Policy updates via OTA, they recently released an SEPOLICY update to most devices breaking root. Chainfire patched this.
As this policy is stored in DATA and over rides the one in the boot.img it may be possible to use a patched SEPOLICY by creating a flashable DATA image with the patched SEPOLICY thereby removing the SElinux root restriction.
I ran it by Chainfire and he said in theory it should work except for that fact that the SEPOLICY in DATA is signed.
I have yet to try this out.
I think it would be difficult to get CM running as the kernel may need some patches and as we know that can't be touched.
ashyx said:
Yes at least the saving grace is that Samsung left Dm-verity off for this device.
If only they'd have left out the root restriction in the kernel too we'd have a rootable device.
I have an idea for this that I haven't tried yet.
Basically Samsung sends out security Policy updates via OTA, they recently released an SEPOLICY update to most devices breaking root. Chainfire patched this.
As this policy is stored in DATA and over rides the one in the boot.img it may be possible to use a patched SEPOLICY by creating a flashable DATA image with the patched SEPOLICY thereby removing the SElinux root restriction.
I ran it by Chainfire and he said in theory it should work except for that fact that the SEPOLICY in DATA is signed.
I have yet to try this out.
I think it would be difficult to get CM running as the kernel may need some patches and as we know that can't be touched.
Click to expand...
Click to collapse
I ran it by Chainfire and he said in theory it should work except for that fact that the SEPOLICY in DATA is signed.
I have yet to try this out.
Click to expand...
Click to collapse
Would probably need to brush up on se policies in linux. If there are already files available that I just need to flash over to /data I can try it out and also a means to test it if it works.
I've created a petition here:
https://www.change.org/p/samsung-unlock-the-bootloader-for-the-samsung-galaxy-tab-a-7-0-2016?recruiter=286570213&utm_source=petitions_show_components_action_panel_wrapper&utm_medium=copylink&recuruit_context=copylink_long
Not sure if samsung is the type that listens to this sort of thing though.
ashyx said:
As this policy is stored in DATA and over rides the one in the boot.img it may be possible to use a patched SEPOLICY by creating a flashable DATA image with the patched SEPOLICY thereby removing the SElinux root restriction.
I ran it by Chainfire and he said in theory it should work except for that fact that the SEPOLICY in DATA is signed.
I have yet to try this out.
Click to expand...
Click to collapse
I made an attempt to patch sepolicy using data however all I got in the logs was
Code:
E/SELinux ( 733): Function: fileToArray, File Open Unsuccessful:
E/SELinux ( 733): Function: getVersionhash, signature is NULL
I/SELinux ( 733): Function: selinux_init_verify_sepolicy, getVersionhash return false
E/SELinux ( 733): Function: VerifyPolicy , selinux_init_verify_sepolicy is failed
So far I have no indication that my patch worked
Code:
sepolicy-inject -s shell -t system -c file -p read -P sepolicy -o sepolicy
The error above only comes up if I place sepolicy in /data/security and sepolicy_version in /data/security/spota
sha256 hashes were also updated in the version file so I'm not sure what I'm missing.
If I could have a copy of a samsung ota that actually updates the policies I can probably have better direction
jedld said:
I made an attempt to patch sepolicy using data however all I got in the logs was
Code:
E/SELinux ( 733): Function: fileToArray, File Open Unsuccessful:
E/SELinux ( 733): Function: getVersionhash, signature is NULL
I/SELinux ( 733): Function: selinux_init_verify_sepolicy, getVersionhash return false
E/SELinux ( 733): Function: VerifyPolicy , selinux_init_verify_sepolicy is failed
So far I have no indication that my patch worked
Code:
sepolicy-inject -s shell -t system -c file -p read -P sepolicy -o sepolicy
The error above only comes up if I place sepolicy in /data/security and sepolicy_version in /data/security/spota
sha256 hashes were also updated in the version file so I'm not sure what I'm missing.
If I could have a copy of a samsung ota that actually updates the policies I can probably have better direction
Click to expand...
Click to collapse
Finally found a way to patch the kernel on this device. Stay tuned...
jedld said:
Finally found a way to patch the kernel on this device. Stay tuned...
Click to expand...
Click to collapse
Turns out I was just able to modify files in the boot.img, though when I try to update the sepolicy itself, it won't boot.
jedld said:
Turns out I was just able to modify files in the boot.img, though when I try to update the sepolicy itself, it won't boot.
Click to expand...
Click to collapse
Can you at least explain a bit further?
What modifications allow you to create a boot able image?
How have you overcome image signing?
Only way I can think of is hex editing the signature, however I was under the impression this was crc based.
ashyx said:
Can you at least explain a bit further?
What modifications allow you to create a boot able image?
How have you overcome image signing?
Only way I can think of is hex editing the signature, however I was under the impression this was crc based.
Click to expand...
Click to collapse
Yeah I was able to flash a modified boot.img using heimdall, turns out that you just need to use abootimg -u boot.img -r yourmodifiedramdisk so that you don't overwrite the SELINUXENFORCE headers appended at the end of the boot.img file, it appears the bootloader only checks for the presence of those headers but does not actually compute the sig.
Modifying ramdisk works, haven't tried modifying the kernel itself.
I tried to modify the sepolicy files after using sepolicy-inject but it throws a KERNEL not SEnforced error. I am not certain if this is just a blanket error if the kernel doesn't boot due to modifying the policy files incorrectly or if there is legit checking going on. Nevertheless I am able to modify the init.rc files now.
jedld said:
I tried to modify the sepolicy files after using sepolicy-inject but it throws a KERNEL not SEnforced error. I am not certain if this is just a blanket error if the kernel doesn't boot due to modifying the policy files incorrectly or if there is legit checking going on. Nevertheless I am able to modify the init.rc files now.
Click to expand...
Click to collapse
Continued checking it out. So even though I can modify the ramdisk, I am unable to add more than 1000 - 2000 bytes before setting off the SEAndroid enforce error on bootup. Might be some headers on the boot.img that I fail to update when the ramdisk size gets bigger. Trying to modify the sepolicy in any way even if there is minimal change in size prevents it from booting. I have no idea what is checking it, I'll try to hexedit and see what happens.
jedld said:
Continued checking it out. So even though I can modify the ramdisk, I am unable to add more than 1000 - 2000 bytes before setting off the SEAndroid enforce error on bootup. Might be some headers on the boot.img that I fail to update when the ramdisk size gets bigger. Trying to modify the sepolicy in any way even if there is minimal change in size prevents it from booting. I have no idea what is checking it, I'll try to hexedit and see what happens.
Click to expand...
Click to collapse
So I used a hexedit on the sepolicy file and was able to modify one byte of it effectively changing its sha256sum... and it worked. So the sepolicy file CAN be changed, however current sepolicy-inject and supolicy tools does something to it that trips it, looks like samsung has again added a proprietary modification sepolicy format.
I've never known a kernel not boot due to the kernel not SEANDROID enforcing warning.
It's a meaningless warning and easily bypassed.
However this is on bootloader unlocked devices.
So just let me get this straight, you have been able to repack the boot.img with modifications to the ramdisk then force flash it via Heimdall and it still boots?
ashyx said:
I've never known a kernel not boot due to the kernel not SEANDROID enforcing warning.
It's a meaningless warning and easily bypassed.
However this is on bootloader unlocked devices.
So just let me get this straight, you have been able to repack the boot.img with modifications to the ramdisk then force flash it via Heimdall and it still boots?
Click to expand...
Click to collapse
yup. that's correct. I'll post my modified boot.img in a while
jedld said:
yup. that's correct. I'll post my modified boot.img in a while
Click to expand...
Click to collapse
note that using the update only method of abootimg "abootimg -u boot.img -r xxxxxx " is the only one that works for repacking the ramdisk. Trying to build the boot.img from scratch using any other method has so far failed for me.
Here is a flashable boot.img for the SM-T285.
It contains the following modifications to the ramdisk:
a file at /this_device_is_owned
and a modified init.rc that creates a /tmp folder
jedld said:
Here is a flashable boot.img for the SM-T285.
It contains the following modifications to the ramdisk:
a file at /this_device_is_owned
and a modified init.rc that creates a /tmp folder
Click to expand...
Click to collapse
now managed to patch sepolicy using chainfire's supolicy tool. needed to use a customized mkbootimg due to changes in the Tab A image format for this. now attempting to root the device... wish me luck
EDIT: I've found the solution to my problem, posting it here in case anyone else wonders.
1. make clean the build directory and remove vendor/motorola subdirectory
2. add this line to .repo/local_manifests/roomservice.xml :
Code:
<project name="TheMuppets/proprietary_vendor_motorola" path="vendor/motorola" remote="github" />
3. repo sync
4. do the build again
I flashed this new build and everything seems to be working now.
---------------------------
I've been following these instructions (wiki.lineageos.org/athene_build.html) for building Lineage OS for athene. There is a section in those instructions about "Extract proprietary blobs." I followed those instructions, extracting the proprietary blobs from a TWRP backup I temporarily restored back onto my G4 (xt1625) on stock marshmallow 6. Attempting the build, it failed because certain (many) files under the proprietary directory were missing.
I had flashed the first Lineage OS weekly build lineage-14.1-20170123-nightly-athene-signed.zip previously, and it's actually been working well (all sensors, GPS, radios, etc.), so I restored that backup and then attempted the extract proprietary blobs step from that image. The build also failed because of other missing proprietary files that are apparently required but that are not in lineage-14.1-20170123-nightly-athene-signed.zip. I learned that you can actually skip the ADB step and unzip the nightly zip file and extract from that directory, which I did, but of course ran into the same problem as doing it via adb.
Some more digging lead me to another github repo (github.com/TheMuppets/proprietary_vendor_motorola/tree/cm-14.1/athene) which has some of the files.
So at that point I had three different sources for proprietary blobs: 1) stock marshmallow 6.0, 2) the 20170123 nightly, and 3) TheMuppets repo on github. I could finally cobble the files together from different places to get the build to proceed.
I wiped, flashed the zip and started it up. Everything worked fine, except for one major problem: I had no sensors. The gyroscope, accelerometer, ambient light, etc. return no data. I tried out a few tools that display the sensor data being returned and they all just said "Waiting for data." So that was a non-starter, which is disappointing because everything else (gps, phone, camera) worked Ok.
So I started over. This time I did a make clean (actually re-cloned the repo from scratch) back to the proprietary blob step and pieced together the required proprietary blob files from my three sources with a different order of precedence. After flashing THAT zip, I still didn't have sensors, and now the phone doesn't work either (the phone app crashes every time it starts).
So for now I've gone back to my backup from the 20170123 build, which is working Ok, but I was hoping to have been able to figure out how to do my own builds just because I'm interested in that sort of thing.
TLDR; where is the One Place To Rule Them All for extracting the proprietary files for building my own Lineage OS 14.1 nightlies for athene?
tlacuache said:
EDIT: I've found the solution to my problem, posting it here in case anyone else wonders.
1. make clean the build directory and remove vendor/motorola subdirectory
2. add this line to .repo/local_manifests/roomservice.xml :
Code:
<project name="TheMuppets/proprietary_vendor_motorola" path="vendor/motorola" remote="github" />
3. repo sync
4. do the build again
I flashed this new build and everything seems to be working now.
---------------------------
I've been following these instructions (wiki.lineageos.org/athene_build.html) for building Lineage OS for athene. There is a section in those instructions about "Extract proprietary blobs." I followed those instructions, extracting the proprietary blobs from a TWRP backup I temporarily restored back onto my G4 (xt1625) on stock marshmallow 6. Attempting the build, it failed because certain (many) files under the proprietary directory were missing.
I had flashed the first Lineage OS weekly build lineage-14.1-20170123-nightly-athene-signed.zip previously, and it's actually been working well (all sensors, GPS, radios, etc.), so I restored that backup and then attempted the extract proprietary blobs step from that image. The build also failed because of other missing proprietary files that are apparently required but that are not in lineage-14.1-20170123-nightly-athene-signed.zip. I learned that you can actually skip the ADB step and unzip the nightly zip file and extract from that directory, which I did, but of course ran into the same problem as doing it via adb.
Some more digging lead me to another github repo (github.com/TheMuppets/proprietary_vendor_motorola/tree/cm-14.1/athene) which has some of the files.
So at that point I had three different sources for proprietary blobs: 1) stock marshmallow 6.0, 2) the 20170123 nightly, and 3) TheMuppets repo on github. I could finally cobble the files together from different places to get the build to proceed.
I wiped, flashed the zip and started it up. Everything worked fine, except for one major problem: I had no sensors. The gyroscope, accelerometer, ambient light, etc. return no data. I tried out a few tools that display the sensor data being returned and they all just said "Waiting for data." So that was a non-starter, which is disappointing because everything else (gps, phone, camera) worked Ok.
So I started over. This time I did a make clean (actually re-cloned the repo from scratch) back to the proprietary blob step and pieced together the required proprietary blob files from my three sources with a different order of precedence. After flashing THAT zip, I still didn't have sensors, and now the phone doesn't work either (the phone app crashes every time it starts).
So for now I've gone back to my backup from the 20170123 build, which is working Ok, but I was hoping to have been able to figure out how to do my own builds just because I'm interested in that sort of thing.
TLDR; where is the One Place To Rule Them All for extracting the proprietary files for building my own Lineage OS 14.1 nightlies for athene?
Click to expand...
Click to collapse
IWhen you say "4. do the build again" what command did you use? Thanks
Hi, I created this thread because I noticed that more and more people are experiencing the bootloop after flashing gapps on rom 8.1.0 Oreo.
If you experience bootloop after installation oreo, just do everything according to the instructions.
What you will need:
- adb and fastboot,
- notepad++;
1. -- clean flash rom you want to install,
2. -- flash newest gapps ARM64, you can download it here - https://opengapps.org
3. -- don't start the device, in TWRP go to mount, and select "system",
4. -- connect your phone to your computer and run fastboot and adb as administrator,
5. -- type:
Code:
adb pull /system/build.prop
now in the folder with fastboot you will have the build.prop file,
6. -- open build.prop with Notepad ++ and find "ro.setupwizard.mode = OPTIONAL", replace it with "ro.setupwizard.mode = DISABLED" and save it,
7. -- now in fastboot type:
Code:
adb push build.prop /system/
adb shell
cd system
chmod 644 build.prop
8. -- reboot device.
now there will be no bootloop, but you will not see wizard setup, you have to configure the phone manually.
Most roms already have this fixed anyway, I haven't come across any that haven't yet.
Exanneon said:
Most roms already have this fixed anyway, I haven't come across any that haven't yet.
Click to expand...
Click to collapse
Possible, but it does not happen to everyone, I, for example - I have this problem on AospExtended, FireHound and many other roms released after March, I have no idea why it is, most people do not have bootloops, but some people, including me, have problem, that's why it is better to have one guide here than on one of the pages of the topic of some rom.
I see, I suppose that's just to do with your model, mine is XT1675 and the only rom I've had this issue with was bootleggers rom, however, a recent update had fixed this.
With the recent AOSP Extended rom I still have this problem but changing the build prop doesn't work as it turns back to OPTIONAL on boot for some reason, any idea?
EDIT: changed from optional to disabled and it worked
Before following this guide, you'll want to grab the MSM unbricking tool, specifically for this device (not the global or other Oneplus 8 versions). Use it if you brick yourself.
Here's how I got microG to work on my Visible Oneplus 8 running Oxygen OS 11:
Unlock the boot loader and flash Lineage's instantnoodle recovery (The small recovery image ~96MB, not the large rom file)
Reboot into recovery and adb sideload the Magisk zip file, from the recovery's 'Apply Update'.
Follow this guide to enable signature spoofing, but with the following few changes:
Place this specialized hook services file ( 11-hook-services-OxygenOS.jar.dex ) in the same folder as 11-hook-services.jar.dex.
When you get to the `java -jar` command in the guide, do this instead:
Code:
java -jar dexpatcher-1.8.0-beta1.jar -a 11 -M -v -d -o ./ services.jar 11-hook-services-OxygenOS.jar.dex 11core-services.jar.dex
Do not install the microG provided in the guide! But go ahead and install your `spoof_AVDapi30.zip` through magisk as the guide says.
Confirm that signature spoofing is working (you can download Signature Spoofing Checker from F-droid)
Inside the magisk app, search for and install the plugin "microG installer Revived". Reboot.
Grant microG all the permisisons that you can in microG settings' Self-Check.
Tap and install GmsCore.apk located at '/system/priv-app/GmsCore/". You need to do this step even though its already installed because until you do this, it will only be installed as a system app. Doing this installs it as a user app, which fixes the location permission issue (somehow this issue is encountered). If it doesn't fix it right away you may need to reboot.
Open the microG settings again, and give yourself the location settings (and SMS if still needed)
I hope this helps someone. I know I had a lot of frustration because so much that works for other instantnoodles simply doesn't work on this device. Instantnoodle custom roms like lineageOS (as of writing this) and automated patchers like smali and nanodroid don't work, so at least we have this one option.
Ciao @Calebdvn
Trying to apply this fix on OP6 OOS11.1.2.2 but nothing happends
trying the standard method I were stuck at bootlogo, using this file the system volta, but, signature spoofing Is not working
Caould you kindly support me ?