Related
Hello,
First of all, I am not attempting to compete with the other awesome images for the G Tablet available. I am doing this process to learn, and maybe contribute to the community.
I have grabbed the AOSP directly from Google's repo tree, and compiled it in two different ways: Generic build, modifying BoardConfig.mk and other files as necessary. I have also used the Device/Vendor files from the Cyanogen Beta 4 harmony repo tree, and compiled a harmony target with AOSP.
When I compiled the generic build (or the the targeted build), I made sure all proprietary files from the tablet had been extracted and replaced in my system.img. (I got this list from the extract-files.sh script in Cyanogen harmony repo).
I have found that using the stock boot.img from the original nvflash files will boot nearly any system.img (from my update.zip in clockwork). I used this original boot.img, combined with my system.img from the AOSP build (with the proprietary files in place), and made an updater-script which installed things. I found that the system.img was properly extracted to /system.
The problem that occurs -- when booting, the Viewsonic bootup screen will load the GTablet screen, but it will eventually loop back to the Viewsonic screen and report "deleting msc" prior to returning to Recovery Mode on it's own.
I have enabled ADB persistence in the boot ramdisk, and it works fine as long as it's not my system.img. When I use the AOSP system.img, adb devices shows the device, but adb shell/logcat fail until the device power cycles.
Does anyone know what I might be missing?
Also want to add:
I have tried the stock boot.img, which lacks a 'cmdline' parameter, and I have tried using the cmdline parameters from the Cyan Harmony boot.img specifications. I am not sure if this might have something to do with the issue or not.
kornyone said:
Hello,
First of all, I am not attempting to compete with the other awesome images for the G Tablet available. I am doing this process to learn, and maybe contribute to the community.
I have grabbed the AOSP directly from Google's repo tree, and compiled it in two different ways: Generic build, modifying BoardConfig.mk and other files as necessary. I have also used the Device/Vendor files from the Cyanogen Beta 4 harmony repo tree, and compiled a harmony target with AOSP.
When I compiled the generic build (or the the targeted build), I made sure all proprietary files from the tablet had been extracted and replaced in my system.img. (I got this list from the extract-files.sh script in Cyanogen harmony repo).
I have found that using the stock boot.img from the original nvflash files will boot nearly any system.img (from my update.zip in clockwork). I used this original boot.img, combined with my system.img from the AOSP build (with the proprietary files in place), and made an updater-script which installed things. I found that the system.img was properly extracted to /system.
The problem that occurs -- when booting, the Viewsonic bootup screen will load the GTablet screen, but it will eventually loop back to the Viewsonic screen and report "deleting msc" prior to returning to Recovery Mode on it's own.
I have enabled ADB persistence in the boot ramdisk, and it works fine as long as it's not my system.img. When I use the AOSP system.img, adb devices shows the device, but adb shell/logcat fail until the device power cycles.
Does anyone know what I might be missing?
Click to expand...
Click to collapse
Did you ever get your AOSP build to boot?
tjohnsonjr said:
Did you ever get your AOSP build to boot?
Click to expand...
Click to collapse
I did. It's in the Dev section now
MT6592 CM 12.1 PORTING GUIDE
Lots of people asked me how i ported cm 12.1 from @fire855's compiled rom for kingzone k1 Turbo
First of all huge thanks to @fire855 and other Dev who helped him for bringing cm 12.1 on mt6592
Give support to him via pressing thanks or Donate , here is it's Link : http://forum.xda-developers.com/and...od-12-kingzone-k1-turbo-t3119908#post61000671
Requirements :
1. Stock Rom KK
2. Working Good Custom Recovery
3. Good Porter and Mind
Lets Start This Short Guide :
1. Download Latest Cm 12.1 from above link
2. Extract in a new folder
3. Use this tool LInk : http://forum.xda-developers.com/android/development/tool-convert-folder-to-ext4-format-t3099237
unpack .dat file and copy extracted system folder in new folder as stated in step 2.
4. Using @michfood's tool (link : http://forum.xda-developers.com/showthread.php?t=2036528)
change Kernel and Do necessary changes acc. to your stock's ramdisk
5. Copy new boot.img that created in step 4 and replace in new folder as stated in step 2.
6. From stock kk rom ...........extract libaudio.primary.default.so (system/lib) and modem.img (system/etc/firmware) nd replace in cm 12.1 's rom ................ in the same location
7. Delete meta-inf folder of cm 12.1's rom and extract this (link : https://www.sendspace.com/file/vnf0gi)
8. Open meta-inf's updater-script in notepad++ and change mountpoint of system acc. to your's phone
9. Pack the folder as in zip format and flash via recovery
( meta-inf, install ,system, boot.img, file context these files must there in zip )
10. Voila Rom booted .............if not comment
If Rom Booted ..............Follow this steps :
1. Download this apk (link : http://forum.xda-developers.com/showthread.php?t=2524485)
2. Go to Settings>developer>enable root and install apk from step 1
3. Open app and Set as permissive ,reboot Your device
4. Voila your wifi,bluetooth etc will start working, even Dual Sim
5. If you faced basedband unknown that mean restore your imei
6. For Home Key Bug , Edit generic.kl and mtk-kpd.kl (system/user/keylayout)
7. For Storage Bug, Edit Framework-res.apk and set sdcard1 as primary and edit boot's ramdisk MT6592.rc, fstab
8. For Other Bugs, Let Me Know
Notice : Always give thanks and link of @fire855's Rom Link
Credits : everyone (who's name i added in this guide and there's tools )
@[email protected] Thanks for a great guide, I was able to succesfully port the rom and it booted as well and after setting the selinux to permission my sims also started working but mic is not working, my device is MT6582 (Intex Aqua Speed). I have a working CM11 already ported for my device which is working perfectly fine. Also the soft keys (capacitive keys are not working nor even the power button). Please advise...
contactwajeeh said:
@[email protected]. . . . but mic is not working . . . .
Click to expand...
Click to collapse
The microphone is also not working in all apps (except Telephone where it work's fine) in the original CM12.1 by fire855 for the Kingzone K1. (The Rom this Porting Guide is based on).
That could be part of the problem.
Dominic
G-GFFD said:
The microphone is also not working in all apps (except Telephone where it work's fine) in the original CM12.1 by fire855 for the Kingzone K1. (The Rom this Porting Guide is based on).
That could be part of the problem.
Dominic
Click to expand...
Click to collapse
But its not working in calls as well. BTW I am using @moonrotation build as my base. I haven't asked for permissions to port it yet. But that should be fine as far as I dont do the public release of it.
What necessary changes i must do in ramdisk?help
contactwajeeh said:
But its not working in calls as well. BTW I am using @moonrotation build as my base. I haven't asked for permissions to port it yet. But that should be fine as far as I dont do the public release of it.
Click to expand...
Click to collapse
currently mic problem is there ....wait for fixes
contactwajeeh said:
@[email protected] Thanks for a great guide, I was able to succesfully port the rom and it booted as well and after setting the selinux to permission my sims also started working but mic is not working, my device is MT6582 (Intex Aqua Speed). I have a working CM11 already ported for my device which is working perfectly fine. Also the soft keys (capacitive keys are not working nor even the power button). Please advise...
Click to expand...
Click to collapse
edit keylayout's genric.kl etc
mirrr46 said:
What necessary changes i must do in ramdisk?help
Click to expand...
Click to collapse
like some some extra lines der in urs .
Tried to port this, Device reboots right after vendor logo
I compare stock Ramdisk with CM12. There are no diff. At end both have same values. I changed Kernel and Kernel Header
I changed the updater script so it fits to my partition. It gave me strange errors:
lsetfilecon of /system/lost+found to ubject_r:system_file:s0 failed: No such file or directory
m_file:s0 failed: Operation not supported on transport endpoint
Error flashing Zip : Failed
Updating partition details...
Click to expand...
Click to collapse
Also @michfood's tool just ain't work here, i took the v4 for my x64 win8.1. The Program is unable to extract the Ramdisk path, so i was forced to use "MTK Firmware Adapter Tool"
Recovery:TWRP 2.8.1.0
SoC:MT6592
Device: Doogee DG550
Traace said:
Tried to port this, Device reboots right after vendor logo
I compare stock Ramdisk with CM12. There are no diff. At end both have same values. I changed Kernel and Kernel Header
I changed the updater script so it fits to my partition. It gave me strange errors:
Also @michfood's tool just ain't work here, i took the v4 for my x64 win8.1. The Program is unable to extract the Ramdisk path, so i was forced to use "MTK Firmware Adapter Tool"
Recovery:TWRP 2.8.1.0
SoC:MT6592
Device: Doogee DG550
Click to expand...
Click to collapse
1. don't touch kernel header....change only kernel
2. u should try other recovery like philz
3. delete lost and found folder if present
4. use my meta-inf only....just change mountpoint of system........it seems u need good recovery with lp supported or philz recovery :fingers-crossed:
Thanks for guide.
My camera does not work and gallery does not see SD card.
How to fix it?
mirrr46 said:
Thanks for guide.
My camera does not work and gallery does not see SD card.
How to fix it?
Click to expand...
Click to collapse
1. camera icon in launcher is issue (for mt6592)
2. for storage...fixes r from mt6592.rc in this file read proper sysmlink and do changes acc. to it ,decompile framework-res.apk....set sdcard1 as primary ,fstab changes also needed
Enforcing to Permissive
Does anyone know how to make selinux permissive without any app,I tried to change ro.build.selinux and set it to 0 but it didn't work...does anyone know what to edit in ramdisk to make selinux permissive.?
Traace said:
Tried to port this, Device reboots right after vendor logo
I compare stock Ramdisk with CM12. There are no diff. At end both have same values. I changed Kernel and Kernel Header
I changed the updater script so it fits to my partition. It gave me strange errors:
Also @michfood's tool just ain't work here, i took the v4 for my x64 win8.1. The Program is unable to extract the Ramdisk path, so i was forced to use "MTK Firmware Adapter Tool"
Recovery:TWRP 2.8.1.0
SoC:MT6592
Device: Doogee DG550
Click to expand...
Click to collapse
I'm still struggling to port this rom to DG550.
1. The tool you used to extract the kernel does not work in Windows 8.1 and Windows 10 (I got empty RAMDISK folder). So I switched back to Windows 7 and it worked well.
2. Compared both Ramdisk folders in Stock DG550 Kitkat and Stock Kingzone K1 Kitkat boot.img's.
There is no difference except in ueventd.rc file. I tried to mix DG550 kernel and Kingzone Z1 stock Ramdisk with DG550 Kitkat rom. It didn't boot at first. The problem was in ueventd.rc file. See line 152 (Mali Node). After replacing ueventd.rc file from DG550 ramdisk it booted and worked well (stock kitkat rom). So both the stock ramdisks are identical if ueventd.rc file is replaced.
3. But it fails when porting the boot.img for CM12.1. Theoretically CM12.1 ramdisk should work with DG550 kernel for CM12.1 rom without any changes (except ueventd.mt6592.rc). It does not pass the boot logo.
4. Also I noticed that there's some issue in sbin folder in ramdisk.
ADev_28 said:
Does anyone know how to make selinux permissive without any app,I tried to change ro.build.selinux and set it to 0 but it didn't work...does anyone know what to edit in ramdisk to make selinux permissive.?
Click to expand...
Click to collapse
/system/bin/setenforce 0
From any root terminal.
Thanks,
1. But i did port for mtk6582 (camera unfortunelty has stop)
chanaka89 said:
I'm still struggling to port this rom to DG550.
1. The tool you used to extract the kernel does not work in Windows 8.1 and Windows 10 (I got empty RAMDISK folder). So I switched back to Windows 7 and it worked well.
2. Compared both Ramdisk folders in Stock DG550 Kitkat and Stock Kingzone K1 Kitkat boot.img's.
There is no difference except in ueventd.rc file. I tried to mix DG550 kernel and Kingzone Z1 stock Ramdisk with DG550 Kitkat rom. It didn't boot at first. The problem was in ueventd.rc file. See line 152 (Mali Node). After replacing ueventd.rc file from DG550 ramdisk it booted and worked well (stock kitkat rom). So both the stock ramdisks are identical if ueventd.rc file is replaced.
3. But it fails when porting the boot.img for CM12.1. Theoretically CM12.1 ramdisk should work with DG550 kernel for CM12.1 rom without any changes (except ueventd.mt6592.rc). It does not pass the boot logo.
4. Also I noticed that there's some issue in sbin folder in ramdisk.
Click to expand...
Click to collapse
Please let us know if u can let it boot
Ramdisk sBin shoudn't be a problem, if they really cause trouble, try copy the missing files from base dg550 kk to cm12
[email protected] said:
1.
Click to expand...
Click to collapse
Thank you very much... Your guide was very appreciated... Work like a charm..
I used the device MT6592 - BLU VIVO IV of the my friend for port CM12.1
Sent from my LIFE PLAY X KK using XDA Free mobile app
lopestom said:
Thank you very much... Your guide was very appreciated... Work like a charm..
I used the device MT6592 - BLU VIVO IV of the my friend for port CM12.1
Sent from my LIFE PLAY X KK using XDA Free mobile app
Click to expand...
Click to collapse
congo
Traace said:
Please let us know if u can let it boot
Ramdisk sBin shoudn't be a problem, if they really cause trouble, try copy the missing files from base dg550 kk to cm12
Click to expand...
Click to collapse
mirrr46 said:
1. But i did port for mtk6582 (camera unfortunelty has stop)
Click to expand...
Click to collapse
seems storage bug...u need to fix storage .............check guide and comments
chanaka89 said:
I'm still struggling to port this rom to DG550.
1. The tool you used to extract the kernel does not work in Windows 8.1 and Windows 10 (I got empty RAMDISK folder). So I switched back to Windows 7 and it worked well.
2. Compared both Ramdisk folders in Stock DG550 Kitkat and Stock Kingzone K1 Kitkat boot.img's.
There is no difference except in ueventd.rc file. I tried to mix DG550 kernel and Kingzone Z1 stock Ramdisk with DG550 Kitkat rom. It didn't boot at first. The problem was in ueventd.rc file. See line 152 (Mali Node). After replacing ueventd.rc file from DG550 ramdisk it booted and worked well (stock kitkat rom). So both the stock ramdisks are identical if ueventd.rc file is replaced.
3. But it fails when porting the boot.img for CM12.1. Theoretically CM12.1 ramdisk should work with DG550 kernel for CM12.1 rom without any changes (except ueventd.mt6592.rc). It does not pass the boot logo.
4. Also I noticed that there's some issue in sbin folder in ramdisk.
Click to expand...
Click to collapse
i don't think so....again try and don't touch ramdisk
[email protected] said:
congo
seems storage bug...u need to fix storage .............check guide and comments
i don't think so....again try and don't touch ramdisk
Click to expand...
Click to collapse
How to solve storage bug??
Device booted.Not able to mount/access storage. ??
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?
Hi everyone, I am a RMX2071 owner and I was experimenting with GSI images, I have installed the AOSP 10 GSI (AOSP 10.0 v222) Source: https://github.com/phhusson/treble_experimentations/releases/tag/v222
Seems like it works except for the fingerprint (it doesn't work) and the camera that could be better. I'm not a developer nor I'm familiar with Android modding. I have bricked my phone several times during the attempt. This is not an advice or guide, everything you do is at your own risk.
I had unlocked bootloader and TWRP (Source: https://forum.xda-developers.com/realme-x50-pro/how-to/recovery-lr-team-twrp-3-4-1b-0616-t4123353)
This is what I did:
I have downloaded the latest firmware for my device from realmeupdater (https://realmeupdater.com/)
It was an OZIP file, I have unpacked with this tool (https://github.com/bkerler/oppo_ozip_decrypt)
Now I have a zip file
I have downloaded a GSI .img image (I have tried many, the one listed is the one that works best for now)
I have used this tool (https://github.com/xpirt/img2sdat) to convert .img to three .dat files: system.new.dat, system.patch.dat, system.transfer.list
I have used this other tool (https://github.com/VarunSaiTeja/Brotli-Rom-Manager) to convert system.new.dat into system.new.dat.br
I have deleted this three files from the the official rom zip, using 7zip: system.new.dat.br, system.patch.dat, system.transfer.list
I have added to the official rom zip the files just created: system.new.dat.br, system.patch.dat, system.transfer.list
I have put the zip on a flash drive. I have booted in recovery, wiped everything, flashed the zip, closed AVB2.0 from advanced menu, booted into system.
There could be many bugs I have only tested for some hours, I'm sharing this because some expert could find a way to make fingerprint work, modify the top bar to accommodate the camera hole and find a better camera app.
I'm uploading the zip I have created, I'll post it soon.
Pic: https://mega.nz/file/8ApUXYBJ#kYBqwpDfMEF_MdxLCnTQCtITA8rV6YlENWCkkPzMM1E
link to the modified zip: https://mega.nz/file/gN5gjKTB#pkQHQotBhY7IocGZWj9iwwWEoTM9x5APSVYsTgH4Pak
You flash this gsi zip with twrp ?
I did try before to install GSIs on this phone without success, if thats it, ill try it and see what i can do
Just wondering again; What either in theory or practice prevents from using an Android 11 GSI with this phone?
I don't understand the Project Treble/GSI mechanism enough.
Shouldn't every device from Android 9 (shipped with, that is) able to run a stock android image? i.e. why would this not work - https://developer.android.com/topic/generic-system-image
Saitb said:
Pic: https://mega.nz/file/8ApUXYBJ#kYBqwpDfMEF_MdxLCnTQCtITA8rV6YlENWCkkPzMM1E
link to the modified zip: https://mega.nz/file/gN5gjKTB#pkQHQotBhY7IocGZWj9iwwWEoTM9x5APSVYsTgH4Pak
Click to expand...
Click to collapse
Any update?
after return x50 pro in service center they bring it broken. cán someone help me run unblock bootloader on android 11 , downgrade to android 10 with https://c.realme.com/in/post-details/1294219896854413312
in only work for android 10. i find reverse engineer maybe hacker can change it to work in android https://bgzashtita.es/android/Downloads.rar it is reverse engineer that need to be made work for abdroid 11.
here my friend yestarday call realme and put livestream on youtube. realme lie it is for indian
here photos:
Jordi Ba
https://bgzashtita.es/android/photo/IMG2...035605.jpg
https://bgzashtita.es/android/photo/IMG2...040043.jpg
https://bgzashtita.es/android/photo/IMG2...040100.jpg
https://bgzashtita.es/android/photo/IMG2...040300.jpg
https://bgzashtita.es/android/photo/IMG2...052200.jpg
https://bgzashtita.es/android/photo/IMG2...052208.jpg
https://bgzashtita.es/android/photo/IMG2...052223.jpg
https://bgzashtita.es/android/photo/IMG2...052244.jpg