Update March 23, 2019: I'd like to apologize to everyone. It looks like I am not going to be able to actively keep this thread updated like I used to. I have had too much going on at home an work and it doesn't look like it's going to settle down any time soon. The thread is still usable so I will leave it open for discussion.
Code:
* Your warranty is now void.
*
* I am not responsible for bricked devices, dead SD cards, fires, rigged elections,
* thermonuclear war, or you getting fired because the alarms failed and you
* could not call in.
*
* Please ensure you have an advanced understanding of this device before
* flashing it! YOU are choosing to make these modifications or your own free will.
Thread Notes:
I cannot stress this enough--Please READ EVERY STEP FULLY to be sure of what you need to do.
Some steps listed in this process WILL wipe your userdata. If you have anything you need to save back it up first. While flashing via bootloader you should see it say "(bootloader) Image not signed or corrupt" - (and can show "bad key" or "N/A" while booting) this is normal expected behaviour as the image is no longer properly signed by motorola (I had to repack as our dtb's are compressed inside the boot image)
This thread is not about custom roms - You may be able to run them using the boot images provided, but this thread does NOT cover that
This guide assumes your are on COMPLETELY STOCK (FACTORY) FIRMWARE. If you have previously flashed *any* other firmware, system images, kernels, or anything else I cannot say for sure that this guide will work for you
This WILL affect your ability to get OTA's if/when they come. This thread does not cover getting back to stock. It's up to you to figure out how to get back to stock if you want the update. You're best bet to avoid issues (boot-loops, non-booting, failed updates, etc) is to go completely back to stock first!
Android GSI's - For the record, I have booted GSI's made (Aonly-32bit) however there are some issues I've noticed regarding sounds while using them. Again, this thread is NOT the place to discuss problems with this.
TWRP - We can now use official twrp! Please click this link to see details. I have edited the first post to reflect the current state of our twrp images. If you see an error or run across an issue please let me know and I"ll see about fixing it. I have linked an unofficial build I made in the official thread to fix some issues with the official build. When I get a chance to properly verify the new test-build (made by the twrp gerrit) I will see about having the official one updated.
PIE - These instructions were made using Oreo, not Pie. There are differences in the boot images at the very least (you may not need a modified boot image for Magisk). I have not flashed Pie yet to test things. If you want to test, please let me know how things work out for you.
Working Images:
The variant models below have been verified working using one of the firmware versions listed.
XT1925-2, XT1925-3, XT1925-4, XT1925-5, XT1925-6, XT1925-13
OPS27.82-19-4 (Build Date: Fri Mar 9 11:04:39 CST 2018)
OPS27.82-41 (Build Date: Sat Mar 24 01:37:45 CDT 2018)
OPS27.82-72 (Build Date: Sun May 27 02:13:41 CDT 2018)
OPS27.82-87 (Build Date: Mon Jul 16 14:54:23 CDT 2018).
OPSS27.82.87-3 (Build Date: September 2018 Security Update)
OPSS27.82-87-6 *Provided by @Jleeblanch
OPS27.104-15-10 (Build Date: Wed Mar 28 21:13:40 CDT 2018)
OPSS27.104-15-10-4 (Build Date: July 2018 Security Update) *Provided by @Jleeblanch
OPS27.104-92 (Build Date: September 2018 Security Update)
OPSS27.104-92-2 (Build Date: November 2018 Security Update) *Provided by @Jleeblanch
*
*Waiting for confirmation:
*OPS27.82-57
*
Prerequisites:
Unlocked bootloader.
ADB/Fastboot installed on your machine ( https://developer.android.com/studio/releases/platform-tools ) If you have issues with commands make sure you have a current build of ADB and fastboot.
At least some knowledge of how to use ADB and fastboot, this guide does not cover that.
Some knowledge of how TWRP/custom recoveries work.
Finally, the guide:
Step 1) Downloading TWRP and modified boot image
Download TWRP and a modified boot image that matches your factory firmware version to the ADB/Fastboot folder on your computer. The boot image downloads are based on the premise of the firmware you are running. If yours is not listed please back up (next step) and provide a link for me to edit.
Official TWRP Thread: please read the thread for more information regarding this build. The download link is in that thread.
Unofficial TWRP, this link is just like official but added a vendor image mount for testing vendor operations: [AFH] twrp-v3.2.3-ali.img
BOOT Image Links - [AFH] No-verity edited boot images link
Reboot to your bootloader. You can do this by turning on your device while holding the power and volume down buttons at the same time. Once the device reboots to the bootloader connect your phone to your computer.
Step 2) Backing up your stock boot and recovery images and fstab.qcom file--if you have these already you can safely skip to step 3.
Open a terminal/command prompt on your computer and type the following to boot into TWRP (If your filename is different, please replace the filename below with yours):
Code:
fastboot boot twrp-v3.2.3-ali.img
Once TWRP boots (it may take a bit to boot because it is trying to decrypt your userdata. It will fail as TWRP--at least for now--needs to be flashed to decrypt properly. Swipe to allow modifications if you want if asked), type the following in your computer's terminal/command prompt to back up your boot and recovery images:
Code:
adb pull /dev/block/bootdevice/by-name/boot stockboot.img
Code:
adb pull /dev/block/bootdevice/by-name/recovery stockrecovery.img
If you intend to remove encryption you'll want a backup of your fstab.qcom file:
To back up your fstab.qcom file (modified in a later step) we need to mount Vendor in TWRP first if it's not already mounted. From TWRP's main menu press 'Mount'. You can see if the vendor partition is mounted (check mark next to the word 'Vendor') . If it isn't mounted just press 'Vendor' and it should mount. Next type the following:
Code:
adb pull /vendor/etc/fstab.qcom factory-fstab.qcom
Reboot to the bootloader.
Step 3) Installing TWRP and modified boot images
Run the following command from your computer's terminal/command prompt to install the TWRP image to your device (If your filename is different, please replace the filename below with yours).
Code:
fastboot flash recovery twrp-v3.2.3-ali.img
Run the following command from your computer's terminal/command prompt to install the boot image to your device.
usage:
Code:
fastboot flash boot <insert-boot-image-name-here>.img
example:
Code:
fastboot flash boot OPS27.104-92_no-verity_boot.img
Step 4) Wiping your data on your phone to remove the current encryption. Ensure you have a backup beforehand if you want it.
This step is only needed if you intend to remove your current encryption, if you don't want to do this please skip to the next step
Boot into TWRP by using the volume keys on your phone to select "recovery mode" and then press the power button and TWRP will boot up (it may take a bit to boot because it is trying to decrypt your userdata or if you have a screen lock it may ask for it--enter it and proceed. Please read the thread linked above for help if you enter it incorrectly.)
Swipe to allow system partition modifications if you want and are asked. If you wish to backup your data and restore it after formatting then do so now. Next click the "Wipe" button in TWRP and then "Swipe to Factory Reset". This step should have formatted data as it was encrypted (removing internal storage ) however if it didn't and data is still not mountable in TWRP you can use the "Format Data" button above "Swipe to Factory Reset", this will format data and remove EVERYTHING from the internal storage as well. You may need to format data again and reboot into TWRP. DON'T REBOOT TO SYSTEM YET.
Step 5) Removing forced-encryption upon first boot (you may still choose to encrypt after booting--Moto's firmware defaults to saying it's encrypted, at least on mine, in the security tab of settings but it's not and the option to encrypt still exists within that menu)
This step is only needed if you intend to remove forced encryption, if you don't want to do this please skip to the next step
**THIS STEP DOES NOT REMOVE CURRENT ENCRYPTION--IT ONLY REMOVES FORCED ENCRYPTION DURING THE FIRST BOOT: YOU MUST HAVE COMPLETED STEP 4 ABOVE TO REMOVE CURRENTLY ENCRYPTED DATA**
This file has been verified working on Oreo and may not function correctly on Pie, please be aware of this: see HueyT's Post.
Download the force-encryption disabler zip to your ADB/Fastboot folder: [AFH] Force_Encryption_Disabler_For_ALI_Oreo_v2.zip
Now push that zip file to your phone. The example uses the /tmp directory. From your computer's terminal/command prompt type the following into your command prompt/terminal from your adb/fastboot folder:
Code:
adb push Force_Encryption_Disabler_For_ALI_Oreo_v2.zip /tmp
Flash the zip you just pushed by pressing the Install button in the TWRP main menu, select the folder where you pushed the zip to and install it. We can verify it flashed by mounting vendor manually if it's not mounted and using the following command from your computer's terminal/command prompt and checking the line that mounts /data says "encryptable" instead of "forceencrypted":
Code:
adb shell "cat /vendor/etc/fstab.qcom"
The result should include this line:
/dev/block/bootdevice/by-name/userdata /data f2fs rw,discard,nosuid,nodev,noatime,nodiratime,nobarrier,inline_xattr,inline_data wait,check,formattable,encryptable=/dev/block/bootdevice/by-name/metadata
Click to expand...
Click to collapse
Note where it says "encryptable". That means we now have the choice to do so vs. being forced to. If for whatever reason it still says "forceencrypted" mount vendor manually and try again.
Step 6) Rooting via Magisk
This step is only needed if you intend to have root access, if you don't want to do this or wish to do this later please skip to the next step
To be safe, you may need to reboot back into TWRP to make sure it sees the data partition mounted correctly and again swipe to allow system partition modifications if you want. (I've seen Magisk say forced-encryption was still detected even though it actually wasn't if I didn't reboot)
Download Magisk from the linked thread to your ADB/Fastboot folder: https://forum.xda-developers.com/apps/magisk/official-magisk-v7-universal-systemless-t3473445
Run the following command to push the Magisk zip to your device (v17.3 (beta) is current as of the last edit of this post, if it changes please put your version number instead).
The example uses the /tmp folder:
Code:
adb push Magisk-v17.3.zip /tmp
Flash the Magisk zip from TWRP by pressing the Install button in the main menu and navigate to the /tmp (or wherever you pushed it) folder to select and install it. Magisk should show success without any mention of verity or encryption. If it does, something hasn't gone right and you may need to start again.
Step 7) Almost finished!
Reboot your device. If you installed Magisk it will say "N/A" in the top corner of your device for a few seconds (otherwise it should say "bad key"). This is normal. It may look like it bootloops that screen, just let it go and and it should boot the Motorola boot screen and you can setup your device as a new phone.
Once booted, if you installed Magisk, verify Magisk Manager is installed and the root functionality works.
Step 8) ???
Step 9) Profit
Credits:
@kwiksi1ver - getting things going for us, work with twrp and verity and allowing me to use his thread as base for this guide.
@CodyF86 and his Moto E5 thread for clues as to what it would take to turn off DM-Verity (per kwik)
@Dadud - testing and constantly nuking said device
@AngryManMLS - testing and communications
@Vache - Provided us the fix for sdcards in TWRP.
@Xennet's thread regarding verity and encryption and the disabler zip and everyone there: Disable [DM-Verity]/[Force Encryption] [OnePlus 3T/3] for [Oreo] Oxygen OS
@likemiketoo - Having had TWRP built for us for testing purposes
@Jleeblanch - Helping provide various no-verity images and other help/advice like....everywhere
Everyone else who I am forgetting because let's be honest, I'm sure I have. If you feel like mention is owed please let me know and I'll be happy to add.
Extras:
THE BOOT IMAGE LINKS IN THIS POST HAVE BEEN REMOVED TO AVOID CONFUSION: THEY WERE OLD DOWNLOADS WITH IMPROPERLY LABELED NAMES.
The following is provided for backup purposes only in case you forgot to back up. When pulled from the phone, the images are the full partition size, not actual size.
XT1925-6 (OPS27.104-15-10) Factory pulled files
These files will get you back to stock as far as this guide is concerned. Remember though, 'bad key' will be displayed as they were pulled from a device instead of being provided by Motorola
Factory boot image - *link removed*
Factory recovery image - *link removed*
Factory fstab.qcom file - factory-fstab.qcom - You can push this file to /vendor/etc/ to go back to stock vendor parition if you need. You'll need to rename it to 'fstab.qcom' to make it work right. Factory boot images will probably have an issue booting without vendor being completely stock.
The following images have been provided by other XDA members:
XT1925-2
Factory boot image - *link removed*
XT1925-4
Factory boot image - *link removed*
XT1925-5
Factory boot image - *link removed*
Notes regarding editing the boot images
First off, this is not going to be a "guide" like the first post. Different devices may have different needs, and at this time I am not changing this thread to answer questions about the editing process. Maybe that'll change in the future.
It took me a minute to realize that the G6 (ALI) dtb's are compressed and this is why directly hex editing the boot images (like the G6 Play (jeter)) initially resulted in non-booting. I'd think anyone could decompress the lz4 archive and edit the necessary info, recompress (I used max compression) and then repack the boot image and it should boot. Before that realization I had at one time built the kernel from source code (OPS27-104.15.10) with verity support disabled there so I could get around verity.
Story time!
I'll keep it shorter than it really was so be happy!
So the last time I was into building roms and such was several years ago. If the dtb's existed then, I didn't remember them I started off with some of the various "kitchens" unpacking the boot image I pulled and was getting no where. Even simply unpacking and repacking seemed like it was causing issues. I saw the results kwiksi1ver was having with the G6 Play and asked for advice: Hex edits, don't unpack..
Not sure where to go from there I searched around for posts regarding verity and at some point came across Xennet's thread: Disable [DM-Verity]/[Force Encryption] [OnePlus 3T/3] for [Oreo] Oxygen OS. Within that thread there was a link for another post in that thread that spoke a more in detail about what needed to change (post #3). Please read up on that if you want to know more.
Details:
Basically, if we're not rebuilding from source, etc etc, then we need to hex edit the dtb file (ours is actually I believe 6 dtb files combined into one, other devices can vary). On some devices these files are not-compressed and we can just edit them and go. For ours, I found the need to unpack them with a kitchen (AIK). Once there, I decompress the dtb archive (it's in 'lz4' format, max compression) and make the edits. The lines we are looking for contain "wait,verify". Under normal circumstances these will mount the system and vendor partitions with verity enabled (verify) to be sure they aren't modified. We need to REPLACE the ",verify" portion of the "wait,verify" with zeros. We can't just delete them, replace with zeros so we don't change the overall file size. We have to make sure we get all references to ",verify" replaced. It'll just say "wait" now. After I've edited the dtb file I recompress in 'lz4' format with max compression and then repack the boot image. After that, we should be good to go!
Please reference Xennet's thread if you want more details of how the lines actually look in code, just be aware ours may not be 100% the same. I may add or change stuff here later.
Great guide!
thanks, can't try it yet but i will soon.
Excellent work broski, sweet guide. Really looking forward to testing some stuff out, I'm off for the next two days... so gotta get to a computer [I know pathetic, I don't have one] ... Jeez you couldn't make a one click solution for all this? ?
For real though, super big thanks to all of you for
enduring the grueling task of cracking this bad boy
How bout some donate links? ... and @kwiksi1ver, I'm not sure if you're into developing ROMs or Kernels, but I say more is always better, so there's still good cause for you to get a G6.
dejello said:
Extras:
The following is provided for backup purposes only in case you forgot to back up. When pulled from the phone, the images are the full partition size, not actual size.
Moto G6 (Ali - OPS27.104-15-10) Factory pulled files
Factory boot image - MotoG6-ali-factory-boot.img
Factory recovery image - MotoG6-ali-factory-recovery.img
Factory fstab.qcom file - factory-fstab.qcom
Click to expand...
Click to collapse
it serves for XTI 1925-4?
OPS 27.82-72
Enviado desde mi moto g(6) mediante Tapatalk
dejello said:
Extras:
The following is provided for backup purposes only in case you forgot to back up. When pulled from the phone, the images are the full partition size, not actual size.
Moto G6 (Ali - OPS27.104-15-10) Factory pulled files
Factory boot image - MotoG6-ali-factory-boot.img
Factory recovery image - MotoG6-ali-factory-recovery.img
Factory fstab.qcom file - factory-fstab.qcom
Click to expand...
Click to collapse
First off thank you for the work, this is incredible and I would love to donate.
And second, I am running the RetBr firmware as I softbricked my retus version, do you know how or where I could get the us firmware?
stifmaster81 said:
it serves for XTI 1925-4?
OPS 27.82-72
Enviado desde mi moto g(6) mediante Tapatalk
Click to expand...
Click to collapse
This is for the US version xt1925-6, but seems that it may work for you depending on the files
bird412 said:
First off thank you for the work, this is incredible and I would love to donate.
And second, I am running the RetBr firmware as I softbricked my retus version, do you know how or where I could get the us firmware?
This is for the US version xt1925-6, but seems that it may work for you depending on the files
Click to expand...
Click to collapse
I just want to install magic, I do not want to decrypt it at the moment, what I'm scared if it's boot.img will be useful for me, anyway if it goes wrong, installing the factory image
Enviado desde mi moto g(6) mediante Tapatalk
---------- Post added at 04:37 PM ---------- Previous post was at 04:35 PM ----------
anyway if something goes wrong, installing the factory image by adb is solved everything not?
Enviado desde mi moto g(6) mediante Tapatalk
stifmaster81 said:
I just want to install magic, I do not want to decrypt it at the moment, what I'm scared if it's boot.img will be useful for me, anyway if it goes wrong, installing the factory image
Enviado desde mi moto g(6) mediante Tapatalk
---------- Post added at 04:37 PM ---------- Previous post was at 04:35 PM ----------
anyway if something goes wrong, installing the factory image by adb is solved everything not?
Enviado desde mi moto g(6) mediante Tapatalk
Click to expand...
Click to collapse
I believe you are correct, that if you fastboot the original boot img it should fix any issues. Of course you should back up your data in the case that you need to completely reflash
someone could do this same but for the version OPS27.82-72 XTI 1925-4 ??
This did not work for me, I had to reinstall everything again, I would be very grateful
Same here
It didnt work for XT1925-2
Thanks anyway
But could anyone help us to do the same with the other varients pls :b as it seems it depends on it (and the boot img) (i had ALI_OPS27.82-72_cid50 in mine)
Btw thanks you again, all of you did a great job giving us a working TWRP, Root and magisk
(Just we need make it work for everyone )
Josio67 said:
Same here
It didnt work for XT1925-2
Thanks anyway
But could anyone help us to do the same with the other varients pls :b as it seems it depends on it (and the boot img) (i had ALI_OPS27.82-72_cid50 in mine)
Btw thanks you again, all of you did a great job giving us a working TWRP, Root and magisk
(Just we need make it work for everyone [emoji14] )
Click to expand...
Click to collapse
+1
Enviado desde mi moto g(6) mediante Tapatalk
---------- Post added at 07:40 PM ---------- Previous post was at 07:39 PM ----------
stifmaster81 said:
someone could do this same but for the version OPS27.82-72 XTI 1925-4 ??
This did not work for me, I had to reinstall everything again, I would be very grateful
Click to expand...
Click to collapse
Help us please
Enviado desde mi moto g(6) mediante Tapatalk
bird412 said:
First off thank you for the work, this is incredible and I would love to donate.
And second, I am running the RetBr firmware as I softbricked my retus version, do you know how or where I could get the us firmware?
Click to expand...
Click to collapse
@bird412 I do not currently. I have yet to see them posted anywhere. @Dadud had a similar (same?) issue and is now on a different bootloader as a result. If you give us a bit we can see about getting links for what you need (minus the bootloader) to see if we can get you mostly back to stock. I will not post pulled bootloader files at this time as I have zero clue if it could brick your device *permenantly* and I just don't want that on my conscience Can you let me know what all files you flashed?
For everyone else on different variants
Looks like we're going to have to do what @kwiksi1ver has done on G6 Play boot images, just slightly different. It will take a tiny bit more time per device.... Plus I'm about to go out for a bit so yeah, it'll still be a minute.
Firstly, does the TWRP image boot for you?
Secondly, if TWRP boots for you, I'd like for you to get me a couple of things:
A) I need you to pull the boot image following the steps in the first post and post a link here (along with your model number ie XT1925-#). I will see what I can do and try to find what's actually different so maybe we can avoid having to do this in the future.
B) If someone could pull the config.gz from the phone while booted in TWRP and post the model number you're using (XT1925-#) that may help.
Code:
adb pull /proc/config.gz
dejello said:
@bird412 I do not currently. I have yet to see them posted anywhere. @Dadud had a similar (same?) issue and is now on a different bootloader as a result. If you give us a bit we can see about getting links for what you need (minus the bootloader) to see if we can get you mostly back to stock. I will not post pulled bootloader files at this time as I have zero clue if it could brick your device *permenantly* and I just don't want that on my conscience [emoji14] Can you let me know what all files you flashed?
For everyone else on different variants
Looks like we're going to have to do what @kwiksi1ver has done on G6 Play boot images, just slightly different. It will take a tiny bit more time per device.... Plus I'm about to go out for a bit so yeah, it'll still be a minute.
Firstly, does the TWRP image boot for you?
Secondly, if TWRP boots for you, I'd like for you to get me a couple of things:
A) I need you to pull the boot image following the steps in the first post and post a link here (along with your model number ie XT1925-#). I will see what I can do and try to find what's actually different so maybe we can avoid having to do this in the future.
B) If someone could pull the config.gz from the phone while booted in TWRP and post the model number you're using (XT1925-#) that may help.
Code:
adb pull /proc/config.gz
Click to expand...
Click to collapse
If you tell me the steps that I have to do I will try to take mine out of my variant XTI 1925-4
Enviado desde mi moto g(6) mediante Tapatalk
---------- Post added at 08:21 PM ---------- Previous post was at 08:14 PM ----------
stifmaster81 said:
If you tell me the steps that I have to do I will try to take mine out of my variant XTI 1925-4
Enviado desde mi moto g(6) mediante Tapatalk
Click to expand...
Click to collapse
Tell me the steps to remove from the phone the configuration you are asking me please
Enviado desde mi moto g(6) mediante Tapatalk
dejello said:
@bird412 I do not currently. I have yet to see them posted anywhere. @Dadud had a similar (same?) issue and is now on a different bootloader as a result. If you give us a bit we can see about getting links for what you need (minus the bootloader) to see if we can get you mostly back to stock. I will not post pulled bootloader files at this time as I have zero clue if it could brick your device *permenantly* and I just don't want that on my conscience Can you let me know what all files you flashed?
For everyone else on different variants
Looks like we're going to have to do what @kwiksi1ver has done on G6 Play boot images, just slightly different. It will take a tiny bit more time per device.... Plus I'm about to go out for a bit so yeah, it'll still be a minute.
Firstly, does the TWRP image boot for you?
Secondly, if TWRP boots for you, I'd like for you to get me a couple of things:
A) I need you to pull the boot image following the steps in the first post and post a link here (along with your model number ie XT1925-#). I will see what I can do and try to find what's actually different so maybe we can avoid having to do this in the future.
B) If someone could pull the config.gz from the phone while booted in TWRP and post the model number you're using (XT1925-#) that may help.
Code:
adb pull /proc/config.gz
Click to expand...
Click to collapse
thank You for your help, I am gonna try to find out what @kwiksi1ver did to modify the boot.img.
But in every case here are the files for XT1925-5
dejello said:
@bird412 I do not currently. I have yet to see them posted anywhere. @Dadud had a similar (same?) issue and is now on a different bootloader as a result. If you give us a bit we can see about getting links for what you need (minus the bootloader) to see if we can get you mostly back to stock. I will not post pulled bootloader files at this time as I have zero clue if it could brick your device *permenantly* and I just don't want that on my conscience Can you let me know what all files you flashed?
Click to expand...
Click to collapse
I downloaded the firmware from this and flashed it using the code provided in the op. Later in the thread someone uploaded some files from their RetUS phone but I could not get past their encryption passwords
nightmw said:
thank You for your help, I am gonna try to find out what @kwiksi1ver did to modify the boot.img.
But in every case here are the files for XT1925-5
Click to expand...
Click to collapse
Can you help me make mine? What steps do I have to do, thanks
Enviado desde mi moto g(6) mediante Tapatalk
nightmw said:
thank You for your help, I am gonna try to find out what @kwiksi1ver did to modify the boot.img.
But in every case here are the files for XT1925-5
Click to expand...
Click to collapse
Thanks for doing this...Stifmaster hold on buddy, it's going to be okay, breath.
adb pull /dev/block/platform/soc/7824900.sdhci/by-name/boot stockboot.img
what to put who ... by-name / boot adb pull /dev/block/platform/soc/7824900.sdhci/by-name/boot stockboot.img
what to put who . ... by-name/boot para el motog6 ali xti 1925-4
Related
TWRP 3.1.0.0 with FIsH for our FLEX 2
Tested on h955 and it's still a BETA
Requirements
Here are the pre-requirements you have to met!
If you can't get them: Close this page and FORGET it (until the day you met those reqs)!
Here are the 2 simple requirements you have to met:
1. root by SuperSU >=v2.76 (greater or equal v2.76)
--> to test this requirement just start the installer of FIsH with --check (see next lines) which will check for all requirements and abort if its not possible
--> for many devices - if not all - this means you HAVE TO downgrade/install LL. It also means that you have to upgrade your SuperSU to this version by e.g. FlashFire if you have a lower version installed!
--> SU by phh is NOT supported => It needs a modified /boot and this would void the boot signing chain!
--> Magisk is NOT supported => It needs a modified /boot and this would void the boot signing chain!
--> I will NOT provide downgrading guides there are plenty of them so search and read.
--> I will NOT provide any guides in rooting your device
--> Before you think about downgrading to LL read about ANTI-ROLLBACK protection some devices and may have! Anti-Rollback means you CAN NOT downgrade - it would HARD-BRICK your device (wtf thinking the vendors who we are?? Is this even legal?!)! Check that before!!
2. you have to be able to disable SELinux in your booted Android
--> You do NOT need to set SELinux permanently to permissive. Just CHECK if you COULD get it MANUALLY. If you can get it OK. If not.. you obviously have not full root access but check the forums maybe there is something you can do about this.
--> I will NOT provide any guides enabling SELinux but some lines later you will see how u can execute the very simple check
--> to test this requirement just start the installer of FIsH with --check (see next lines) which will check for all requirements and abort if its not possible
Those above are hard facts so it may NEVER work with MM. Google has changed the way on how the boot chain will be verified and that means changes in /system will void it from now on.
If MM can get fully rooted somehow/somewhen on your device with SuperSU installed and you are able to disable SELinux the method will work there as well.
If you can not meet ALL of the above 2 requirements lay down and cry.
For the others: calm down and read on!
You can simply test those both requirements by downloading the FIsH package and execute the installer with the following test parameter:
./install.sh --check
This way nothing get installed but you will see if it would work on your device or not.
Limitations!
Keep in mind what I said above: FIsH does NOT unlock your bootloader!
That means with TWRP-in-FIsH you can NOT:
Install a custom ROM like CM/Lineage (this will modify boot = SOFT-BRICK)
Install a custom Kernel (this will modify boot = SOFT-BRICK)
Install a custom recovery (this will modify recovery = may SOFT-BRICK)
In short: do nothing which modifies boot or recovery partitions. Those changes will BREAK your boot signing chain.
You can of course flash everything which is modifying /system /data only (e.g. xposed, Audio mods, etc...)
You're able to backup and restore as well of course and doing any other modifications which you may can't while the Android system is running.
Download
READ THE REQUIREMENTS above before proceeding!
Then UNDERSTAND the requirements before proceeding! <-- omg this is crucial important!!!! Ensure that you really do not skip this step!
READ THE LIMITATIONS above before proceeding!
Then UNDERSTAND the limitations before proceeding! <-- omg this is crucial important!!!! Ensure that you really do not skip this step!
... and NEVER ask for ETA's!
if you can say:
Yes! I have read and totally understood the limitations AND the requirements!
then proceed. Otherwise read again until you got it.
Keep in mind that this is a HACK. It may soft-brick your device. you have been warned!
The concept is the same for all models but again no guarantees here for anything.
There is ALWAYS a risk and you should better backup what you do not want to loose before starting downloading this.
Download
Installation (Linux)
You can just install any newer version over an old one.
boot Android and connect USB cable
download the newest version to your PC and open a terminal in that directory
tar xzf TWRP-in-FIsH*.tgz
cd android_FIsH
./install.sh
check the output of that script. you should not see any errors there (hopefully)
Installation (Windows)
use FWUL or be patient.. maybe i or someone else release an installer... maybe...
First run (no PC required)
This FIsH gets installed PERMANENTLY! That means:
You can boot up TWRP the same way as described here again without re-installing.
If you re-install your STOCK image you have to re-install TWRPinFIsH as well.
reboot Android
you should now see: LED goes from blue to GREEN
NOW directly when u see this GREEN LED press VOLUME DOWN and do NOT release
wait until the device vibrates and the LED changed to RED. Then release the Volume Down button.
Wait until FIsH completed and TWRP should be shown --> This means FIsH has done it's job well!
This is a good time to do a full backup isn't it ? Manually mount the SYSTEM partition as it gets not auto mounted atm and do a full backup
reboot from here (safely ignore the msg "no OS installed" and reboot anyways) and you should see Android booting (hopefully ... if not see bottom)
Daily Usage (no PC required)
reboot Android
you should now see: LED goes from blue to GREEN
NOW directly when u see this GREEN LED press VOLUME DOWN and do NOT release
wait until the device vibrates and the LED changed to RED. Then release the Volume Down button.
Wait until FIsH completed and TWRP should be shown --> This means FIsH is doing it's job still very well
AGAIN: keep your mind up! You HAVE to ensure that whatever you do and whatever you flash -> NEVER TOUCH BOOT/RECOVERY! If you flash a ZIP ensure first that it do not modify them! Otherwise you WILL softbrick. You have been warned (several times now)
Trouble / Bootloop fix
if you encounter a bootloop (should never happen but who knows) you have 3 choices at least:
Option 1a: (TWRP-Bootloop) Within TWRP open Advanced -> File Manager -> Goto: /system/su.d and click "select" button -> Delete
Option 1b: (TWRP-Bootloop) From your PC: adb shell rm -rf /system/su.d/
Important: Catch the fish log (see next topic)
Option 2 (this works also for a bootloop without twrp): boot into download mode and use LGLaf to get a shell
then:
setenforce 0 <-- if that doesn't work you may have to do a FULL restore to stock
mount -oremount,rw /system
rm -rf /system/su.d/
reboot. You are out of the bootloop.
Important: Catch the fish log (see next topic)
Option 3: Last resort: Reflash STOCK. sorry.. there is always a risk..
Catch the FIsH logs
when in TWRP (or other ramdisk providing adb shell):
adb shell "cat /cache/fish/fish.log"
adb shell "cat /tmp/recovery.log"
OR - when in Android:
adb shell "su -c cat /cache/fish/fish.log"
adb shell "su -c cat /cache/fish/fish.log.old"
adb shell "su -c tar cvzf recoverylogs.tgz /cache/recovery"
adb pull recoverylogs.tgz
Upload the output to https://paste.omnirom.org and paste the link in the IRC channel (see next topic)
Support / IRC Channel
IRC means Internet Relay Chat and you will get best support here only.
Choose how to get in:
PC (HexChat and Pidgin are only 2 of them! This list is not complete!)
Android (Yaaic, AndChat, HoloIRC, AndroIRC are only a few of them! This list is not complete!)
Web (KiwiIRC-Web,FreenodeWebchat])
When you have to choose a channel it is: #Carbon-user
When you will be asked for a server network choose: freenode
Known issues (may never get fixed)
Due to the fact that FIsH is a BRUTAL hijack of the booting process several things may not work as expected.
This will normally not harm anything but you have to know about.
ZIP / ROM flashing:
omg really you wanna hear that again? OK: DON'T TOUCH BOOT / RECOVERY. And you be safe.
When you try to install a ROM it will modify at least BOOT. That means soft-brick!
When you try to install a custom Kernel.. omg really? It will definitively SOFT-BRICK! Maybe you should read the limitations again??
When you try to install a ZIP like xposed, supersu, Vipermod and others ensure that those are not modifying BOOT or RECOVERY partitions. For those mentioned it would be very unlikely but who knows.
FIRMWARE partition:
cannot be mounted - even not manually. You have to live with it.
Double Tap to wakeup (in TWRP):
Unfortunately this cannot work in TWRP-in-FIsH due to the nature of this hijack. You have to live with it.
Credits (without them - no FIsH!!!)
If you feel that someone / you is missing on this list lemme know!
Chainfire for SuperSU! This is the main part of FIsH.
TeamWin for TWRP
@cray_Doze, @dssmex, @Aaahh and @KeiranFTW for their hijack implementations (e.g. https://forum.xda-developers.com/showthread.php?t=2608408, first steps to a G4 hijack)
steadfasterX for the android FIsH !
Here is the h955 device tree for building TWRP with omnirom minimal sources - https://github.com/jarno83/android_device_lge_h955
Here are TWRP logs from backups and restoring if anyone interested - https://github.com/jarno83/twrp_logs
Changelog
29.04.2017 - TWRP-3.1-in-FIsH-v2.0_LGFLEX2_LL_BETA3.zip
Latest FIsH source code and fixes.
3.04.2017 - TWRP-3.1-in-FIsH-v2.0_LGFLEX2_LL_BETA2.zip
Fixed the RESTORE issue - thanks to SteadfasterX
Used latest FIsH source code.
Went to zip format, now a pit smaller.
2.04.2017 - TWRP-3.1-in-FIsH-v2.0_LGFLEX2_LL.tar.gz
The fishfood is TWRP 3.1.0.0 it uses 15c stock kernel for now. And has a problem with restoring.
What is TESTED
BACKUP and RESTORING /system and /data partitions - OK
Xposed V87 - flashes ok with twrp and works - http://dl-xda.xposed.info/framework/sdk22/arm64/
Tested Device List
H955 running 5.1.1 15c ROM
H950 running 5.1.1 PR ROM - thanks to iDefalt
Congrats
Have you seen the XDA template for FIsH?
https://forum.xda-developers.com/an...ack-to-boot-want-device-t3578373/post71567825
.
Sent from my LG-H815 using XDA Labs
steadfasterX said:
Congrats
Have you seen the XDA template for FIsH?
https://forum.xda-developers.com/an...ack-to-boot-want-device-t3578373/post71567825
.
Sent from my LG-H815 using XDA Labs
Click to expand...
Click to collapse
Ok, thanks Didn't saw that
So anyone tested it yet ? TWRP booting ?
I have my phone in repair center atm cant test anything.
Yes, I have it on my h955 and twrp boots fine. I tested system backup and restore, now working. Flashed xposed also ?
Sent from my LG-H955 using XDA-Developers Legacy app
/data backuped and restored with success ?
Sent from my LG-H955 using XDA-Developers Legacy app
Ok so now what? What is the next step? On road To install custom rom or custom kernel.
dadaa1 said:
Ok so now what? What is the next step? On road To install custom rom or custom kernel.
Click to expand...
Click to collapse
SteadfasterX is developing some stuff... so maybe on day we will have a possibility to use full custom roms.
But for now we have a custom recovery
If someone is willing to cook something interesting that can work with not touching the boot or recovery partitions... then well I would call it a custom rom
In theory it should work on a H950PR? So I can at least test it
maucvs said:
In theory it should work on a H950PR? So I can at least test it
Click to expand...
Click to collapse
Hi, I think it will work. You'll need to be rooted and You can give it a try ?
Sent from my LG-H955 using XDA-Developers Legacy app
It should work..
I already tried this on h950 but there is dead android with red '!' ..
For some reason it wont boot into the fishrecovery and goes to the recovery partition..
Ill try smth when i have time.
adds08 said:
It should work..
I already tried this on h950 but there is dead android with red '!' ..
For some reason it wont boot into the fishrecovery and goes to the recovery partition..
Ill try smth when i have time.
Click to expand...
Click to collapse
Seams like the twrp I build is not liking h950
Sent from my LG-H955 using XDA-Developers Legacy app
I'll try to make h950 tree and build a test twrp.
Sent from my LG-H955 using XDA-Developers Legacy app
adds08 said:
It should work..
I already tried this on h950 but there is dead android with red '!' ..
For some reason it wont boot into the fishrecovery and goes to the recovery partition..
Ill try smth when i have time.
Click to expand...
Click to collapse
Can you test this... made a h950 test tree. The twrp boots on my h955 also.
ergo911 said:
Seams like the twrp I build is not liking h950
Click to expand...
Click to collapse
I had a similar issue for the g4 and here it was FIsH because it was too slow for some devices . I will release a new FIsH release which improves speed dramatically asap.
.
Sent from my LG-H815 using XDA Labs
Thanks ?
ergo911 said:
Thanks ?
Click to expand...
Click to collapse
Ok so please use git pull to get the latest updates!
Lemme know if you have any trouble.
.
Sent from my LG-H815 using XDA Labs
ergo911 said:
Can you test this... made a h950 test tree. The twrp boots on my h955 also.
Click to expand...
Click to collapse
Works like a charm on my H950. Thanks! The only issue is TWRP booting time, but it's should be right that, if I understand correctly.
Thank you!
Various Android devices support Android Verified Boot (AVB). A part of this is more commonly known as dm-verity, which verifies system (and vendor) partition integrity. AVB can however also verify boot images, and stock firmwares generally include signed boot images. Of course this does not mean that all signed boot images are using AVB, many OEMs have their own signature verification scheme.
Note: AOSP is moving towards the use of avbtool (taken from Brillo), the following is the old way for signing boot images.
Bootloaders might or might not accept unsigned boot images, and might or might not accept boot images signed with our own keys (rather than the OEM's keys). This depends on the device, bootloader version, and bootloader unlock state.
For example, with the bootloader unlocked, the Google Pixel (and XL) devices accepted unsigned boot images up to (but not including) the May 2017 release. From the May 2017 release onwards, the boot images must be signed if flashed (booted works without), but may be signed with your own key rather than the OEM's.
Note: The situation changes when you re-lock the bootloader. I have not tested this, but documentation implies that (one of) the keys used in the current boot image must be used for future flashes until it is unlocked again.
Generating custom signing keys
The following openssl commands generate all the keys we need. Execute them line-by-line rather than copying the whole block, as you will be asked for input.
Code:
# private key
openssl genrsa -f4 -out verifiedboot.pem 2048
openssl pkcs8 -in verifiedboot.pem -topk8 -outform DER -out verifiedboot.pk8 -nocrypt
# public key
openssl req -new -x509 -sha256 -key verifiedboot.pem -out verifiedboot.x509.pem
openssl x509 -outform DER -in verifiedboot.x509.pem -out verifiedboot.x509.der
For future signings, you do not need the .pem files, and they can safely be deleted once the .pk8 and .der files are generated. In AOSP's implementation, they were never even written to disk in the first place.
Security-wise, documentation states it is advisable to use a different set of keys for each device you support; though obviously this doesn't matter much if the device is running with the bootloader in unlocked state.
Signing the boot image
Download the attached BootSignature.jar file (built from AOSP sources), and sign the boot image using the keys generated above with the following commands:
Code:
java -jar BootSignature.jar /boot boot.img verifiedboot.pk8 verifiedboot.x509.der boot_signed.img
java -jar BootSignature.jar -verify boot_signed.img
Instead of /boot, /recovery and other values may be used. Their use should be obvious.
From Android
Attached is also BootSignature_Android.jar, which is a version ProGuard-reduced against SDK 21 and then dexed. Provided /system is mounted as is usual on Android (on the Pixel (XL), TWRP mounts this differently by default!), it can be used like this:
Code:
dalvikvm -cp BootSignature_Android.jar com.android.verity.BootSignature /boot boot.img verifiedboot.pk8 verifiedboot.x509.der boot_signed.img
dalvikvm -cp BootSignature_Android.jar com.android.verity.BootSignature -verify boot_signed.img
The base command can be extended as follows to make it able to run without any precompiled files present on the device:
Code:
/system/bin/dalvikvm -Xbootclasspath:/system/framework/core-oj.jar:/system/framework/core-libart.jar:/system/framework/conscrypt.jar:/system/framework/bouncycastle.jar -Xnodex2oat -Xnoimage-dex2oat -cp BootSignature_Android.jar com.android.verity.BootSignature ...
Flashable ZIP
Attached is also VerifiedBootSigner.zip, this is a flashable ZIP for FlashFire/TWRP/etc that signs the currently flashed boot image, if it isn't signed already. You can simply flash this after installing a SuperSU version or custom boot image or whatever that doesn't sign the boot image itself already.
I've tried to make it very portable (borrowing ample script from the SuperSU ZIP, as well as its signing keys), but I have only tested it on my Pixel XL.
Note that it does depend on Android files in the system partition, so if (aside from the unsigned boot image) your system isn't functional, the ZIP may not work either.
If the boot image is already signed when you flash the ZIP, it will offer to abort or force re-sign.
If you place custom.pk8 and custom.x509.der files inside the ZIP, these keys will be used for flashing instead of SuperSU's default keys. Additionally, /tmp/avb/custom.pk8 and /tmp/avb/custom.x509.der will override any keys from the ZIP.
There is some more documentation in the update-binary file inside the ZIP as well.
Note: If you're using TWRP's manual slot selection on the Pixel (XL), you must be using TWRP-v3.1.0-RC2 or newer, or it will not work as expected.
Todo
- test what happens when the bootloader is re-locked on multiple devices supporting AVB
- test what happens when dm-verity is kept enabled on a custom/modified boot image with a different image signature than dm-verity signature
-reserved-
*finally my dream come true, btw, nice job on doing this, keep it up man*
Super great
Great write up! So I take it we can no longer distribute kernel images without first integrating them into the boot image and then signing it? That negates the whole point of being able to flash the kernel individually with fastboot!
thank God Chanifire hasnt left us entirely!!!
This gives me hope my Pixel isn't dev dead. Thank you, CF!
@Chainfire you not going to reply but still, you are responsible i have faith in Android... Development is most of the times happens because of you ....It always revolves around you ... One man army i would say. Thank you for all your works. We all owe you a lot...
Is it possible to create the signature for boot bundle with openssl alone (i.e. without this BootSignature.jar ) ?
Wasn't self-signing boot images already kind of possible?
cr2 said:
Is it possible to create the signature for boot bundle with openssl alone (i.e. without this BootSignature.jar ) ?
Click to expand...
Click to collapse
Not just with openssl, no. How the boot signature works is not properly documented, but of course you could read the source in AOSP and make your own version.
mirhl said:
Wasn't self-signing boot images already kind of possible?
Click to expand...
Click to collapse
Apart from both of these things talking about signatures, they are unrelated. However, self-signing images has been supported for quite a while on several devices, it just wasn't required. CopperheadOS - as far as I know - is the only project that has actively been using it until now.
is it possible to sign the boot image in recovery?
Hi @Chainfire ! Thank you for this great find (and for everything else what you have done for us during the last years )!!
I would like to ask one question... Do you think it would be possible to sign the boot image on the fly in recovery? For example when changing the recovery image, before flashing the boot image back?
Your instructions use "dalvikvm" on android, and I ran the command successfully under a running android system. But what about recovery ?
I would be interested in your thoughts on this
Or am I completely wrong, and images "dumped" via dd can't be signed and flashed back?
I would really appreciate if you could point me in the right direction, how it could be possible to do this. (create an executable instead of the BootSignature.jar file? leave this, because it is not possible? start a java vm under recovery? ....)
Thanks in advance!
gubacsek said:
Hi @Chainfire ! Thank you for this great find (and for everything else what you have done for us during the last years )!!
I would like to ask one question... Do you think it would be possible to sign the boot image on the fly in recovery? For example when changing the recovery image, before flashing the boot image back?
Your instructions use "dalvikvm" on android, and I ran the command successfully under a running android system. But what about recovery ?
I would be interested in your thoughts on this
Or am I completely wrong, and images "dumped" via dd can't be signed and flashed back?
I would really appreciate if you could point me in the right direction, how it could be possible to do this. (create an executable instead of the BootSignature.jar file? leave this, because it is not possible? start a java vm under recovery? ....)
Thanks in advance!
Click to expand...
Click to collapse
Yes, this is possible - I have already tested this on my PIxel XL. SuperSU ZIP will do exactly this in a future update, and @Dees_Troy is also aware of all of this, so I assume TWRP will be updated to do this sooner or later as well.
If I can find the time I'll make a ZIP that does this.
Chainfire said:
Yes, this is possible - I have already tested this on my PIxel XL. SuperSU ZIP will do exactly this in a future update, and @Dees_Troy is also aware of all of this, so I assume TWRP will be updated to do this sooner or later as well.
If I can find the time I'll make a ZIP that does this.
Click to expand...
Click to collapse
Okay! I am very curious about how you solve it... Until then, I'll experiment a bit further
Can't wait to see your result!
Thanks! And have a very nice weekend!
I have attached a flashable ZIP to the opening post. Just flash it after SuperSU / custom boot image / whatever to fix the current boot image.
gubacsek said:
Okay! I am very curious about how you solve it... Until then, I'll experiment a bit further Can't wait to see your result!
Click to expand...
Click to collapse
Chainfire said:
I have attached a flashable ZIP to the opening post. Just flash it after SuperSU / custom boot image / whatever to fix the current boot image.
Click to expand...
Click to collapse
Thank you so much, it worked beautifully on my VZW Pixel with the May update.
:good: working fine on the May update with May bootloader, FK, TWRP and SuperSU
Outstanding as usual!
Chainfire said:
I have attached a flashable ZIP to the opening post. Just flash it after SuperSU / custom boot image / whatever to fix the current boot image.
Click to expand...
Click to collapse
I almost got it I could install TWRP and root but only by signing the boot images on my laptop...
I had a few errors (mounting /system did create a /system/system mount point, and I tried to copy the dalvikvm binary to the zip ), and I wouldn't ever have thought of clearing LD_LIBRARY_PATH
Thank you very much for this solution, and your time spent on this! I learnt a lot today
Nice job!
Chainfire said:
Various Android devices support Android Verified Boot (AVB). A part of this is more commonly known as dm-verity, which verifies system (and vendor) partition integrity. AVB can however also verify boot images, and stock firmwares generally include signed boot images. Of course this does not mean that all signed boot images are using AVB, many OEMs have their own signature verification scheme.
Note: AOSP is moving towards the use of avbtool (taken from Brillo), the following is the old way for signing boot images.
Bootloaders might or might not accept unsigned boot images, and might or might not accept boot images signed with our own keys (rather than the OEM's keys). This depends on the device, bootloader version, and bootloader unlock state.
For example, with the bootloader unlocked, the Google Pixel (and XL) devices accepted unsigned boot images up to (but not including) the May 2017 release. From the May 2017 release onwards, the boot images must be signed if flashed (booted works without), but may be signed with your own key rather than the OEM's.
Note: The situation changes when you re-lock the bootloader. I have not tested this, but documentation implies that (one of) the keys used in the current boot image must be used for future flashes until it is unlocked again.
Generating custom signing keys
The following openssl commands generate all the keys we need. Execute them line-by-line rather than copying the whole block, as you will be asked for input.
For future signings, you do not need the .pem files, and they can safely be deleted once the .pk8 and .der files are generated. In AOSP's implementation, they were never even written to disk in the first place.
Security-wise, documentation states it is advisable to use a different set of keys for each device you support; though obviously this doesn't matter much if the device is running with the bootloader in unlocked state.
Signing the boot image
Download the attached BootSignature.jar file (built from AOSP sources), and sign the boot image using the keys generated above with the following commands:
Instead of /boot, /recovery and other values may be used. Their use should be obvious.
From Android
Attached is also BootSignature_Android.jar, which is a version ProGuard-reduced against SDK 21 and then dexed. Provided /system is mounted as is usual on Android (on the Pixel (XL), TWRP mounts this differently by default!), it can be used like this:
Flashable ZIP
Attached is also VerifiedBootSigner.zip, this is a flashable ZIP for FlashFire/TWRP/etc that signs the currently flashed boot image, if it isn't signed already. You can simply flash this after installing a SuperSU version or custom boot image or whatever that doesn't sign the boot image itself already.
I've tried to make it very portable (borrowing ample script from the SuperSU ZIP, as well as its signing keys), but I have only tested it on my Pixel XL.
Note that it does depend on Android files in the system partition, so if (aside from the unsigned boot image) your system isn't functional, the ZIP may not work either.
Todo
- test what happens when the bootloader is re-locked on multiple devices supporting AVB
- test what happens when dm-verity is kept enabled on a custom/modified boot image with a different image signature than dm-verity signature
Click to expand...
Click to collapse
So are Samsungs latest devices now using this. Reason I ask is because in the S8 and Tab S3 stock firmware there is a META-DATA folder in the AP firmware tar. Inside is a fota.zip containing various folders with all sorts of utilities and files, one of which is BootSignature.jar.
It seems it is required to flash the META-DATA folder with the boot.img in ODIN or it will not boot. So I'm guessing the boot.img is being signed as part of the flashing process?
ashyx said:
So are Samsungs latest devices now using this. Reason I ask is because in the S8 and Tab S3 stock firmware there is a META-DATA folder in the AP firmware tar. Inside is a fota.zip containing various folders with all sorts of utilities and files, one of which is BootSignature.jar.
It seems it is required to flash the META-DATA folder with the boot.img in ODIN or it will not boot. So I'm guessing the boot.img is being signed as part of the flashing process?
Click to expand...
Click to collapse
Possibly. Which S8 are you talking about? I thought there was already working TWRP for S8 Exynos that didn't require anything special?
Chainfire said:
Possibly. Which S8 are you talking about? I thought there was already working TWRP for S8 Exynos that didn't require anything special?
Click to expand...
Click to collapse
New S8. Qualcomm Snapdragon 835 MSM8998 bootloader locked versions.
It's got an eng kernel available, but it's a no go with your s7 script due to no adb write access.
https://forum.xda-developers.com/galaxy-s8/how-to/rd-carrier-switch-root-snapdragon-t3597473/page54
Edit 25/10/2020: OK its been a while guys, if you want to try a ROM I'd highly recommend following LineageOS's wiki for instructions. Then if u want to try other ROMs keep an eye out in these forums, ill have a build up every now and then. See ya around guys
==========================================================================================
Rather than having random comments in random parts of the forum here is a thread for everything 64 bit on G7 Play.
CURRENT STATUS
WE DID IT!!!! CHECK SyberHexen's ANDROIDFILEHOST FOR DOWNLOAD!
OLD POST ARCHIVED BELOW
And here is what is available so far:
A nice selection of ROMs for the other G7's, but they dont actually boot on the Play, although should do something in theory
postmarketOS is aarch64, but that is mobile linux, and no phone interface works (x.org doesnt work with the current drivers)
Here is what I've tried:
crDroid from ocean:
I got it to install by: repartitioning device using ocean gpt.bin
Then flashing stock rom from channel
Booting TWRP
Flashing ROM, with modified zip accepting channel
Doesnt boot
Also tried a flash using ocean firmware completely, doesn't boot, but got the logos and bootloader works lol
If anyone has any tips or progress drop it here, eta kids go away. Read the status above if you want the up-to-date answer
00p513 said:
Rather than having random comments in random parts of the forum here is a thread for everything 64 bit on G7 Play.
CURRENT STATUS
NO 64-BIT ANDROID ROM AVAILABLE
And here is what is available so far:
A nice selection of ROMs for the other G7's, but they dont actually boot on the Play, although should do something in theory
postmarketOS is aarch64, but that is mobile linux, and no phone interface works (x.org doesnt work with the current drivers)
Here is what I've tried:
crDroid from ocean:
I got it to install by: repartitioning device using ocean gpt.bin
Then flashing stock rom from channel
Booting TWRP
Flashing ROM, with modified zip accepting channel
Doesnt boot
Also tried a flash using ocean firmware completely, doesn't boot, but got the logos and bootloader works lol
If anyone has any tips or progress drop it here, eta kids go away. Read the status above if you want the up-to-date answer
Click to expand...
Click to collapse
You have to compile the kernel from source and use a 64bit gsi and flash a 64 bit vendor partition I'm pretty sure everythi
---------- Post added at 04:44 AM ---------- Previous post was at 04:42 AM ----------
00p513 said:
Rather than having random comments in random parts of the forum here is a thread for everything 64 bit on G7 Play.
CURRENT STATUS
NO 64-BIT ANDROID ROM AVAILABLE
And here is what is available so far:
A nice selection of ROMs for the other G7's, but they dont actually boot on the Play, although should do something in theory
postmarketOS is aarch64, but that is mobile linux, and no phone interface works (x.org doesnt work with the current drivers)
Here is what I've tried:
crDroid from ocean:
I got it to install by: repartitioning device using ocean gpt.bin
Then flashing stock rom from channel
Booting TWRP
Flashing ROM, with modified zip accepting channel
Doesnt boot
Also tried a flash using ocean firmware completely, doesn't boot, but got the logos and bootloader works lol
If anyone has any tips or progress drop it here, eta kids go away. Read the status above if you want the up-to-date answer
Click to expand...
Click to collapse
You have to compile the kernel from source and use a 64bit gsi and flash a 64 bit vendor partition I'm pretty sure everything else will work fine. I'm working on getting a new dev environment set up I'll give it a shot... This phone is reeeeealy under developed. Proly cause the g6 play is a way better phone and much cheaper to boot
mrsurge said:
You have to compile the kernel from source and use a 64bit gsi and flash a 64 bit vendor partition I'm pretty sure everythi
---------- Post added at 04:44 AM ---------- Previous post was at 04:42 AM ----------
You have to compile the kernel from source and use a 64bit gsi and flash a 64 bit vendor partition I'm pretty sure everything else will work fine. I'm working on getting a new dev environment set up I'll give it a shot... This phone is reeeeealy under developed. Proly cause the g6 play is a way better phone and much cheaper to boot
Click to expand...
Click to collapse
We have a 64-bit kernel and 64-bit Lineage OS testing builds but porting 64-bit vendor partition for it to flash in g7 play hasn't been achieved yet.
kD said:
We have a 64-bit kernel and 64-bit Lineage OS testing builds but porting 64-bit vendor partition for it to flash in g7 play hasn't been achieved yet.
Click to expand...
Click to collapse
I think maybe you can just pick out driver binaries from 64 bit /vendor and use all the configs scripts and frameworks from the original vendor
Try backing up/vendor pieceing the drivers from another device of the same model but diff carrier and a combo as such would work. If not mistaken the. Vendor from the Verizon g6 play worked for sprint except data and wifi or radio in general didn't work.. that's a start right there
I think the modem is going to be the same architecture no matter what so you wouldn't have to worry to much about that
64bit Test
Okay so this sh*t probably totally won't boot up at all, but if someone is feeling brave, you can test this out.
1. From your active slot, with root access, you'll need to dd these images to the correct partitions. It's easiest to do this from the internal sdcard using termux. Use the following as a template. These commands assume you're installing it to slot b.
Code:
su
dd if=/sdcard/boot64.img of=/dev/block/by-name/boot_b
dd if=/sdcard/dtbo64.img of=/dev/block/by-name/dtbo_b
dd if=/sdcard/vendor64.img of=/dev/block/by-name/vendor_b
dd if=/sdcard/oem64.img of=/dev/block/by-name/oem_b
2. Reboot into fastboot, swap active slots, and wipe userdata + DDR. Then flash an arm64 AB GSI. I'd recommend trying Phh's AOSP Vanilla to maximize the chances of success.
To swap slots and wipe user data...
Code:
fastboot --set-active=_b
fastboot erase userdata
fastboot erase DDR
3. Reboot system, and tell me what happens.
**Do NOT attempt to use TWRP with this. You'll probably have to reflash stock firmware to the slot you tampered with to get everything back to normal afterwards.**
Link: 64bit Folder
This is not source built, and it's very much a hack job, so I'm really not expecting anything to work. I did get Ubuntu installed this morning, so I will attempt to build from source in the near future.
Please don't use this if you don't know what a "brick" is or how to recover from one
PS: it probably wont work cause vendor is twice the size xD
The G7 play is coming so far little by little it was like yesterday we never thought we would have twrp and magisk and now in fact we do on a GSI
([emoji88]Havoc GSI[emoji88])
00p513 said:
PS: it probably wont work cause vendor is twice the size xD
Click to expand...
Click to collapse
You are correct. She's way too hefty. It's ~164mb too large. I tried resizing last night, but I can only shrink it to 433mb. I can probably remove the modem files and replace them with the ones from stock. I think it's where most of the extra weight is from. The 64bit libs are about 1.5x bigger, but I don't think that accounts for all of it. The Muppets have a tree for sdm632, so all I need to do is look at it, and delete everything in vendor that's not in there. It should help but I'm not sure if it'll be enough. I could repartition it, but I'm not a fan of resizing partitions because I'm very fearful of bricks.
Spaceminer said:
You are correct. She's way too hefty. It's ~164mb too large. I tried resizing last night, but I can only shrink it to 433mb. I can probably remove the modem files and replace them with the ones from stock. I think it's where most of the extra weight is from. The 64bit libs are about 1.5x bigger, but I don't think that accounts for all of it. The Muppets have a tree for sdm632, so all I need to do is look at it, and delete everything in vendor that's not in there. It should help but I'm not sure if it'll be enough. I could repartition it, but I'm not a fan of resizing partitions because I'm very fearful of bricks.
Click to expand...
Click to collapse
I can get a bit more space with an ocean gpt.bin btw. i suppose we could see how those files work i guess and make a bigger vendor?
00p513 said:
I can get a bit more space with an ocean gpt.bin btw. i suppose we could see how those files work i guess and make a bigger vendor?
Click to expand...
Click to collapse
Have you flashed the gpt.bin from ocean before? If so I'll definitely try using that with the slightly smaller vendor I made. I'm thinking most things from Ocean should work natively. The only difference is screen size by a few pixels, ram, and battery capacity. Otherwise they're essentially the same.
Spaceminer said:
Have you flashed the gpt.bin from ocean before? If so I'll definitely try using that with the slightly smaller vendor I made. I'm thinking most things from Ocean should work natively. The only difference is screen size by a few pixels, ram, and battery capacity. Otherwise they're essentially the same.
Click to expand...
Click to collapse
yeah i use channel firmware extracted, then i use motoflash2sh to generate a bashscript from the flashfile. I then replace gpt .bin and remove it from the md5 checks at the beginning of the script. run the script and im repartitioned!
00p513 said:
yeah i use channel firmware extracted, then i use motoflash2sh to generate a bashscript from the flashfile. I then replace gpt .bin and remove it from the md5 checks at the beginning of the script. run the script and im repartitioned!
Click to expand...
Click to collapse
That's awesome! I'll try working with this.
Spaceminer said:
That's awesome! I'll try working with this.
Click to expand...
Click to collapse
ill send a repartition kit later. just unzip and run the script
00p513 said:
ill send a repartition kit later. just unzip and run the script
Click to expand...
Click to collapse
I already found it. So I'd just remove 61863ba7dac0c512d610ffa6406a50f8 and it'll flash correct?
Code:
md5sum --check <<EOF || exit 1
[B]61863ba7dac0c512d610ffa6406a50f8[/B] *gpt.bin
Spaceminer said:
I already found it. So I'd just remove 61863ba7dac0c512d610ffa6406a50f8 and it'll flash correct?
Code:
md5sum --check <<EOF || exit 1
[B]61863ba7dac0c512d610ffa6406a50f8[/B] *gpt.bin
Click to expand...
Click to collapse
that whole line needs deleting. That is just to stop it failing on md5 verification ,as it is a dfiferent file
Spaceminer said:
I already found it. So I'd just remove 61863ba7dac0c512d610ffa6406a50f8 and it'll flash correct?
Code:
md5sum --check <<EOF || exit 1
[B]61863ba7dac0c512d610ffa6406a50f8[/B] *gpt.bin
Click to expand...
Click to collapse
Did it work? Any update on the vendor image?
00p513 said:
Did it work? Any update on the vendor image?
Click to expand...
Click to collapse
I haven't tried it yet. I got side tracked compiling twrp. I'm 3 errors away from success. Something about unknown compiler flags.
As an FYI, I'm out of a computer for the next several months, possibly up to a year. I'm going through a nasty divorce at the moment, and that's all I'm going to say about that. I'll get back into the game as soon as I can, but for now, you should not expect me to put out anything new for quite awhile. I can and will help people as much as possible during this time. But my ability to do so is going to be hindered without an PC.
I'm sorry to hear that. My divorce lasts since two years.
However, that's not why I registered. I received a Moto G7 Play for app security testing just a few days ago and found this forum when trying to install GSI to the phone. Everything works fine, but I'm interested to upgrade the OS to 64bit. Therefore, I'd like to try out the work already present in this thread. Unfortunately, I have neither found the repartition kit nor gained enough information about gpt.bin file format yet in order to repartition the flash memory of the G7 Play.
I'd really appreciate if anybody could either post or send me the repartition kit or supply information about the partition table format, because I failed to google for that kind of information.
[edit] Ok, I found out how to change partition size to the size of ocean. I flashed the following images:
* Partition table from ocean
* Everything else except system_a from channel
* system_a from phh (binder64)
Everything worked just fine.
Then I proceeded to flash the files posted in this thread earlier. The vendor64.img fits into the new partition layout just fine. After flashing all 4 files, I proceeded to flash phh 64bit version. Then I rebooted, but the boot failed:
First, the device showed up some very long hexadecimal number (maybe some UUID?) on a black screen, where it had shown "bad key" before when everything went right.
Afterwards, it ran into fastboot:
Start Up Failed:
Your device didn't start up successfully.
Use Software Repair Assistant on computer to repair your device.
Connect your device to your computer to get the Software Repair Assistant.
AP Fastboot Flash Mode (Secure)
Failed to verify hab image boot_a
Error: failed to load kernel!
No bootable A/B slot
Failed to boot Linux,falling back to fastboot
Fastboot Reason: Fall-through from normal boot mode
Click to expand...
Click to collapse
So, I'm back on binder64 again.
Please, could you provide any help for fixing the images, or at least the information how you have built the 64bit images?
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
Blu G90 device shipped from factory with Android 10
as with other devices from blu they do not have a public download of there roms. So here is the stock rom pulled from the device with SP-Flash tool.
Both the shipped rom build fingerprint
Code:
ro.bootimage.build.fingerprint=BLU/G90/G0310WW:10/QP1A.190711.020/1585383273:user/release-keys
And the ota update from June fingerprint
Code:
ro.system.build.fingerprint=BLU/G90/G0310WW:10/QP1A.190711.020/1592848714:user/release-keys
are in android file host flash-able with spflash tool, if needed.
I know the first thing to have before modifying android is the method to recover from bad edits. So here they are.
Other works will be stored in this same folder.
https://www.androidfilehost.com/?w=files&flid=315927
First stock rom is Dumped to github, If you need or want specific files, without needing to download whole rom.
https://github.com/mrmazakblu/blu_g0310ww_dump
Stock kernel source:
https://github.com/mrmazakblu/Blu_G90_G0310WW_stock_kernal
Device INFO
*******Above links are pulled firmware. Below is an official firmware file, w/ verified images.********
https://www.mediafire.com/folder/ocmvgrcd73bqy/G90
**
.
Bootloader unlock is same as past devices.
1. enable develper options
2. enable OEM unlock , from inside developer options
3. Reboot to bootloader (adb reboot bootloader, or button combo)
4. fastboot flashing unlock
5. Select confirm on device
6. fastboot reboot (causes factory reset)
Flashing GSI
few more steps than Pie devices, but not too complicated.
You will need recent fastboot tools as tested these steps were done with V30.0.4
https://developer.android.com/studio/releases/platform-tools
Verified boot is enabled on device. The verity key is stored into 3 section.
vbmeta.img
vbmeta_system.img
vbmeta_vendor.img
All found in stock rom. Shared in first post.
1. Unlock bootloader. (see last post)
2. Reboot to bootloader to disable verity
Code:
fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img
fastboot --disable-verity --disable-verification flash vbmeta_system vbmeta_system.img
fastboot --disable-verity --disable-verification flash vbmeta_vendor vbmeta_vendor.img
3. Reboot from bootloader to fastboot(new interface for android 10)
Code:
fastboot reboot fastboot
4. flash sysem from "fastbootd"
Code:
fastboot flash system **gsi-system.img**
Use 64 bit AB GSI
5. Wipe data so the new system will work
Code:
fastboot -w
ROOT::
Not yet confirmed yet. Magisk patched_boot has not provided root as of yet.
Currently looking into pre-rooting the system.img, but not success yet.
TWRP;;
https://forum.xda-developers.com/android/development/twrp-twrp-3-4-0-0-blu-g90-g0310ww-t4163497
.
I have been able to edit the stock /system and flash it back to phone.
--I have added adaway host file
--Removed the SIMO app
-- Removed the IGNITE adware app (dti.blu)
--Removed The Verizon Remote SIM lock app
--Removed Blu-Privacy app
--Removed Opera browser app
--Deodexed Rom (rom would not boot past splash screen without this)
Uploaded edited sysem.img to device folder listed in OP.
Flash with same instructions as How to flash GSI
--Attempting to add SU binary makes rom fail to boot. So still no stock rooted.
Maybe soon.
/
Blu released kernel source today. 8-27. The tar.hz is dated April, eh, whatever.
I added the source files to the wip twrp tree, it compiles without error. (Not my normal experience , on first time out with Blu kernel).
But as mentioned before, the twrp will not pack the image correctly. Because of the need for new dtb commands that twrp 9.0 build environment does not accept.
And when building in the twrp 10.0-wip tree, the results have not booted for me yet. (I'm on build attempt 12, or so)
I'm rambling, sorry.
When I repack the twrp using the built kernel, twrp has only blank screen, and adb is active. So kernel is slightly off.
Build did not output separate dtb or dtbo.
Well I confirmed it, the screen on this phone is not the one the kernel is building for.
I compared the defconfig from source, the one that matches the name in build prop, to the one I pulled from /proc. And they are different, and the kernel errors out during build when using right defconfig. So, waiting again for Blu to provide the files.
There does not appear to be any interest in this phone, other than my own.
Well maybe it will catch on
It's been advertised on many mm ore locations than the average BLU phone.
Amazon
Ebay
Walmart
Newegg
Best buy
B&H photo
Time will tell.
mrmazak said:
Well I confirmed it, the screen on this phone is not the one the kernel is building for.
I compared the defconfig from source, the one that matches the name in build prop, to the one I pulled from /proc. And they are different, and the kernel errors out during build when using right defconfig. So, waiting again for Blu to provide the files.
Click to expand...
Click to collapse
Any luck with Blu providing the correct kernel files?
Ivisibl3 said:
Any luck with Blu providing the correct kernel files?
Click to expand...
Click to collapse
Not yet. They acknowledged my email, but as yet have not updated there posted source.
Root is half way achieved.
Factory rom was found. It included a boot-debug.img
When this image is used in boot partition, adb root is allowed.
It is only limited root. Example: blockdev command , used to allow remount / to rw, is not permitted. Bit is start.
Factory flashtool rom shared on Blu developers mediafire page.
Will add link to debug-boot.img soon
added to device folder listed in OP
google information on debug-boot.img
https://source.android.com/compatibility/vts/vts-on-gsi
if you have the stock boot.img, and magisk manager, why cant you patch the boot.img and then disable dm-verity by flashing vbmeta.img/vbmeta_system.img/vbmeta_vendor.img and then flash the boot.img via sp flash tool to give you root access?
aryanhington said:
if you have the stock boot.img, and magisk manager, why cant you patch the boot.img and then disable dm-verity by flashing vbmeta.img/vbmeta_system.img/vbmeta_vendor.img and then flash the boot.img via sp flash tool to give you root access?
Click to expand...
Click to collapse
because magisk init is not starting on a patched image. have no sign on magisk in the any of the logs.
the issue is posted on magisk github issue tracker. no solution as of yet.
mrmazak said:
because magisk init is not starting on a patched image. have no sign on magisk in the any of the logs.
the issue is posted on magisk github issue tracker. no solution as of yet.
Click to expand...
Click to collapse
why this that occurring, because for umidigi devices on android 10 work fine https://community.umidigi.com/forum.php?mod=viewthread&tid=19114 and they also use a mediatek chipset?
aryanhington said:
why this that occurring, because for umidigi devices on android 10 work fine https://community.umidigi.com/forum.php?mod=viewthread&tid=19114 and they also use a mediatek chipset?
Click to expand...
Click to collapse
different brand, so built differant. just like ther are redmi (xiamoi) devices with mtk, but fastboot unlock doe not work, it needs redmi app to unlock. and flash tool not work on all devices with MTK, like amazon fire device , they have mtk and do not work with fastboot unlock, or spflash.
mrmazak said:
I have been able to edit the stock /system and flash it back to phone.
--I have added adaway host file
--Removed the SIMO app
-- Removed the IGNITE adware app (dti.blu)
--Removed The Verizon Remote SIM lock app
--Removed Blu-Privacy app
--Removed Opera browser app
--Deodexed Rom (rom would not boot past splash screen without this)
Uploaded edited sysem.img to device folder listed in OP.
Flash with same instructions as How to flash GSI
--Attempting to add SU binary makes rom fail to boot. So still no stock rooted.
Maybe soon.
/
Click to expand...
Click to collapse
which steps did you take to modify the stock /system?
aryanhington said:
which steps did you take to modify the stock /system?
Click to expand...
Click to collapse
used superr script to unpack stock super.img and continued to extract system.img
manually went through the extracted system/system/app folder and deleated the aps I did not want (adware// bloate)
used the rom tools option / deodex
then repacked the system.img
aryanhington said:
why this that occurring, because for umidigi devices on android 10 work fine https://community.umidigi.com/forum.php?mod=viewthread&tid=19114 and they also use a mediatek chipset?
Click to expand...
Click to collapse
This is not entirely true.
Many Umidigi phones have been upgraded from 9 to 10. So the partitions would be very similar and considerably easy to root.
But for new phones coming with 10 the story changes. Read the last pages of your link's article. In addition, I know why and effect on Umidigi Power 3 still has limitations on root.
So this BLU G90 is not very different and depends on a lot of experimentation and tests. I believe that the OP is doing a great job mainly taking everything to github and trying to compile the kernel and firmware.
DragonPitbull said:
This is not entirely true.
Many Umidigi phones have been upgraded from 9 to 10. So the partitions would be very similar and considerably easy to root.
But for new phones coming with 10 the story changes. Read the last pages of your link's article. In addition, I know why and effect on Umidigi Power 3 still has limitations on root.
So this BLU G90 is not very different and depends on a lot of experimentation and tests. I believe that the OP is doing a great job mainly taking everything to github and trying to compile the kernel and firmware.
Click to expand...
Click to collapse
can you elaborate what you mean by this?