Related
AROMA/TWRP version of SPFlash Tools.
This tool is for MTK devices with a GPT layout - (MT6732, MT6752 and their variants).
With some testing it may be possible to add some some support for the older devices using an MBR.
Requirements:Copy SPFlash contents to /sdcard/SPFlash
Rename *scatter.txt to scatter.txt
Run .zip from TWRPMTK-64bit_SoCs-v*.zip:During testing there will only be info displayed on screen, nothing should be modified. (Unless otherwise stated)SPFlash-v*.zip:This will install all .img/.bin in SPFlash folder if partition is large enoughDownloads:GDrive FolderChangelogs:SPFlash
v10 - Readded internal sd - fixed aroma exit/about screen - (a few cosmetic issues introduced).
v8 - Aroma menus updated
v7 - Create 'flashable' zip from backed up partitions.
v6 - Zipped backups added
v4 - Backup + Install fixed -- Aroma "Quit Installation" stalls
v3 - Backup function added - untested -- backup works / install from v2 broken
v2 - Menu Select Added
v1 - Initial Release
MTK-64bit_SoCs
v8 - attempts to fix unrelated menu/alert
v7 - calculations done quicker
v6 - script rewrite/reorder
v1 - v5: Initial test builds
Only follow menu Partition Related -> Scatter Information
Other menus/option are broken/dead ends...
Other things in the MTK folder:simg2img/img2simg are arm source compiled binaries to handle sparse files
file/magic were taken from @osm0sis's AIK (I can't seem to get file to compile)
MTKsplit is used to split boot/recovery images into it's individual parts. Normal images will split into 3; 1 = img ANDROID! header, 3 = kernel (zImage) and 5 = ramdisk (ramdisk). MTK images split into 5; 1,3,5 as before with 2 and 4 being additional headers.
XDA:DevDB Information
TWRP/AROMA SPFlasher, Tool/Utility for all devices (see above for details)
Contributors
HypoTurtle
Source Code: https://drive.google.com/open?id=0B8WPOq9wZyKxfktHVWgxbW9nYmtJd1ZWc2RIM1NXUU5pSXpramg0bVBYYUdyRDhid3hwM3c
Version Information
Status: Testing
Current Stable Version: V8
Stable Release Date: 2015-09-03
Created 2015-09-03
Last Updated 2015-09-03
Current StatusMTK-64bit_SoCs-v8 .zip will output the partitions that it deems are incorrectly sized in the scatter.txt and will also check the .img/.bins in the SPFlash folder and determine what should go where and will determine if the partition is large enough for the respective .img/.bin
SPFlash-v1.zip will flash the entire contents of /sdcard/SPFlash folder
SPFlash-v3.zip allows selection of files /sdcard/SPFlash folder to install and has a backup option
Improvements NeededFor SPFlash-v2 will add a basic menu select option for what you want to flash...
In future versions will add backup option and partition resize
Will start to look at resize...
Derivative Work - using scatt and part from #1
ScatterfixGenerating a fixed scatter from a 'broken one'
Code:
[size=1]#!/sbin/sh
ldr=`pwd`
scatterfix(){
scatt \${b} \${c} \${d}
part \${p} \${q} \${r}
scttrbfr=`cat "${scatterloc:-$ldr}/scatter.txt"`
while IFS=" " read -r a b c && read -r d e f <&3; do
if [ $a = $d ]; then
if [[ ! ${b} = "DONT_USE" && ${b} != ${e} ]]; then
scttrafter="${scttrbfr//${b}/${e}}"
scttrbfr=`echo "${scttrafter}"`
fi
if [[ ! ${c} = "DONT_USE" && ${c} != ${f} ]]; then
scttrafter="${scttrbfr//${c}/${f}}"
scttrbfr=`echo "${scttrafter}"`
fi
fi
echo "${scttrbfr}" > ${scatterloc:-$ldr}/scatter-new.txt
done </tmp/scatter 3</tmp/parted-new
}
scatterfix
diff ${scatterloc:-$ldr}/scatter.txt ${scatterloc:-$ldr}/scatter-new.txt[/size]
Problems to fixThe code will change any hex value deemed wrong to a new calculated value - there is a chance that 4 values are the same but only one/two are wrong - to fix will need to add a loop through scatterfix until the scatter-new.txt generated is actually correct.Resize Userdata/IntsdMore of a precursor - bugs fixed and maintained by @odigitech
Thread located here
Some Dev. QuestionsBefore adding the resizing partitions (Firmware Upgrade) option:
1. Is the preloader header custom or generic; and does it change when flashing the proloader?
2. Is there an actual function to the BPLGU/APDB files other than some sort of device/system check?
For v7 trying to add a backup + make installable zip option:
Have done it with basic dd backups; would prefer to use sparse/simg2img but simgimg can't seem to use zipped .img's; have looked into using dat/sdat2img but that would require getting python to run in recovery (unless I'm mistaken).
Have added the simplistic option as v7...
odigitech said:
@HypoTurtle I have made a modified version of MTKsplit with more human-friendly names, its in my Drive folder, if it's any use.
Click to expand...
Click to collapse
Thanks, I have updated mine to support non-MTK header-ed boot/recovery.imgs -- can't hurt to make it human readable I suppose.
MTKsplit will be used in the next uploaded version (v8) in the form of a simplistic porting tool...
Should be uploaded on Monday/Tuesday
odigitech said:
You made it work for non-MTK also? Nice one, is it on your Drive?
Sent from my thl 2015 using XDA Free mobile app
Click to expand...
Click to collapse
Should be... but I'll update it with the human-readable version now.
It's not vigorously tested; and not as robust as the (un)mkbootimg binaries out there but it seems to do the job.
@HypoTurtle: on my Jiayu s3, the Germans have been working on android 5.1.1 for it and so far it is great. I installed beta 3 and the next day they released beta 4. Rather then getting out the laptop, I thought I'd use your script, so I got the files needed, I got your script and set it up as the instructions. But when I ran the script, it didn't find the system.img file, and didn't give it to me as an option. I verified that the file was there on disk, but I was never given a check box to select it for flashing. Any logs I can send you to try and figure out why?
Sent from my KFTHWI using XDA Premium 4 mobile app
AlexZap said:
@HypoTurtle: on my Jiayu s3, the Germans have been working on android 5.1.1 for it and so far it is great. I installed beta 3 and the next day they released beta 4. Rather then getting out the laptop, I thought I'd use your script, so I got the files needed, I got your script and set it up as the instructions. But when I ran the script, it didn't find the system.img file, and didn't give it to me as an option. I verified that the file was there on disk, but I was never given a check box to select it for flashing. Any logs I can send you to try and figure out why?
Sent from my KFTHWI using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Is it just the system.img that doesn't appear? And are you using internal or external SD?
HypoTurtle said:
Is it just the system.img that doesn't appear? And are you using internal or external SD?
Click to expand...
Click to collapse
Just system.img, and external_sd
Sent from my KFTHWI using XDA Premium 4 mobile app
AlexZap said:
Just system.img, and external_sd
Sent from my KFTHWI using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Can you post the scatter; the menu items are just an existence check.
[ if *.img/*.bin from scatter exists in SPFlash folder then you are given the option to flash it ]
(Just noticed that it will stall if you try and install and there are no valid img/bin files present)
HypoTurtle said:
Can you post the scatter; the menu items are just an existence check.
[ if *.img/*.bin from scatter exists in SPFlash folder then you are given the option to flash it ]
(Just noticed that it will stall if you try and install and there are no valid img/bin files present)
Click to expand...
Click to collapse
Screenshot of the folder, and the scatter. I checked it and it looked fine.
AlexZap said:
Screenshot of the folder, and the scatter. I checked it and it looked fine.
Click to expand...
Click to collapse
Ah yes - this problem is caused by the amount of items shown - I have it set to show 3, 5 or 12. It will only show 12 (more than 5) if there are 12 things to flash. From your screenshot you have 7 items to be flashed (trustzone gets flashed twice), so you will miss two items - the second flash of trustzone.bin and system.img.
Hope that makes sense; I can alter it to work with 6+; but you should be able to adjust it to work as described above. the reason I did it this way was that otherwise it would look a bit messy - I suppose I could add a 7 option.
HypoTurtle said:
Ah yes - this problem is caused by the amount of items shown - I have it set to show 3, 5 or 12. It will only show 12 (more than 5) if there are 12 things to flash. From your screenshot you have 7 items to be flashed (trustzone gets flashed twice), so you will miss two items - the second flash of trustzone.bin and system.img.
Hope that makes sense; I can alter it to work with 6+; but you should be able to adjust it to work as described above. the reason I did it this way was that otherwise it would look a bit messy - I suppose I could add a 7 option.
Click to expand...
Click to collapse
Ahhh... Not a. Problem then. I don't really need to flash anything besides system and boot. I just included the rest for completness. I'll take one out and let you know how it goes.
On a side note, any reason for these (3, 5, and 12)? An not just everything that is there?
Sent from my JY-S3 using XDA Premium 4 mobile app
HypoTurtle said:
Some Dev. QuestionsBefore adding the resizing partitions (Firmware Upgrade) option:
Q1. Is the preloader header custom or generic; and does it change when flashing the proloader?
Q2. Is there an actual function to the BPLGU/APDB files other than some sort of device/system check?
Click to expand...
Click to collapse
A1 - Generic, MTK preloader has been the same since armv7 to armv8. Yes, dd backup copy needs to be clean up of the header & footer, more info then checkout with AlexZap... :good:
A2 - Not all MTK firmware include it, it contains the IMEI refer to here for more info or a single link that explained everything... :good:
AlexZap said:
Ahhh... Not a. Problem then. I don't really need to flash anything besides system and boot. I just included the rest for completness. I'll take one out and let you know how it goes.
On a side note, any reason for these (3, 5, and 12)? An not just everything that is there?
Sent from my JY-S3 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Not sure if you missed the edit. It was more for cosmetic reasons - I could have had say 12 files being displayed but if there's only one file to flash you would have a screen with a lot of blank entries. 3, 5 and 12 seemed the most appropriate without going down the route of creating a menu for all possible entries.
3 being typical install (system/boot and perhaps blank cache/userdata to wipe); 5 as 3 but with custom etc.
I figured that anyone with more than 5 flashable items in there would have dumped the entire SPFlash ROM which I calculated as ~12 items.
yuweng said:
A1 - Generic, MTK preloader has been the same since armv7 to armv8. Yes, dd backup copy needs to be clean up of the header & footer, more info then checkout with AlexZap... :good:
A2 - Not all MTK firmware include it, it contains the IMEI refer to here for more info or a single link that explained everything... :good:
Click to expand...
Click to collapse
A2. I don't thing it contains the IMEI - but it is the database that the IMEI is coded against; I'm not aware of any devices (other than the P6000) suggesting that you recode the IMEI on an upgrade from KK to LP so there is probably not an issue here.
i never use it myself, typically MDRT is able to recover it on mine, feedbacks from fellow XDA member is that, that is the only way that they manage to recover IMEI on their MTK...
On 2nd thought, BTW, i'm using intel nowadays :laugh: IMEI & calibration info is at a hidden partition, same as Samsung & Qualcomm devices that reside at /efs partition, how did MTK IMEI survive Factory Reset since it is at /data/nvram, i wonder, never really thought about it...
yuweng said:
i never use it myself, typically MDRT is able to recover it on mine, feedbacks from fellow XDA member is that, that is the only way that they manage to recover IMEI on their MTK...
On 2nd thought, BTW, i'm using intel nowadays :laugh: IMEI & calibration info is at a hidden partition, same as Samsung & Qualcomm devices that reside at /efs partition, how did MTK IMEI survive Factory Reset since it is at /data/nvram, i wonder, never really thought about it...
Click to expand...
Click to collapse
On the 64bits at least it is also on a hidden partition (nvram) - and it just gets copied to /data/nvram or something (ie. its not mounted but it's files are there). The DB files etc are present in /system as well as in the full SPFlash ROM so I guess things like MTKEng and apps like chamelephon use that when setting/'fixing' the IMEI.
What are the file formats used by intel stock ROMS? This tool isn't really MTK dependant - it's GPT partition dependant (with a scatter for validity check- I'll post a bear minimum of what a 'scatter.txt' needs to have).
Anyway v8 added - so that files to flash aren't hidden (max. 12 files).
Hmm, further digging seems MTK IMEI is at /dev/nvram, same thing happening on intel, users just never spell out everything, they use the format/ erase flash/ emmc that wipes out the IMEI partition but never tell...
i think on the X3, its not possible as its NOT an Android image file but proprietary fls file which they got it when they acquire infineon i think...
Manual fastboot/ dd backup/ restore & you'll end up with a brick device, ATM, no custom recoveries that boot on the x3, i haven't figure out how to repack its recovery that has three separate different region that requires three proprietary download file that packs it together into a fls file & only their FlashTool_E2 is able to download it correctly...
Can't really understand infineon/ intel for developing such cheap device but with such high end software tools...
Hi,
I'm currently waiting for buy the Xperia XZ. I check some of XDA's thread and with Sony's smartphone I'm still afraid. So I want to know if there is a thread gathering all the detailled step to root, install TWRP, flash latest firmware, install custom ROM etc... ?
Thanks a lot
[Guide] Here is the DHGE guide for rooting SONY devices 2019-04
Changelog at the bottom of this post.
nathan30 said:
if there is a thread gathering all the detailed step to root, install TWRP, flash latest firmware, install custom ROM etc... ?
Click to expand...
Click to collapse
No - but you can find all you need to know here in this forum or in the devices-fora later than Z3+ or SONY-cross-device.
https://forum.xda-developers.com/crossdevice-dev/sony
Good introductory (written for devices before Z3+):
https://forum.xda-developers.com/crossdevice-dev/sony/noob-guide-to-sony-ericsson-xperia-t3209012
It is still valid but the 2015 and newer devices are not rootable anymore as described thanks to DM-Verity.
For rooting the current device you have to open the bootloader.
Any claims to the contrary found "on the web" are only tricks to have you install "interesting" software on a Windows PC.
Do you want root?
A classic post to help you decide
No:
wait for the OTA-updates from SONY (over the air - prosaic?)
don't like waiting or want to downgrade: get Flashtool http://www.flashtool.net
it comes with Xperifirm that finds you the latest ROM
https://forum.xda-developers.com/cr...xperifirm-xperia-firmware-downloader-t2834142
Unfortunately Xperifirm only finds the latest ROM (the only available on SONYs servers) so you better keep your downloads (>2 GBytes each) or find an older ROM in case you need it (xda has a search function). Here you'll find some ROM-versions: https://xpericheck.com
since my Xperia XZ/XZ1 I occasionally have problems with Flashtool that it requires a FSC-script which does not come with it or can not easily be copied from a similar device.
Now I use Newflasher https://forum.xda-developers.com/cr...gress-newflasher-xperia-command-line-t3619426 by @munjeni. This is a command line tool that for me unfortunately only works under Windows (have JDK issues under Debian).
You unpack the ROM (ftf-file) and place the newflasher.exe in the directory where you unpacked to. Then you start the device in flash mode (power on while holding the volume down key) and run the tool from the command line as administrator/root.
If you do not delete userdata.sin you will initiate the equivalent of a factory reset (aka loose all your data and settings!). For an upgrade within the same Andoid version I always delete userdata.sin before newflashing.
Yes:
As stated above, you need to unlock the bootloader to modify the system software on your device. Fortunately SONY gives (for non-carrier-locked) devices the option to unlock the bootloader.
Check if unlocking is allowed: in the service menu (dial *#*#7378423#*#* or *#*#SERVICE#*#* ) check under "Service Info"->"Configuration" the line "Bootloader unlock allowed:"
If you read anything other than "Yes" Stop here!
No: flashing another SONY Rom ("Customized CountryX") does not help you.
Hint: there is an app "SONY service menu" in the app-repository (F-Droid or Google).
OK - you can Now it is your last chance to save your device keys or "backup the trim area partition"
You should do this if you ever want to return to a SONY "blessed" state. e.g claiming service in countries where warranty is not for devices with unlocked bootloader or you want to sell it.
There are some device specific kernels out there whose authors state that they mitigate all DRM issues once the TA is restored. I guess you need these kernels otherwise restoring the TA locks up your device ...
Otherwise do not bother with restoring the TA-partition. Doing so after the next steps will soft brick your device.
Now you have to prepare your PC with some drivers in order to start the backup process:
Go to SONY's developver world http://developer.sonymobile.com
Under "Downloads" you will find the drivers for the XZ or any other device http://developer.sonymobile.com/downloads/drivers/xperia-xz/
These drivers are for Windows, do not bother if you are running a free operating system.
To get fastboot running you might additionally have to find the "fastboot_driver" in the download area. Put the content of the ZIP-file into the directory where you you unzipped the device driver and install it via right-clicking on the file android_winusb.inf.
Install these drivers if you are a Windows user. Under Windows 8 and newer there could be problems with installing "non signed" drivers.
Do a web/xda search to circumvent this security measure of Microsoft or do click on reboot while holding the shift-key and figure it out yourself.
http://www.flashtool.net/win8drivers.php
When you are installing: You also need to install the programs adb and fastboot.
https://forum.xda-developers.com/showthread.php?t=2317790
If you are running a free operating system: search for adb/fastboot or Android SDK in your repository and install these.
Running Linux it helps to insert the udev-rule mentioned in http://www.flashtool.net/lininstall.php otherwise you have to run esp. fastboot with root-privileges (not recommended, although the udev rule saves no punches ...)
On Android on your SONY device you have to be root to save a partition - catch 22 :crying: ...
https://en.wikipedia.org/wiki/Catch-22
Don't fear the ... / catch: For Android Marshmallow ROMs, e.g. up to version 39.0.A.3.30 of the Xperia XZ ROM, exists an exploit of the copy on write function in the Linux kernel that gets you root privileges temporarily.
On newer devices where there is no Marshmallow ROM with a vulnerable kernel available you are out of luck until another exploit is found.
Follow https://forum.xda-developers.com/crossdevice-dev/sony/universal-dirtycow-based-ta-backup-t3514236
Hint: In post #21 is described how to restore the TA (read the last sentence! -> you have to flash a stock ROM after restore).
If it does not work the first time let the tarnished bovine do its stride several times more.
Or: Repeat the process until success.
If you are already on Nougat you must downgrade the system ROM (see above) to use the exploit and backup the TA-partition.
The latest exploit that is available for devices that came out with Oreo uses a different exploit.
Search for this exploit in the specific forum or on "Sony Cross Device". If you are already on Pie you have to download an Oreo ROM for your device.
This is similar to the procedure described above that has the Xperia XZ in mind.
TA-partiton backed up?
Now the non-reversible part:
Under http://developer.sonymobile.com/unlockbootloader/ you request an unlock code.
READ, READ what SONY have written there!
- You will lose some DRM functionality: https://forum.xda-developers.com/z3-compact/general/loss-drm-keys-t2890936
- Your device will factory reset. You have a backup?
You can get the IMEI-number from the original package of your phone (if you have good eye sight and nobody swapped the boxes) or pull a tab from the side of the phone (you do not want to do that) or print a screen shot of the relevant page of your service menu or head into settings->about device->status->IMEI-Info.
You follow SONY's instructions to unlock the bootloader and hold your breath as after a long reboot everything on your device is wiped. On the newer devices you get an ugly warning "the device can't be trusted anymore".
NEVER EVER enable the MyXperia software from now on!
On some devices this in combination with an unlocked bootloader will hard brick your device.
Here was a link to fxpblog where they destroyed two devices.
Hey, you have been warned. With the TA-backup you always can return to the chicken den.
Become a "developer"
- Tap seven times on the build number of your device. (settings->device info)
- then enable "OEM unlocking" (new for the 2016 and later devices like XZ) and "USB-debugging"
You have read the SONY advice?
Next decision: Root stock ROM or go Custom Rom?
I am VERY happy with LineageOS on a Tablet Z and other devices in my household. I liked the Resurrection Remix ROM on my SAMSUNG phone.
Your mileage may vary: Testing a ROM and reversing will cost you with a proper backup minimum 4-5 hours.
If you choose a custom ROM:
- read the thread to get a hunch if you really want to install it (get over the off topic noob questions and annoying full quotes)
- Follow the instructions of the first page of the ROM-thread to install it. If you can not do this: stop or be prepared for searching and learning.
From February 2017 until May 2017 I had eXistenZ N on my Xperia XZ and like the UI tuning modifications. This "ROM" does not come pre-rooted it is a patch for the stock ROM (match the versions exactly!) that enhances the settings/look.
On SONY devices I recommend rooting stock ROMs.
Shortcut: Pie users can proceed to step 7 here
Having a custom kernel might still be advantageous for you.
You need a custom (or modified stock) kernel (aka boot image) with DM-Verity and SONY-RIC OFF.
This kernel has to be in sync with your ROM. Flashing an unsuitable kernel (e.g. MM-kernel on N-Roms) will result in a boot loop aka "soft brick".
You even can bake one yourself (no easy task) if you find/adapt the sources for your device. -> first stop SONY developer world
This is might be easy! THANKS to the efforts of @AndroPlus, @janjan and others.
You have to look into the device specific fora to find a proper kernel for your ROM-version.
They have also included many patches to improve battery life, mitigate some (e.g. camera) issues from the loss of the device keys ...
Download the kernel and recovery for your device and ROM-version and follow the kernel makers' instructions.
On devices where there is no custom kernel, you can try patching the stock kernel to switch off RIC and DM-verity. In reality behind the scenes it is a bit more than just patching (=modifying) the kernel. You also get some updated init-scripts and as a end result a new boot.img
Very useful is [PoC][Work in progress] Trim Area Proof Of Concept developed by @munjeni
These scripts not only prepare a stock kernel for rooting but also put your TA backup from above to such a use that you regain the DRM-features lost by opening the bootloader! So you do not need a custom kernel with partial DRM-fixes!
For Oreo it is more complicated (it might be easier to search for a suitable boot.img aka kernel and I have not tested it on Pie but see next step):
@serajr enhanced a script specifically for Xperia X Performance, XZ and XZs
https://forum.xda-developers.com/showpost.php?p=74724162&postcount=2793
Under Linux I had to set the executable attributes on the shell scripts and binaries (chmod +x).
You get the required kernel.elf via the tools menu in Flashtool. Dump "kernel.sin".
I started applying the scripts to the Stock ROM in May 2017 since eXistenZ ROM lagged a bit behind in security patches and Android version:
- flashed stock ROM via Flashtool or Newflasher
- prepared a patched boot image with PoC and my kernel...sin and TA.img and answered all questions with "yes" (hit return each time)
Code:
./ta_poc kernel.sin TA.img ramdisk
I am on Debian as operating system.
On Windows you just run the provided batch files and follow the instructions here and in the thread for the scripts.
- flashed the resulting boot image with fastboot flash boot boot.img and test it works. Service menu/Security: keys provided YEAH
- flash recovery and from there root with SuperSU and flash Titanium Backup
- restored my apps with their data via Titanium Backup
==============
Some hints:
==============
Most of these commands emit useful info on the command line - read it, post their error messages if you are stuck.
Version numbers of the software used speeds diagnosis of problems. Often a good advice: "Use latest version."
adb reboot bootloader or switching OFF the device and then pressing the "volume up" button while plugging the USB cable gets you into fastboot mode. You see a black screen and the blue LED light.
I normally do not flash the kernel-ZIP-file via recovery but unpack it and flash this: fastboot flash boot boot.img
To get into recovery mode:
Switch OFF your device. Press the "power" button shortly to switch ON and hold "volume down" button more than 5 seconds (or when you see the yellow LED light on some devices).
Or: adb reboot recovery
If you can not get into recovery (e.g. AndroPlus has no kernel for your latest SONY ROM):
fastboot boot TWRP_latest_version.img
I use an SD card (content there survives factory resets) and there a directory "for_recovery" well stocked with the zip-files I intend to flash. In TWRP you can tell the file manager on what storage (internal, SD-card, USB ...) it will find the flashable ZIP-files. The default is "internal".
Pressing the Power button and "volume up" for about five seconds gives you a hard reset.
Good if you are totally struck - just flash a SONY ROM for your device with Flashtool and all the wipe boxes checked or use Newflasher (overwrites most partitions including your data).
If you like to read about the haarrrdddd way:
https://forum.xda-developers.com/z4-tablet/help/enybody-root-t3154926
The first rooting of a DM-Verity secured device in 2015. Thanks to SONY for releasing source code and binaries.
Rooting - aaahh, finally
Flash the latest Magisk (up to late 2017 I used SuperSU which still works) from recovery.
https://forum.xda-developers.com/apps/magisk/official-magisk-v7-universal-systemless-t3473445
https://www.chainfire.eu/ Find the latest SuperSU from there. You will not find it there any more since Chainfire has sold the rights to the utility. I endorse Magisk since that is open sourced on GitHub.
No: flashing a custom kernel and recovery does not root your device.
For Android Pie users: On my Xperia XZ1 I can skip step 6 completely!
Just install/upgrade to the latest Pie ROM and flash Magisk and install the Magisk app.
Bonus: Debloat the device
https://forum.xda-developers.com/search/forum/2522?query=debloat
Nowadays I use a debloat script written by @serajr for my devices https://forum.xda-developers.com/xperia-xz2/development/oreo-debloat-script-v1-0-t3798979,.
I edit (comment out) the debloat_list.sh in order to keep "com.google.android.apps.maps" and "com.sonymobile.email" which I both use.
mine (you screened my script?):
flash the attached ZIP-file
View attachment xtrm_debloat.flashable_ew_2016-12.zip
found in https://forum.xda-developers.com/xperia-z5/general/discussion-bloat-sony-xperia-z5-t3518860 probably original work by @ganeshbiyer
=============================================================
With opened bootloader you will not get OTA updates any more!
You have to check with the Xperifirm program if there are newer ROMs for your device.
I have not had any problems with installing e.g. a Swiss ROM over a Central Europe. There could be some worries when switching continents.
Download the desired ROM via Xperifirm and follow the instructions of Flashtool to flash the device (over USB update = OUU :laugh.
Accept the use of the FSC script.
Repeat the steps 5 to 6(7) for any other/newer SONY ROMs you flash followed by step 4 (if necessary).
If a wipe is needed I prefer the full wipe in TWRP compared to checking the boxes in Flashtool.
Or use Newflasher without flashing userdata.sin (just delete the file) in case of an upgrade.
=============================================================
CHANGES to this Guide
2019-04-23 updated for Pie, endorsed Newflasher, added link to serjars debloat script, link ckecks
2018-02-28 clarified getting kernel.elf for self patching, some typos, link ckecks
2018-01-31 link for better suited ta_poc added, toned down AndroPlus endorsement, added Magisk
2017-06-25 added link to xpericheck (find older ROMs), added hint for restoring TA for those TLDR-guys
2017-06-02 added procedure for patching stock kernel as alternative to custom kernels
2017-02-05 added recommendation for eXistenZ N ROM
2017-01-25 new URL for SuperSU, typos
2017-01-18 corrected the advice for booting into TWRP
2017-01-17 added info on fastboot driver for Windows users
DHGE said:
No - but you can find anything here or in the devices-fora later than Z3+ or SONY-cross-device.
https://forum.xda-developers.com/crossdevice-dev/sony
Good introductory (written for devices before Z3+):
https://forum.xda-developers.com/crossdevice-dev/sony/noob-guide-to-sony-ericsson-xperia-t3209012
It is still valid but the 2015 and newer devices are not rootable anymore (as described) thanks to DM-Verity.
For rooting the current device you have to open the bootloader.
Any claims to the contrary found "on the web" are only tricks to have you install "interesting" software on a Windows PC.
Do you want root?
No:
wait for the OTA-updates from SONY
don't like waiting or want to downgrade: get flashtool http://www.flashtool.net
it comes with Xperifirm (at least for my linux machines) that finds you the latest ROM
https://forum.xda-developers.com/cr...xperifirm-xperia-firmware-downloader-t2834142
Unfortunately it does not find many older ROMs anymore so you better keep your downloads (>2 GBytes each) or find an older ROM in case you need it (xda has a search function).
Yes:
As stated above, you need to unlock the bootloader to modify the system software on your device. Fortunately SONY gives (for non-carrier-locked) devices the option to unlock the bootloader.
Check if unlocking is allowed: in the service menu (dial *#*#7378423#*#* or *#*#SERVICE#*#* ) check under "Service Info"->"Configuration" the line "Bootloader unlock allowed:"
If you read anything other than "Yes" Stop here!
No: flashing another SONY Rom ("Customized CountryX") does not help you.
Hint: there is an app "SONY service menu" in the app-repository (F-Droid or Google).
OK - you can Now it is your last chance to save your device keys or "backup the trim area partition"
You should do this if you ever want to return to a SONY "blessed" state. e.g claiming service in countries where warranty is not for devices with unlocked bootloader or you want to sell it.
Otherwise do not bother with restoring the TA-partition. Doing so after the next steps will soft brick your device.
Go to SONY's developver world http://developer.sonymobile.com
Under drivers you find the drivers for the XZ under "Downloads" http://developer.sonymobile.com/downloads/drivers/xperia-xz/
These drivers are for Windows (which version?), do not bother if you are running a free operating system.
Install these drivers if you are a Windows user. Under Windows 8+ there could be problems with installing "non signed" drivers. Do a web/xda search to circumvent this security measure of Microsoft. http://www.flashtool.net/win8drivers.php
When you are installing: You also need to install the programs adb and fastboot.
https://forum.xda-developers.com/showthread.php?t=2317790
If you are running a free operating system: search for adb/fastboot or Android SDK in your repository and install these.
Running Linux it helps to insert the udev-rule mentioned in http://www.flashtool.net/lininstall.php otherwise you have to run esp. fastboot with root-privileges (not recommended, although the udev rule saves no punches ...)
You have to be root to save a partition - catch 22 :crying: ...
For Android Marshmallow ROMs, precisely up to version 39.0.A.3.30, exists an exploit of the copy on write function in the Linux kernel that gets you root privileges temporarily.
Follow https://forum.xda-developers.com/crossdevice-dev/sony/universal-dirtycow-based-ta-backup-t3514236
If you are already on Nougat you must downgrade the system ROM (see above) to use the exploit and backup the TA-partition.
TA-partiton backed up?
Now the non-reversible part:
Under http://developer.sonymobile.com/unlockbootloader/ you request an unlock code.
READ, READ what SONY have written there!
- You will lose some DRM functionality: https://forum.xda-developers.com/z3-compact/general/loss-drm-keys-t2890936
- Your device will factory reset. You have a backup?
You can get the IMEI-number from the original package of your phone (if you have good eye sight and nobody swapped the boxes) or pull a tab from the side of the phone (you do not want to do that) or print a screen shot of the relevant page of your service menu or head into settings->about device->status->IMEI-Info.
You follow SONY's instructions to unlock the bootloader and hold your breath as after a long reboot everything on your device is wiped. On the newer devices you get an ugly warning "the device can't be trusted anymore".
Hey, you have been warned. With the TA-backup you always can return to the chicken den.
Become a "developer"
- Tap seven times on the build number of your device. (settings->device info)
- then enable "OEM unlocking" (new for the 2016 devices like XZ) and "USB-debugging"
You have read the SONY advice?
Next decision: Root stock ROM or go Custom Rom?
Well - my opinion - for the newer SONY devices I have not found a recommendable custom ROM yet. I am VERY happy with a generic CyanogenMod on a tablet Z in my household. Do not ask me about the sad story of CyanogenMod as of late 2016...
Your mileage may vary: testing a ROM and reversing will cost you with a proper backup minimum 4-5 hours.
If you choose a custom ROM:
- read the thread to get a hunch if you really want to install it (get over the off topic newbie questions)
- Follow the instructions of the first page of the ROM-thread to install it. If you can not do this stop or be prepared for searching and learning.
On SONY devices I recommend rooting stock ROMs.
You need a custom kernel (aka boot image) with DM-Verity and SONY-RIC OFF.
This kernel has to be in sync with your ROM. Flashing an unsuitable kernel (e.g. MM-kernel on N-Roms) will result in a boot loop aka "soft brck".
You even can bake one yourself (no easy task) if you find/adapt the sources for your device. -> first stop SONY developer world
This is easy! THANKS to @AndroPlus
AndroPlus has also included many patches to improve battery life, mitigate some (e.g. camera) issues from the loss of the device keys ...
https://forum.xda-developers.com/xperia-xz/development/kernel-andropluskernel-v01-t3475240
AndroPlus has kernels for other devices too. Look into the specific device forum for a custom kernel,
Download the kernel and recovery for your device and ROM-version and follow AndroPlus' instructions.
Some hints: (most of these commands emit useful info on the command line - read it, post it if you are stuck)
adb reboot bootloader or switching OFF the device and then pressing the "volume up" button while plugging the USB cable (hooked to your PC! we need DC power for all this) gets you into fastboot mode. You see a black screen and the blue LED light.
I normally unpack the kernel-ZIP-file and flash this: fastboot flash boot boot.img
You get into recovery mode on booting by pressing the "volume up" button when you see the yellow LED light.
If you can not get into recovery (e.g. AndroPlus has no kernel for your latest SONY ROM):
fastboot boot TWRP_latest_version
I use an SD card (content there survives factory resets) and there a directory "for_recovery" well stocked with the zip-files I intend to flash.
Pressing the Power button and "volume up" for about five seconds gives you a hard reset.
If you like to read about the hard way:
https://forum.xda-developers.com/z4-tablet/help/enybody-root-t3154926
The first rooting of a DM-Verity secured device in 2015. Thanks to SONY for releasing source code and binaries.
Rooting - aaahh, finally
Flash the latest SuperSU from recovery.
https://download.chainfire.eu/1019/SuperSU
No: flashing AndroPlus or TWRP does not root your device. You'll have to flash Chainfire's ZIP-file!
Bonus: Debloat the device
https://forum.xda-developers.com/search/forum/2522?query=debloat
mine (you screened my script?):
flash the attached ZIP-file
View attachment 4000189
With opened bootloader you will not get OTA (over the air - prosaic?) updates any more!
You have to check with Xperifirm if there are newer ROMs for your device.
I have not had any problems with installing e.g. a Swiss ROM over a Central Europe. There could be some worries when switching continents.
Download the desired ROM via Xperifirm and follow the instructions of flashtool to flash the device. Accept the use of the FSC script.
Repeat the steps 5 to 6(7) for SONY ROMs followed by step 4 (if necessary).
If a wipe is needed I prefer the full wipe in TWRP compared to checking the boxes in FlashTool.
Click to expand...
Click to collapse
Woaw, thanks a lot for your awesome answer !
I receive my phone today, I'll follow your instructions
@DHGE your guide is well put, and I've not had any problems so far (I used a slightly different version of the Xperia ROM since the version you specified didn't show up, but it worked just fine, is sitting on Android 6.0, and I have the TA backed up).
I've obtained the unlock code from Sony's developer site, but I've still yet to get their email with the instructions on where to shove the code. Its been about two or three hours now, and it was sent to a Gmail address (which has received other mail since). I tried generating a new code to make sure the email was right (it was), and it spat out the same unlock code, so I'm guessing its just based off of the IMEI.
Question is: what does one do with the unlock code? I can't imagine the instructions would be different for each person and am not sure how long it may take Sony to email the Gmail account...
k2trf said:
What does one do with the unlock code?
Click to expand...
Click to collapse
Follow the steps on SONY's website where you obtained the unlock code.
Look at the big link at the right bottom after all the warnings...
Somehow I missed that completely, and just latched onto it saying to wait for the instructions via email. Honestly, I don't even know why they think it necessary. Anyone playing with unlock codes damn sure better be familiar with ADB and fastboot already, or be learning as they go. >_>
Hi,
there something I can do to roll back if I didn't backed up my TA partition?
thanks
bigkekko said:
Hi,
there something I can do to roll back if I didn't backed up my TA partition?
thanks
Click to expand...
Click to collapse
Roll back to recover TA? Unfortunately not.
Welcome everyone!
This project has started, becouse we need real solution for the problem. The problem of hard bricked Moto devices. It is like a curse.
When my device bricked I have done solid research, I have gathered many informations and files essential to revive my cellphone but 5 years experience of linux, rooting, compiling kernels and roms weren't enough to make it work.
But nevermind. I am even more determinated and I am asking ALL of You guys here to help me. Together we will come to solution.
Here is what I got, happy reading :
DICTIONARY:
PBL - Primary bootloader of the chip - this is like BIOS for phone so it checks chip for damage and problems and then it tries to load SBL but if SBL is corrupted or checksum doesn't match, PBL invokes Qualcomm HS-USB QDLoader 9008 emergency mode. PBL is hard flashed into SoC and can't be corrupted by firmware.
SBL - Second stage bootloader wich is more advanced than PBL. It initializes phone hardware and ABOOT.
ABOOT - Application bootloader (HBOOT). You probably know this one well. Android botloader.
Full mmcblk0 backup - Backup of whole phone flash storage byto to byte.
blankflash - method of repairing msm phones in 9008 state
programmer.mbn - Special type of software programmer that is being sent to chip in Qualcomm 9008 emergency mode. There it comunicates with pc via firehose protocol. Each phone has set of their own programmers, they are unique to phone and other programmers don't work. These programmers are signed so tampering it results in not working one.
firehose protocol - it is used to tell programmer what operations it must do on chip.
singleimage.bin - this package contains instructions for programmer and set of files it need (for example to replace)
gpt_main0.bin - Partition layout
rawprogram0.xml - instructions for programmer
patch0.xml - I don't know yet
STAR.exe - Application for managing and editing contents of singleimage.bin aka blankflash files
QPST - Flash tool from Qualcomm it basic function is to handle blank-flashing in a better way, also it allows for in-depth debugging of the process
Qualcom Premium Tool - Program made by Mppg Myanmar that is capable of making unlocking bootloader, OEM locks, making backup/restore of chip firmware, handling blank-flashing in VERY specific way (creating instructions for programmer), reading eMMC structure from firmware (can generate gpt layout so very useful!!!), modyfing FW and removing Xiaomi account. It also contains ALL programmers
for more:
https://forum.xda-developers.com/android/general/info-android-device-partitions-basic-t3586565
https://alephsecurity.com/
https://github.com/alephsecurity/firehorse
https://github.com/aravindvnair99/Motorola-Moto-E-XT1022-condor-unbrick
INFO:
1. What causes the brick
I bet 100$ that you hard-bricked your Moto Z Play by installing OTA updates after downgrading firmware. This is only known reason for me at the time of writing this. There is most probable reason why it happens, look:
There are two most common chips on which smartphones are built - Qualcomm and Mediatek. While Mediatek chips are "modification friendly" and simple, Qualcomm chips are somewhat more advanced and have many features that can be enabled or disabled during prorammming in factory. One of them is PBL signature checking. During programming of your phone, proper signatures of SBL are written to it. When someone tries to override default SBL with the new one, it checksums are compared with that stored. If they match, new one is flashed, if not, then update does not happen.
Ok, but what it has to do with brick?!
I explain:
1. You decide to downgrade your firmware
2. During flashing, everything goes "well" (Phone boots), but trully update is partial:
FW in chip is (obviously) more recent that the one you downgrade to, and SBL signature is different (updated), so when it is compared to the signature of SBL from FW you want to flash, it don't match. That don't rise error and flashing continues. Only partition that stays untouched is bootloader, but all other partitions get replaced by those in FW zip. SBL is still compatible with the new partition offsets and partition layout overall so phone functions normally.
3 When OTA is executed, it checks the version of currently installed firware. The most reliabe way to do it is to check checksum of SBL which is pretty logical becouse it's checksum is like "fingerprint" of firmware. Normally, if it would detect the old firmware, OTA would be stopped, but newer SBL tricks it and OTA installs anyway.
4 Results are horrible, becouse OTA does not check GPT table and flashes partitions in bad sectors, corrupting FW.
This causes bootloader to go into Qualcomm HS-USB QDLoader 9008 safe mode.
5 Viola! Hard brick!
2. How to fix it?
That is jolly good question! What we have to do is to reflash full chip firmware. Suprisingly I see some solutions, but those need to be developed:
A) SD-BOOT
It turns out that our fancy chip can probably boot from SD-CARD! The procedure works like this:
- When chip starts, one of the very first things it does is loading the memory, so it can actually work. The trick, is that chip loads it from specific disk, marked with exact name (I don't remember which, but I will do research). Speccially repared SD-CARD can appear with that name, so chip boots from it, not from internal memory. (This trick is proved to work on this model)
How to do it?
- Get full dd of working phone - it must be phone with the SAME chip and very likely the same model
- flash it to SD-CARD of 32GB or more, class 10 speed or higher, directly to card, not partition
- put card in phone, turn it on and wait
- you should see HBOOT
- select fastboot and flash new FW via it
- viola!
!!!THIS IS COMPLICATED PROCEDURE, I WILL MAKE DETAILED THREAD SOON, BUT FOLLOW IT ONLY IF YOU KNOW WHAT ARE YOU DOING!!!
B) FIREHOSE/SAHARA ATTACK
This could be achieved by sending payload via Firehose programmer that would allow to break verification of SBL or somehow allow SBL to be flashed. Now, PBL blocks attempts to update SBL. I have thesis that it is becouse PBL do not allows for SBL downgrade, so it's version must be higher, but we try to flash same version of SBL so it doesn't work. That thesis needs confirmation.
C) CRAFT BLANKFLASH
This would be last resort. It will work for sure, but this method needs knowledge and I don't know if it is doable.
STEP 1: Get white-listed blankflash checksums from OTA (we would need to reverse engineer those)
STEP 2: Break hash
STEP 3: Craft blankflash with needed hash
STEP 4: Flash
NEVER USE BLANKFLASH (ATTENTION!)
DO NOT try any blankflash files. They can make situation a lot worse and even physically (!) dmage your phone.
D) JTAG
Medusa Box etc.
E) Qualcomm Premium Tool
This can even work, but it is untested and there is a slight chance that can worsen state of phone (needs confirming).
The tool is very advanced and I need to gather info about usage, so very probable to be a good solution if we will learn how to use it!
E) METHOD 7
Interesting method from this guy: (7th option, I have contacted him if it is compatibile)
https://github.com/aravindvnair99/Motorola-Moto-E-XT1022-condor-unbrick/blob/master/Unbrick%20methods.md
3. DOWNLOAD
(Links will be aded *soon*)
XDA:DevDB Information
Unbrick Developement for Moto Z Play (addison) Full-Brick, Tool/Utility for the Moto Z Play
Contributors
Bobernator, Artim_96, Camarda
Version Information
Status: Testing
Created 2019-05-03
Last Updated 2019-05-03
Hi, same problem. Did you solve it?
Sony-MTK Devices
Hi and welcome to the Sony-MTK Devices development thread.
This is a meeting place for Sony-MTK dev's to meet and exchange information and idea's while developing for various Sony devices that use the MediaTek SoC.
Since MediaTek devices in general are very much alike there is a lot information regarding flashing, source code, leaks, official source code, etc, etc widely available.
The problem comes when we have to deal with Sony's implementation of their own specifics.
Things begin to diverge quite quickly and things can soon become very confusing.
Hopefully in this thread we can begin to bring order to the chaos and confusion for new and experienced dev's alike.
I will reserve a few threads below for the following.
Flashing Rooting Tool's etc.
MediaTek SoC brief but just for those new to mtk.
Sony specifics.
Sony MediaTek based devices.
Flashing Rooting Tool's etc.
Ok so where do I start
Tools:
Most of these tools following are specific to Sony but not all.
Most are for Linux and or Windows. I work with Linux only nowadays so others may need to help out with the Windows specifics.
If I refer to something you don't understand like .sin for example check the Sony specifics in Posts below.
GUI stands for General User Interface you know point click drag drop enter sort of stuff.
cmd stands for a command line tool run in a terminal or cmd prompt.
Androxyde FlashTool (Sony Specific, GUI, Linux (Needs Mono installed) Windows)
Androxyde FlashTool is a Sony Specific tool to download and flash Sony firmware packages and more. It use Sony's S1 Protocols when flashing Most of the MediaTek devices that Sony produce but the newer L3 L4 models may use the new protocol. Thread here https://forum.xda-developers.com/showthread.php?t=920746 website is here http://www.flashtool.net/index.php Note: the Warning to C4/C5 users in the Downloads section M5 users should also be included. To use that version you need a custom FSC if one exists if not then there is a older version which is safe to use but it does have some limitation but more on this later)
XperiFirm (Sony specific, GUI, Linux (Needs Mono installed) Windows)
XperiFirm is a Standalone version of the same tool built into Androxyde FlashTool. this tools allows you to get the official Sony firmware for your device. It taps into the Sony repository I assume Sony's official Xperia Companion Tool uses. It will download the firmware and unpack it for you.
Main Thread is HERE
UnSIN (Sony specific, GUI, Linux (Needs Mono installed) Windows)
UnSIN is a standalone version of the same tool built into Androxyde FlashTool/XperiFirm it extracts the .elf and ext4 image files from the Sony firmware .sin's
Main Thread HERE
NOTE: munjeni's "Unpack any Sony firmware" see below does the same thing.
MTK-SU (MediaTek Specific, cmd, device binary Linux & Windows)
Thanks to dev @diplomatic All Sony Mediatek devices should now be able to obtain a /ta partition backup before unlocking their bootloader. (Yes I know see Sony specifics below for /ta explanations.)
It works by getting temporary "root" with a easy to use method which will then allow you to grab a /ta backup via the dd cmd
I did some testing for diplomatic and I can confirm this works for Sony MediaTek devices XA, XA1 C4, C5, M5, L1, L2 and L3 and all their variants. diplomatic's Thread is HERE for instructions and details also remember to Hit his Thanks Button or the Thumbs Up Button if your using a phone app.
AIK (Android universal, cmd, device binary also Linux & Windows)
This tool should be familiar to almost all dev's but where it stands out from the crowd is it's support for Sony's .elf format boot and recovery. (Yes I know see Sony specifics below for .elf explanations.) This tool takes the .elf unpacks it and repacks it in the more familiar AOSP .img format (It's not just a renaming exercise) which make life so much easier so big thanks to osm0sis for this.
AIK (meaning Android Image Kitchen by @osm0sis this tool will unpack the .elf's and repack them as AOSP .img's by default :good: I Main Thread HERE
munjeni's Sony Tools collection (Sony specific, cmd, device binary also Linux & Windows)
Sony dev @munjeni has produced a host of standalone open sourced dev tools. :good:
Unpack any Sony firmware does what it says really. It will extract the .img from the .sin's in the firmware packages. (Yes I know see Sony specifics below for .sin explanations.) Main Thread Here
Xflasher This tool is a standalone cmdline tool and can flash devices using the S1 protocol in download mode. I tested this on the L1 with noloader XA and XA1 with loader and it worked fine flashing boot.sin system userdata etc etc but flashing the boot area (preloader lk etc) is not fully tested as yet. The C4 failed as did the M5 so I suspect these older devices are not supported. Main Thread HERE
Sony Backup Tool/Script by bigrammy (Sony specific, cmd, Linux & Windows)
This is a little helper script to backup Sony Mediatek devices and is used in conjunction with MTK-SU prior to unlocking your boot loader.
It will backup your /ta /nvram and some other partitions. It also creates a dd-backup.txt which lists all the partitions on your device in dd backup format.
Sony Backup Script
Other cool things too so be sure to keep checking his threads :good:
MediaTek SoC brief but just for those new to mtk.
WIP Work In Progress
Sony specifics.
WIP
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