[FLASHLIGHT] Low flashlight brightness fix (torch light, not photo flash) - Sony Xperia XZ1 Compact Themes, Apps, and Mods

Hello.
Stock libraries on XZ1 Compact are using 25mA current for the flashlight, which leads to very dim light.
I fixed this to get 400mA current, and now flashlight is very bright, much better than on 25mA (stock) current.
WARNING: You may damage (or even fry) your flashlight LED with these libraries, but i'm think 400mA is fine, because there is 25..400mA limits in the code, and after 2 minutes of light at 400mA my phone's LED was just a bit warm (but not hot).
WARNING: You must disable dm-verity for /vendor/ partition before flashing any .zip attached below, or you will get bootloop.
NOTES:
1. The easiest way to disable dm-verity is to use Magisk to get root (it will automatically disable dm-verity of both /system/ and /vendor/ partitions when installed with default settings). The patched libraries does not require root access, Magisk is mentioned here only for disabling dm-verity.
2. To install Magisk you must unlock bootloader and flash TWRP. Please read [RECOVERY] TWRP 3.2.3-0 (lilac) [UPDATE: 2018-11-28] to learn more about TWRP installation for XZ1 Compact (or find appropriate TWRP for your device).
3. Please read [XZ1c/XZ1/XZp] temp root exploit to backup drm keys implemented to learn more about the way to backup your TA with DRM keys before unlocking your device's bootloader (this is important, because DRM keys will be lost on bootloader unlock, and you will have no way to get them back if you don't have TA backup with those DRM keys).
If you need other current value (in 25..400mA range) - feel free to contact me.
If you need patch for another ROM version or device - please contact me with attached /vendor/lib/libcameralight.so and /vendor/lib64/libcameralight.so from your ROM (and please tell me your device's model and version of your ROM).
You may try to do patch by yourself, tech details about patching is in Post #17 - feel free to upload patched .so files or flashable .zip for your device (please don't forget to write device model and ROM version in the description).
Files without model in name is for XZ1 Compact, other files (with model at the end of file name) is for corresponding phone models.
Files for 47.2.A.0.306 are also compatible with 47.2.A.2.33, 47.2.A.4.41 and 47.2.A.4.45 ROM versions, and may be compatible with future ROM releases (or may not - I don't know exactly, so please check compatibility before flashing).
Please check Post #25 for details about compatibility between fixes and ROM versions, and how to check compatibility if your ROM isn't listed.
You can use Magisk module from Post #32 instead of flashing the ZIP files directly to the /vendor/ (just replace existing .so files in Magisk module ZIP with desired versions (using any ZIP archiver) and install the module).
4PDA.ru post (in Russian)

@S-trace
please can modify for me the one for xz3 and for xzp. thank u

I assume root is needed?

karrouma said:
@S-trace
please can modify for me the one for xz3 and for xzp. thank u
Click to expand...
Click to collapse
Please upload necessary files here and tell me device models and firmware versions of each device you need, and which current should i set.
mEREHAIGE said:
I assume root is needed?
Click to expand...
Click to collapse
Yes, you must get root using Magisk (or disable verity on /vendor/ in any other way) before installing this mod, or you may get bootloop.
Root access itself is not necessary for mod to work, just disabled verity is needed (but installing Magisk is the easiest way to get this for me)

@S-trace
can you make a 350ma for pie version of xz1c
it is same as xzp

Can you make some medium for xz1c? Like 250 ?

karrouma said:
@S-tracecan you make a 350ma for pie version of xz1c
it is same as xzp
Click to expand...
Click to collapse
Done.
manuerduarte said:
Can you make some medium for xz1c? Like 250 ?
Click to expand...
Click to collapse
Done.

Thanks!

S-trace said:
Done.
Done.
Click to expand...
Click to collapse
Thank you my friend.
Teting the 350 and 400
400 is better in all condition for cam
And 400 has no heat so it is fine for daily use.
Thank you for your work

Here for xz3
Attached
Can you modified to 400ma
Thank you

Hi,
This is a welcome patch. It used to be (on Z3C) to just change flashled_calc_parameters file - do you think it's still possible on XZ1C? Can you share more details on how exactly you patch the .so files?

gshegosh81 said:
Hi,
This is a welcome patch. It used to be (on Z3C) to just change flashled_calc_parameters file - do you think it's still possible on XZ1C? Can you share more details on how exactly you patch the .so files?
Click to expand...
Click to collapse
Is there anyway, we can control the current that goes to the flash on the go?

S-trace said:
Done.
Done.
Click to expand...
Click to collapse
@S-trace
Can i take a little bit from your time
Can you make an 450ma and 500 for me.
Thank you

rsk_kelkar said:
Is there anyway, we can control the current that goes to the flash on the go?
Click to expand...
Click to collapse
You can use following script for testing different current values:
Code:
#!/system/bin/sh
toggle=$(cat /sys/class/leds/led:switch_0/brightness)
if [ "$toggle" = "0" ];then
echo 60 > /sys/class/leds/led:torch_0/brightness
echo 60 > /sys/class/leds/led:torch_1/brightness
echo 1 > /sys/class/leds/led:switch_0/brightness
echo "on"
else
echo 0 > /sys/class/leds/led:torch_0/brightness
echo 0 > /sys/class/leds/led:torch_1/brightness
echo 0 > /sys/class/leds/led:switch_0/brightness
echo "off"
fi
60 means 120mA here, stock value is 13 (25mA).
I don't know any way to control flashlight current dynamically from the Android OS (like display brightness can be controlled).
karrouma said:
@S-trace
Can i take a little bit from your time
Can you make an 450ma and 500 for me.
Thank you
Click to expand...
Click to collapse
No, it won't work (I tried) - kernel will limit current to 400mA. Maybe it will be possible if you will patch kernel/dt to overcome this limit, but I'm not sure.

S-trace said:
You can use following script for testing different current values:
Code:
#!/system/bin/sh
toggle=$(cat /sys/class/leds/led:switch_0/brightness)
if [ "$toggle" = "0" ];then
echo 60 > /sys/class/leds/led:torch_0/brightness
echo 60 > /sys/class/leds/led:torch_1/brightness
echo 1 > /sys/class/leds/led:switch_0/brightness
echo "on"
else
echo 0 > /sys/class/leds/led:torch_0/brightness
echo 0 > /sys/class/leds/led:torch_1/brightness
echo 0 > /sys/class/leds/led:switch_0/brightness
echo "off"
fi
60 means 120mA here, stock value is 13 (25mA).
I don't know any way to control flashlight current dynamically from the Android OS (like display brightness can be controlled).
No, it won't work (I tried) - kernel will limit current to 400mA. Maybe it will be possible if you will patch kernel/dt to overcome this limit, but I'm not sure.
Click to expand...
Click to collapse
Thank you

Can you use this on lineageos?

karrouma said:
Here for xz3
Attached
Can you modified to 400ma
Thank you
Click to expand...
Click to collapse
Modified
Can you tell exact ROM version (from which you have taken libraries) to let me upload these patched libraries and original libraries to the OP?
4684361 said:
Can you use this on lineageos?
Click to expand...
Click to collapse
This depends on LineageOS you have.
gshegosh81 said:
Hi,
This is a welcome patch. It used to be (on Z3C) to just change flashled_calc_parameters file - do you think it's still possible on XZ1C? Can you share more details on how exactly you patch the .so files?
Click to expand...
Click to collapse
I'm think /vendor/etc/flashled_calc_parameters.cfg holds only camera flash parameters, not torch parameters.
But you may try to edit this file if you want.
Details about patching (offsets is for XZ1c):
Code:
32bit 8.0: (Thumb-2)
0x3F52 ALL 23=>22
0x3F9A 300 00E0FFE746F2A810=>49F2E030C0F20400
0x3F9A 400 00E0FFE746F2A810=>41F68020C0F20600
64bit 8.0: (ARM64)
0x4BBC ALL 0003=>E002
0x4C18 300 020000140100001400358CD2=>007C92D28000A0F21F2003D5
0x4C18 400 020000140100001400358CD2=>005083D2C000A0F21F2003D5
32bit 9.0: (Thumb-2)
0x4D52 ALL 3C=>3B
0x4DCC 250 00E0FFE746F2A810=>4DF29000C0F20300
0x4DCC 350 00E0FFE746F2A810=>45F23070C0F20500
0x4DCC 400 00E0FFE746F2A810=>41F68020C0F20600
64bit 9.0: (ARM64)
0x5CAC ALL E0=>C0
0x5D64 250 020000140100001400358CD2=>00129AD26000A0F21F2003D5
0x5D64 350 020000140100001400358CD2=>00E68AD2A000A0F21F2003D5
0x5D64 400 020000140100001400358CD2=>005083D2C000A0F21F2003D5
Payloads:
32bit:
MOVW R0, #0x1A80
MOVT R0, #6
64bit:
MOVZ X0, #0x1A80
MOVK X0, #0x6, LSL #16
NOP
The first one-byte patch is just a fixup for BEQ offset (to make it jump to correct offset, because we need 4 extra bytes to insert one more instruction, so we'll replace two useless B opcodes with MOV* instructions).
The second multi-byte patch is a payload, in this example MOV* instructions store 0x61A80 (400000) in R0/X0.
You may use http://armconverter.com/ to assemble payload with desired current value and then use HEX editor to patch your libraries (32bit is more important, i don't know who and when will use 64bit library, but patch it too just to leave OS libraries consistent).

S-trace said:
Modified
Can you tell exact ROM version (from which you have taken libraries) to let me upload these patched libraries and original libraries to the OP?
This depends on LineageOS you have.
I'm think /vendor/etc/flashled_calc_parameters.cfg holds only camera flash parameters, not torch parameters.
But you may try to edit this file if you want.
Details about patching (offsets is for XZ1c):
Code:
32bit 8.0: (Thumb-2)
0x3F52 ALL 23=>22
0x3F9A 300 00E0FFE746F2A810=>49F2E030C0F20400
0x3F9A 400 00E0FFE746F2A810=>41F68020C0F20600
64bit 8.0: (ARM64)
0x4BBC ALL 0003=>E002
0x4C18 300 020000140100001400358CD2=>007C92D28000A0F21F2003D5
0x4C18 400 020000140100001400358CD2=>005083D2C000A0F21F2003D5
32bit 9.0: (Thumb-2)
0x4D52 ALL 3C=>3B
0x4DCC 250 00E0FFE746F2A810=>4DF29000C0F20300
0x4DCC 350 00E0FFE746F2A810=>45F23070C0F20500
0x4DCC 400 00E0FFE746F2A810=>41F68020C0F20600
64bit 9.0: (ARM64)
0x5CAC ALL E0=>C0
0x5D64 250 020000140100001400358CD2=>00129AD26000A0F21F2003D5
0x5D64 350 020000140100001400358CD2=>00E68AD2A000A0F21F2003D5
0x5D64 400 020000140100001400358CD2=>005083D2C000A0F21F2003D5
Payloads:
32bit:
MOVW R0, #0x1A80
MOVT R0, #6
64bit:
MOVZ X0, #0x1A80
MOVK X0, #0x6, LSL #16
NOP
The first one-byte patch is just a fixup for BEQ offset (to make it jump to correct offset, because we need 4 extra bytes to insert one more instruction, so we'll replace two useless B opcodes with MOV* instructions).
The second multi-byte patch is a payload, in this example MOV* instructions store 0x61A80 (400000) in R0/X0.
You may use http://armconverter.com/ to assemble payload with desired current value and then use HEX editor to patch your libraries (32bit is more important, i don't know who and when will use 64bit library, but patch it too just to leave OS libraries consistent).
Click to expand...
Click to collapse
52.0.A.3.84 xz3

karrouma said:
52.0.A.3.84 xz3
Click to expand...
Click to collapse
Thank you.
Uploaded files to the OP.

S-trace said:
Thank you.
Uploaded files to the OP.
Click to expand...
Click to collapse
Thank you

Related

[Dev] Kboot release (Stable), boot multiple kernel/os

Hi,
Here a release of kboot.
Kboot permit to boot multiple os with different kernel.
It's based on a buildroot environment.
The source to make your own kboot filesystem are available here
The kernel source are available here
You can download the install archive :
ARCHIVE VERSIONS
0.0. Unstable release. Freeze bug. Install release ARCHIVE (Obsolete)
0.1. Fix freeze. Python bytecode generation (pyc files) is naturally not friend with squashfs. Install release ARCHIVE (Obsolete)
0.2. STABLE Release. Display timeout, migration from squashfs to initramfs. Install release ARCHIVE
The archive looks like :
zImage and initramfs.cpio.gz to flash in SDE menu
a directory kboot which contain:
conf directory : configuration file
os directory : os to boot
images directory : background menu image
Installation
Kboot directory
Copy the kboot directory on your archos in /mnt/storage/, you should have this path /mnt/storage/kboot. The path should be exactly the same otherwise kboot will not be launched
Flash zImage and initramfs.cpio.gz
Follow this link to setup SDE on your archos http://forum.xda-developers.com/showthread.php?t=930197
After Reboot
You should have the following screen. Note: after installing Kboot the device permanently reboot in Kboot.
The main menu will display the os put in os directory (see in Configuration OS boot menu to see how to include your os), advanced menu and halt.
Boot menu
OS boot menu
I have tried to make things simple. To add an OS, all you need is to create a directory in /mnt/storage/kboot/os/ and put in this newly created directory the files zImage and initramfs.cpio.gz.
Important, the name should be exactly zImage and initramfs.cpio.gz, if one file is missing or misnamed the menu item don't appear
For example, the menu above have the following content in /mnt/storage/kboot/os :
Code:
/mnt/storage/kboot/os/Android Froyo:
drwxrwxrwx 2 2000 2000 4096 Feb 27 23:42 .
drwxrwxrwx 5 2000 2000 4096 Feb 28 15:02 ..
-rw-rw-rw- 1 2000 2000 726520 Feb 27 23:39 initramfs.cpio.gz
-rw-rw-rw- 1 2000 2000 2564460 Feb 27 23:39 zImage
/mnt/storage/kboot/os/Android Honeycomb:
drwxrwxrwx 2 2000 2000 4096 Feb 27 16:46 .
drwxrwxrwx 5 2000 2000 4096 Feb 28 15:02 ..
-rw-rw-rw- 1 2000 2000 0 Feb 27 13:42 initramfs.cpio.gz
-rw-rw-rw- 1 2000 2000 0 Feb 27 13:42 zImage
/mnt/storage/kboot/os/UrukDroid 1.6:
drwxrwxrwx 2 2000 2000 4096 Feb 28 15:03 .
drwxrwxrwx 5 2000 2000 4096 Feb 28 15:02 ..
-rw-rw-rw- 1 2000 2000 2874800 Jan 3 19:41 initramfs.cpio.gz
-rw-rw-rw- 1 2000 2000 2302252 Jan 3 19:26 zImage
Note : for specific kernel you can add a file named cmdline containing kernel parameters
Advanced boot menu
Boot init : boot into android, if android kernel was uninstalled, this item didn't appear
Boot recovery : boot into recovery
Soft boot : For details about omap soft reboot see the discussion here
Configuration
There is a configuration file in kboot/conf directory named config.ini. This file is divided into 3 section
init
telnet : 1 to enable telnet, 0 to disable
usbip : set the ip address of usb ethernet interface
Code:
[init]
telnet = 1
usbip = 192.168.10.1
kboot
last_selection : enable (1) or disable (0) the boot by default of the last selectioned entry after a configured timeout
last_selection_timeout : timeout in second
softboot : enable or disable softboot menu
title_font_size : set the title font size
menu_font_size : set the menu font size
title_color : title color in r,g,b format
menu_item_color : menu unselected color in r,g,b format
menu_item_selected_color : menu selected color in r,g,b format
Code:
[kboot]
# boot last selection if no key pressed after 30 seconds
last_selection = 1
last_selection_timeout = 30
# enable soft boot menu (bootloader dev only)
softboot = 1
# some tuning
title_font_size = 36
menu_font_size = 32
# change the color, R,G,B format
title_color = 255,255,255
menu_item_color = 92,97,98
menu_item_selected_color = 0,0,255
softboot
item<n> : the boot sequence wanted
Code:
[softboot]
# put a list of items to display in Soft boot menu
# item<n> = sequence
item1 = uart,usb,mmc1,mmc2
item2 = uart,usb
item3 = mmc1,mmc2
background image
To customize the background image, just replace the file kboot/images/bkg.png with your own and adapt if necessary the size and the font color.
BUGS
Feedbacks are welcome
Cool stuff bro!
Unfortunately it's not working on the A70S, as we only have 800x480 and therefor need a diff picture.
It seems to be good.I have tested it on my A101 and it can boot both openaos and urukdroid.
Thanks.
EDIT:Sorry, Urukdroid cannot boot.It stay at the boot animationan and always show that.
fzelle said:
Unfortunately it's not working on the A70S, as we only have 800x480 and therefor need a diff picture.
Click to expand...
Click to collapse
As an early release I didn't take the time to put the different resolution. The background image have a 1500x1200 resolution, so on 101 it didn't display right too. However kboot adapt resolution for corresponding board. kboot didn't boot on 70s or display wrong the background image ?
MarsCarmen said:
EDIT:Sorry, Urukdroid cannot boot.It stay at the boot animationan and always show that.
Click to expand...
Click to collapse
I have to test urukdroid on mine.
The menu is not readable because the resolution adaption is not doing what it should do.
fzelle said:
The menu is not readable because the resolution adaption is not doing what it should do.
Click to expand...
Click to collapse
I have uploaded a new archive here.
Replace rootfs.squashfs with the new one. Fixed : resolution was wrong for 70S and 70H*.
The zImage in new archive should be flashed, it seems to fix the random freeze.
MarsCarmen said:
EDIT:Sorry, Urukdroid cannot boot.It stay at the boot animationan and always show that.
Click to expand...
Click to collapse
I have to say sorry again that Kboot can boot Urukdroid properly.It was because I copied my backup file to my archos by using MY PC.That is why I cannot boot urukdroid.Maybe I didn't find the real cause. I'm now using Kboot to boot Urukdroid and Openaos.
Really very well!!
Sorry For My Bad English
@alephzain:
Copied the whole kboot dir and flashed the new initrams and zimage.
Looks still as before.
fzelle said:
@alephzain:
Copied the whole kboot dir and flashed the new initrams and zimage.
Looks still as before.
Click to expand...
Click to collapse
. Kernel natively support usb gadget ethernet, when kboot is launched a telnetd is started, an interface usb0 is configured with ip address 192.168.10.1.
if you are on linux it should automatically detect this and on your pc an ifconfig let appear usb0 interface. On your pc type :
Code:
ifconfig usb0 192.168.10.2 netmask 255.255.255.0 up
telnet -l root 192.168.10.1
.
If you can paste a ps output, to see if it detect you board correctly.
Found a Live Linux to use in a vm.
ps output starts with :
{init} /bin/sh /init A70S 07 /dev/mmcblk1p1 /dev/mmcblk0p1
fzelle said:
Found a Live Linux to use in a vm.
ps output starts with :
{init} /bin/sh /init A70S 07 /dev/mmcblk1p1 /dev/mmcblk0p1
Click to expand...
Click to collapse
Its fixed now . Replace rootfs by this one
alephzain said:
Its fixed now . Replace rootfs by this one
Click to expand...
Click to collapse
Please adapt the first post also so that future users have the correct files.
Maybe add a version number....
---------- Post added at 04:27 PM ---------- Previous post was at 04:12 PM ----------
This may be a stupid question but why do you need a squashed fs that contains (when unsquashed) about 30Mb on files including python?
it should be possible to trim that down and put all the scripts and support libs in the initramfs so that you only need to flash the kernel and initramfs and nothing else.
Working now.
If now someone could come with the possibility for booting older stock FW,
would be great.
fzelle said:
Working now.
If now someone could come with the possibility for booting older stock FW,
would be great.
Click to expand...
Click to collapse
Not really possible because the stock firmware (initramfs) always uses the same location for the root file system.
You could do it but it needs some changes to the initramfs that is placed in the dirs.
wdl1908 said:
This may be a stupid question but why do you need a squashed fs that contains (when unsquashed) about 30Mb on files including python?
it should be possible to trim that down and put all the scripts and support libs in the initramfs so that you only need to flash the kernel and initramfs and nothing else.
Click to expand...
Click to collapse
Files on first post have been updated, but you're right a better presentation to avoid confusion is necessary.
Simply because I use python (pygame which use sdl) to code Kboot. Python lib dir is about 13M ... . A minimal filesystem (compressed initramfs) for kboot work is about 8M + ~2M for the kernel give 10M, and it's too big to flash in SDE max 8M. But if i can optimize the size ... I will do
alephzain thanks for the sources on gitorious, I hope I have some time in the weekend to try it out
divx118
@divx118:
And could you then make a initramfs.cpio.gz that direktly boots into CM7?
Hi,
im just about testing...
But sadly I can't get it to work.
Each time the menu starts up i can navigate nicely though the menues.
But whenever I select an entry - noting happens
After that I can still navigate ONCE (up or down) to the next entry and then the device freezes.
It doesn't matter wich entry i select as it seems. I tested Boot init, and my custom entries (UrukDroid and BullRC) yet. But all behave the same.
Any ideas ?
Btw: I tested it with the acutal squashfs and the one packed in the zip (even they seemed to be the same in size)
EDIT:
SOLUTION: I had usb cable attached (since flash) and that made it freeze - juts removed the cable and all is fine
Thanks and gr8 work - was looking for this since ages
fzelle said:
@divx118:
And could you then make a initramfs.cpio.gz that direktly boots into CM7?
Click to expand...
Click to collapse
Yes, no problem.

LZMA compression tool

Hey , this is a small tool -you can call it patch - to compress kernel / recovery ramdisk .
Why this tool ?
Simply some devices have little space for kernel / recovery like samsung galaxy star which has about 10MBs for kernel/recovery .
How to use :
You must first activate LZMA support for ramdisks in kernel Go to your kernel config file then change this
Code:
# CONFIG_RD_LZMA is not set
TO
Code:
CONFIG_RD_LZMA=y
Clone the tool under device/vendor_name/device_name.
Add those line to your BoardConfig.mk file .
Code:
# LZMA compression for recovery's & kernel ramdisk....
BOARD_CUSTOM_BOOTIMG_MK := device/vendor_name/device_name/custombootimg.mk
BOARD_CANT_BUILD_RECOVERY_FROM_BOOT_PATCH := true
Enjoy .
Note :
This tools is used while you building any ROM/Kernel/Recovery from source .
This tool should work with any device .
LZMA compression takes more time to decompress than GZIP but When I tested it didn't take more than 1 or 2 more seconds to decompress .
You won't be able to decompress boot.img or recovery.img using boot-repacker or unpack tool for linux as you will get an error because those tools won't be able to decompress ramdisks for recovery or kernel -boot-repacker only gives you kernel zImage- and If you want to edit anything in ramdisk you will need to build it again from source !!!
This tool derived from
http://review.cyanogenmod.org/#/c/96227/
http://review.cyanogenmod.org/#/c/118533/​
Results using this tool :
Before :
Kernel ramdisk : 1.1 MB (1,117,760 bytes) .
recovery ramdisk : 4.2 MB (4,158,392 bytes) .
Total kernel.img : 9.1 MB (9,111,552 bytes) .
Total recovery.img : 12.2 MB (12,152,832 bytes) .
After :
Kernel ramdisk : 579.3 kB (579,257 bytes) .
recovery ramdisk : 2.7 MB (2,736,844 bytes) .
Total kernel.img : 8.6 MB (8,572,928 bytes) .
Total recovery.img : 10.7 MB (10,731,520 bytes) .
Something to discuss :
Maybe you find that these compress is not enough to save up the space or you maybe find this is very suitable for you , In my case it was useful in some aspects and not in others .
I tried to use LZMA compression for kernel zImage it self and it was pretty good (8 MBs to 2.9 MBs) but the problem that the kernel wasn't loaded so It themes that the bootloader of my device hate LZMA compression or anything else I didn't figure it out so If you find anyway to run and support LZMA compression for kernel please kindly let me know .
Download :
LZMA compression tool
Credit :
Andreas Blaesius
Dan Pasanen
LehKeda (ME )
Neat idea. How do I implement this into a ROM? I see boot.img and recovery.img tutorials but nothing for ROM.
RatchetPanda said:
Neat idea. How do I implement this into a ROM? I see boot.img and recovery.img tutorials but nothing for ROM.
Click to expand...
Click to collapse
You mean compress system.img with LZMA ? if yes , no you can't .
LahKeda said:
You mean compress system.img with LZMA ? if yes , no you can't .
Click to expand...
Click to collapse
Do you think you could modify TWRP so it could handle zips zipped using LZMA instead of just plain deflate? It'd be very useful to get 300-500mb zips down to 200-350mb
RatchetPanda said:
Do you think you could modify TWRP so it could handle zips zipped using LZMA instead of just plain deflate? It'd be very useful to get 300-500mb zips down to 200-350mb
Click to expand...
Click to collapse
It won't reduce the actual size of the ROM it will reduce the zip file size -you will have to download/upload 200 to 300 mb instead of 300 to 500 mb- so it isn't useful that much as you can compress rom zip file before uploading then decompress it again after downloading .
BTW ... Is it good to replace device default bootloader with another one ? and Is there any way to backup it ?
LahKeda said:
It won't reduce the actual size of the ROM it will reduce the zip file size -you will have to download/upload 200 to 300 mb instead of 300 to 500 mb- so it isn't useful that much as you can compress rom zip file before uploading then decompress it again after downloading .
BTW ... Is it good to replace device default bootloader with another one ? and Is there any way to backup it ?
Click to expand...
Click to collapse
Yes that's what I mean is reducing the zip file size, I don't care about the size of the ROM. You probably can on Nexus devices since they are developer friendly however I do not know about other devices.
RatchetPanda said:
Yes that's what I mean is reducing the zip file size, I don't care about the size of the ROM. You probably can on Nexus devices since they are developer friendly however I do not know about other devices.
Click to expand...
Click to collapse
Messing with recovery mechanism doesn't theme so much fair while you can do it by any other file compressor
LahKeda said:
Messing with recovery mechanism doesn't theme so much fair while you can do it by any other file compressor
Click to expand...
Click to collapse
What I'm saying is TWRP cannot currently handle flashable zips using anything other than plain Deflate so it would need modifying to support zips zipped using LZMA2 or Deflate64 for example.
RatchetPanda said:
What I'm saying is TWRP cannot currently handle flashable zips using anything other than plain Deflate so it would need modifying to support zips zipped using LZMA2 or Deflate64 for example.
Click to expand...
Click to collapse
that's theme a little bit interesting .....maybe I'll look into it .

[GUIDE][OREO][8.x] How to modify Oreo kernels to support DualBoot Patcher

The Problem
TLDR: In Oreo ROMs, i.e. Android 8.0/8.1, DualBoot Patcher no longer works, as patched ROMs/kernels will get stuck on Android logo screen(for the Axon 7, it's the 'ZTE, POWERED BY android' screen), and never boot up.
In Oreo(Android 8.0/8.1), Google introduced a new function to fstab, which is early mounting specific partitions. The purpose was so that Android can boot up faster, by ensuring that essential partitions like /system and /vendor are mounted first and the boot process will not be held back by delays in non-essential things like setting up apps. More details can be found here. So the important changes that affect DualBoot Patcher are: 1) There's an important file 'fstab.qcom', which lists all the partitions that Android can use, that got shifted from the '/' directory(the root partition/ramdisk, Android 7.x and below) to the '/system/vendor/etc' directory(in Android 8.x) 2) In addition, another file 'init.qcom.rc', once found in the '/' directory too(in Android 7.x and below), is now shifted to '/system/vendor/etc/init/hw' directory(in Android 8.x) 3) Because of 1), 'init.qcom.rc' now believes that 'fstab.qcom' is in '/system/vendor/etc' and not '/', and so it asks Android to read 'fstab.qcom' from '/system/vendor/etc' 4) In the 'fstab.qcom' file, there are entries for all partitions except /system(and /vendor for Treble devices). For these 2 partitions, they are now found in the dtb(short for Device Tree Binary). How does this affect DualBoot Patcher? 1) DualBoot Patcher expects that 'fstab.qcom' is still in '/' directory(correct me if I'm wrong), so it fails to find this file in Android 8.x ROMs/kernels 2) DualBoot Patcher expects that '/system' is still defined in 'fstab.qcom', which is not the case. Below are the exact changes that Google made(in the case of our Axon 7), note the red parts(the changes):
fstab.qcom(the strike means those lines are now removed/gone)
Code:
/dev/block/bootdevice/by-name/recovery /recovery emmc defaults defaults
[STRIKE][COLOR="red"]/dev/block/bootdevice/by-name/system /system ext4 ro,barrier=1,discard wait[/COLOR][/STRIKE]
init.qcom.rc
Code:
on fs
wait /dev/block/platform/soc/${ro.boot.bootdevice}
symlink /dev/block/platform/soc/${ro.boot.bootdevice} /dev/block/bootdevice
mount_all [COLOR="Red"]/vendor/etc/fstab.qcom[/COLOR]
dtb(converted into dts with dtc)
Code:
fstab {
compatible = "android,fstab";
vendor {
compatible = "android,vendor";
dev = "/dev/block/platform/soc/7464900.sdhci/by-name/vendor";
type = "ext4";
mnt_flags = "ro,barrier=1,discard";
fsmgr_flags = "wait";
status = "disabled";
};
[COLOR="red"]system {
compatible = "android,system";
dev = "/dev/block/platform/soc/624000.ufshc/by-name/system";
type = "ext4";
mnt_flags = "ro,barrier=1,discard";
fsmgr_flags = "wait";
status = "ok";
};[/COLOR]
};
The Solution
There are 3 changes to make for each ROM/kernel: 1) Edit fstab.qcom, dtb and init.qcom.rc 2) Add fstab.qcom and init.qcom.rc back into the ramdisk(i.e. edit the ramdisk) 3) Delete '/system/vendor/etc/fstab.qcom' and '/system/vendor/etc/init/hw/init.qcom.rc'. There are 2 ways you can do this, either manually, or with my script(Work in progress, my sincere apologies)
Method 1: Manually modify ROM and kernel
Files you will need:
Note: the 'files.zip' attached below contains 'dtc', 'magiskboot', 'mkbootimg', 'unpackbootimg'. Extract it to get these files. Feel free to scan them for viruses, I assure you they are clean and not viruses for sure
- boot.img you want to patch
- init.qcom.rc, fstab.qcom from the ROM you are patching
- magiskboot binary(found in /data/magisk or /data/adb/magisk if you installed magisk, otherwise download the one attached below)
- dtc binary(download the one attached below)
If you are patching Hellsgate or Schwifty, you also need:
- unpackbootimg, mkbootimg(attached below)
- Image.gz-dtb(from the flashable zip of the kernel)
Note: You also need a boot.img, but this will be from the ROM you are flashing/have flashed(extract from the ROM zip)
Preliminary step: Prepare the files
- Before you start, I would recommend copying all the files into a directory where you can chmod/execute binaries. I personally recommend '/data/local/tmp', or '/cache'(anywhere in /cache is fine). The guide below assumes that all these files are in the same directory. Also, chmod all the binaries, for example, do this in your working directory:
Code:
chmod 0755 *
- Also, I would recommend backing up 'fstab.qcom' and 'init.qcom.rc'
Additional Step: If you wish to patch kernels like Hellsgate and Schwifty
- First, unpack your ROM's stock kernel:
Code:
./unpackbootimg -i boot.img
- Then, repack the kernel as a Hellsgate/Schwifty kernel:
Code:
./mkbootimg --kernel Image.gz-dtb --ramdisk boot.img-ramdisk.gz --cmdline "androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x237 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 [email protected] androidboot.selinux=permissive buildvariant=userdebug" --base 80000000 --pagesize 4096 --kernel_offset 00008000 --ramdisk_offset 01000000 --second_offset 00f00000 --tags_offset 00000100 --os_version 8.1.0 --os_patch_level [COLOR="red"]2018-06[/COLOR] --hash sha1 --output ./boot-new.img
- Note: For the red part in the above command, adjust for the month that your desired kernel is released. E.g. If your desired kernel was released in 2018 June, you put '2018-06', while if it was released in 2018 July, you put '2018-07', and so on.
- From now on, take note that everytime I mention 'boot.img', for you, it will be 'boot-new.img'(I'll bold each one that you have to change to 'boot-new.img')
Step 1: Unpack the boot.img
Code:
./magiskboot --unpack [COLOR="red"]boot.img[/COLOR]
- Now you get 3 additional files: 1) kernel(not editing this) 2) ramdisk.cpio(gonna edit this) 3) dtb(also editing this)
Step 2: Decompile the dtb
Note: dtb is a BINARY so don't open it with a text editor
Code:
./dtc -I dtb -O dts -o dt.txt dtb
- Another note: It will probably give you a lot of warnings, but it's harmless so just ignore them(I've edited multiple kernels and tested them myself, no bugs so far)
Step 3: Edit the decompiled dts
- Open the created 'dt.txt' with a root text editor(I use Simple Explorer, you can use FX file explorer, or ES file explorer)
- Search for this word:
Code:
/system
. You should find this line:
Code:
dev = "/dev/block/platform/soc/624000.ufshc/by-name/system";
- Remove the entire chunk quoted below:
Code:
system {
compatible = "android,system";
dev = "/dev/block/platform/soc/624000.ufshc/by-name/system";
type = "ext4";
mnt_flags = "ro,barrier=1,discard";
fsmgr_flags = "wait";
status = "ok";
};
- Take note that you will have to remove 1 '};'(at the bottom of the above quote), nothing more, nothing less
Step 4: Recompile the dtb
Code:
./dtc -I dts -O dtb -o dtb1 dt.txt
- Again, it might give you a lot of warnings but just ignore them
- Also, rename the new dtb so that magiskboot will compile this new dtb into your modified kernel:
Code:
mv dtb dtb.bak
Code:
mv dtb1 dtb
Step 5: Edit fstab.qcom
- Open 'fstab.qcom' file with a root text editor
- Add the following red line, below the line about '/recovery', above the line about '/data':
Code:
/dev/block/bootdevice/by-name/recovery /recovery emmc defaults defaults
[COLOR="red"]/dev/block/bootdevice/by-name/system /system ext4 ro,barrier=1,discard wait[/COLOR]
/dev/block/bootdevice/by-name/userdata /data f2fs nosuid,nodev,noatime,nodiratime,data_flush wait,check,encryptable=/dev/block/bootdevice/by-name/cryptkey,quota,formattable[/CODE]
- Save the 'fstab.qcom' file
Step 6: Edit init.qcom.rc
- Open 'init.qcom.rc' with a root text editor
- Look for this line:
Code:
mount_all /vendor/etc/fstab.qcom
- Change it into this line:
Code:
mount_all [COLOR="red"]/fstab.qcom[/COLOR]
- Save the 'init.qcom.rc' file
Step 7: Modify kernel ramdisk
-First do:
Code:
./magiskboot --cpio ramdisk.cpio 'add 0640 fstab.qcom fstab.qcom'
- Then do:
Code:
./magiskboot --cpio ramdisk.cpio 'add 0750 init.qcom.rc init.qcom.rc'
Step 8: Create a new, DBP-compatible boot.img
Code:
./magiskboot --repack [COLOR="red"]boot.img[/COLOR]
- You will get a new boot.img, named 'new-boot.img'
Step 9: Install the modified kernel
- First, flash the boot.img(using TWRP or Flashify or another tool)
- Then, delete these 2 files:
Code:
/system/vendor/etc/fstab.qcom
and
Code:
/system/vendor/etc/init/hw/init.qcom.rc
- Note: Make sure you do not reboot after installing boot.img and before deleting the above 2 files
That's it! If you completed all the steps above properly, you should have a working DBP-compatible boot.img that you can put in a flashable zip and patch with DualBoot Patcher
if you don't know how to make a flashable zip to install your modified boot.img, you can use the one I attached below(named 'flashable-kernel-template.zip'). What you have to do is download it, then extract it and make a new zip containing your modified boot.img(basically, create a new zip with the 'META-INF' folder from my zip and your 'boot.img'. The zip automatically deletes
Code:
/system/vendor/etc/fstab.qcom
and
Code:
/system/vendor/etc/init/hw/init.qcom.rc
so you won't need to do this yourself
Note: If you are using my flashable zip, note that you have to rename your modified 'new-boot.img' to 'boot.img' before you compress it into a new flashable zip. Otherwise you will get an error when flashing in recovery
Note 2: Avoid using the flashable zip template for non-modified kernels, it can render your ROM unable to boot!
Method 2: Work in Progress
Method 2: Use my automated script
Please do leave feedback on whether this guide is clear, and also if any of the steps are not working for you! Happy Dualbooting
Sources:
Github Problem Discussion
Problem Solution
Reserved 1
Reserved 2
This is going to be useful. Personally I just want to run custom O as primary and N as a secondary. Mainly because O doesn't have properly working Daydream and for a couple of games that aren't compatible anymore with O. If I'm only trying to attach LOS14.1 as secondary I wouldn't need to patch anything extra O from this guide? Though I can't install the patched ROM it gives an error.
Edit: Oops missed reading from the old guide the primary ROM needs to be stock. I guess I need to patch then. Do I need Linux to do all the editing?
Infy_AsiX said:
This is going to be useful. Personally I just want to run custom O as primary and N as a secondary. Mainly because O doesn't have properly working Daydream and for a couple of games that aren't compatible anymore with O. If I'm only trying to attach LOS14.1 as secondary I wouldn't need to patch anything extra O from this guide? Though I can't install the patched ROM it gives an error.
Edit: Oops missed reading from the old guide the primary ROM needs to be stock. I guess I need to patch then. Do I need Linux to do all the editing?
Click to expand...
Click to collapse
Actually yeah, if your custom O is primary you don't need to patch it(the kernel, I mean)! You still need to patch the ROM so that it doesn't wipe /system when you OTA update your custom O, which means you need an unpatched custom O stock kernel flsshable zip(sorry for the mouthful). But if you don't OTA update then no need The last I tried, using stock ROM as secondary worked for me though? Didn't find any issues. But I might just be lucky, be careful if you try that.
As for your last question, nope all these commands are meant for Terminal Emulator app on an Android phone! Just use the binaries in the attached files.zip, they are all compiled for Android and do not work on Linux desktops. All the best If you need help just ask here!
haoyangw said:
Actually yeah, if your custom O is primary you don't need to patch it(the kernel, I mean)! You still need to patch the ROM so that it doesn't wipe /system when you OTA update your custom O, which means you need an unpatched custom O stock kernel flsshable zip(sorry for the mouthful). But if you don't OTA update then no need The last I tried, using stock ROM as secondary worked for me though? Didn't find any issues. But I might just be lucky, be careful if you try that.
As for your last question, nope all these commands are meant for Terminal Emulator app on an Android phone! Just use the binaries in the attached files.zip, they are all compiled for Android and do not work on Linux desktops. All the best If you need help just ask here!
Click to expand...
Click to collapse
Figured out the error after dual boot patch on LOS14.1 was my mistake in modifying the update-script incorrectly. Nothing to do with N/O/this guide. However now I tried installing it to data slot so dirty flashing and restoring the system partition won't be complicated. The issue is trying to boot primary it vibrates five times at ZTE logo and goes to recovery. Trying to switch to primary in dualbootutilities gives an error something like (from memory) data/media/0/boot.img cannot be found. I guess DBP installed even on data changes the structure of boot and primary on O doesn't fit so can't boot. Just want your advice, it probably means patching O when O is primary is necessary then?
Infy_AsiX said:
Figured out the error after dual boot patch on LOS14.1 was my mistake in modifying the update-script incorrectly. Nothing to do with N/O/this guide. However now I tried installing it to data slot so dirty flashing and restoring the system partition won't be complicated. The issue is trying to boot primary it vibrates five times at ZTE logo and goes to recovery. Trying to switch to primary in dualbootutilities gives an error something like (from memory) data/media/0/boot.img cannot be found. I guess DBP installed even on data changes the structure of boot and primary on O doesn't fit so can't boot. Just want your advice, it probably means patching O when O is primary is necessary then?
Click to expand...
Click to collapse
Oh you mean you flashed custom O, and after that you flashed you N data slot ROM? You're partially right, if you flash your data slot ROM after a non-patched ROM, you'll have the data slot kernel installed i.e. the LOS 14.1 stock kernel, which cannot boot an O ROM. This is because DBP works by storing multiple kernels on your /data/media/0/Multiboot folder, when you 'switch ROMs' actually what happens is DBP flashes the kernel of the ROM you're switching to. Obviously a N kernel cannot boot an O ROM so you cannot boot. Unfortunately, DBP only stores kernels that you flash with patched zips(i.e. if you flash a DBP-patched ROM/kernel zip, only then will DBP store the kernel in its custom Multiboot folder). So because you didn't patch your O primary ROM, its kernel is not saved and you cannot use DBPUtilities. What you can do is either make your own non-patched kernel zip file for your O ROM's stock kernel that you flash everytime you want to switch to primary, or you patch your primary ROM and then you can use DBPUtilities. However B01 kernel has a slightly different precedure for adding DBP support that this guide doesn't explain(I'm sorry) I'll update it when I find time. Don't follow this guide to patch B01! It won't boot, I tried But I know what changes to make when modifying a B01 kernel don't worry
lost this post when I pressed reply. This RR-O Kranoner 20180511 has the fstab.qcom and init.qcom.rc still on root / directory. But patching only DBP patching hellsgate kernel after having LOS14.1 on data slot 1 still has the same issue. Alternatively installing the mod boot.img allows primary to boot but after using DBP utilities to switch to data slot 1 (onscreen says success) the data slot 1 gets stuck on ZTE logo with 5 vibrates instead. Even tried flashing the final Beastmode 14.1 kernel DBP patched to data slot 1 after switched, five vibrates to recovery.
Lost Magisk install after step nine. Just reinstalling it is fine. Did you forget the flashable zip template by the way?
Infy_AsiX said:
lost this post when I pressed reply. This RR-O Kranoner 20180511 has the fstab.qcom and init.qcom.rc still on root / directory. But patching only DBP patching hellsgate kernel after having LOS14.1 on data slot 1 still has the same issue. Alternatively installing the mod boot.img allows primary to boot but after using DBP utilities to switch to data slot 1 (onscreen says success) the data slot 1 gets stuck on ZTE logo with 5 vibrates instead. Even tried flashing the final Beastmode 14.1 kernel DBP patched to data slot 1 after switched, five vibrates to recovery.
Lost Magisk install after step nine. Just reinstalling it is fine. Did you forget the flashable zip template by the way?
Click to expand...
Click to collapse
Oh hmm did you install the right version of Hellsgate for your data slot 1? I think LOS 14.1 needs a very old version(R2.1? I think). I'm not sure about beastmode kernel though, I'm sorry And thanks for the reminder about the zip template, o dear I forgot about it I'll upload it now!
haoyangw said:
Oh hmm did you install the right version of Hellsgate for your data slot 1? I think LOS 14.1 needs a very old version(R2.1? I think). I'm not sure about beastmode kernel though, I'm sorry And thanks for the reminder about the zip template, o dear I forgot about it I'll upload it now!
Click to expand...
Click to collapse
Sorry that post was worded poorly due to rushed recalling. I meant RR-O primary had Hellsgate kernel patched by this guide, which shouldn't be necessary as the two issue ROM files are still on root directory (patching with DBP instead didn't work as I posted before)? Still had to install the mod boot.img to manage to boot but then data slot 1 LOS14.1 won't boot. I was going to try patching with this guide the kernel I intend for LOS14.1 but it's lacking the image.gz-dtb file, I'd only patched it with DBP and that should be enough as it's an N ROM. I guess I could use an older hellsgate suited to N but Beastmode was updated til a little later so I'd prefer it.
Thanks for the zip template. Just checking, it's not actually needed if I can just install the modded boot.img directly in TWRP anyway?
Infy_AsiX said:
Sorry that post was worded poorly due to rushed recalling. I meant RR-O primary had Hellsgate kernel patched by this guide, which shouldn't be necessary as the two issue ROM files are still on root directory (patching with DBP instead didn't work as I posted before)? Still had to install the mod boot.img to manage to boot but then data slot 1 LOS14.1 won't boot. I was going to try patching with this guide the kernel I intend for LOS14.1 but it's lacking the image.gz-dtb file, I'd only patched it with DBP and that should be enough as it's an N ROM. I guess I could use an older hellsgate suited to N but Beastmode was updated til a little later so I'd prefer it.
Thanks for the zip template. Just checking, it's not actually needed if I can just install the modded boot.img directly in TWRP anyway?
Click to expand...
Click to collapse
Oh you're right, if the 2 files are still present you don't have to patch using this guide. Just checking, what version of hellsgate are you using for primary? And yes you're right! N ROMs/kernels don't have to be patched with this guide for DBP I'm not very sure why you can't boot and get the 5 led flashes though
As for your last question, you're right no need this zip in you install using TWRP.
haoyangw said:
Oh you're right, if the 2 files are still present you don't have to patch using this guide. Just checking, what version of hellsgate are you using for primary? And yes you're right! N ROMs/kernels don't have to be patched with this guide for DBP I'm not very sure why you can't boot and get the 5 led flashes though
As for your last question, you're right no need this zip in you install using TWRP.
Click to expand...
Click to collapse
The last B32+10 hellsgate v3.0. Dunno but the guide did manage to allow primary to boot whereas it wouldn't before. Both N hellsgate and beastmode are lacking the image.gz-dtb so I can't patch them. I guess I'll try stock next, I really wanted KCAL to use on Daydream tho ::crying:. If that fails I might try stock N as primary when I'm about to clean flash update O.
Infy_AsiX said:
The last B32+10 hellsgate v3.0. Dunno but the guide did manage to allow primary to boot whereas it wouldn't before. Both N hellsgate and beastmode are lacking the image.gz-dtb so I can't patch them. I guess I'll try stock next, I really wanted KCAL to use on Daydream tho ::crying:. If that fails I might try stock N as primary when I'm about to clean flash update O.
Click to expand...
Click to collapse
Oh dear I'm sorry to hear Just checking are you using LOS 14.1 builds from 2018? I might know what's wrong
haoyangw said:
Oh dear I'm sorry to hear Just checking are you using LOS 14.1 builds from 2018? I might know what's wrong
Click to expand...
Click to collapse
yeah latest official
Sent from my Xperia Z3C using XDA Labs
Infy_AsiX said:
yeah latest official
Click to expand...
Click to collapse
Oh I probably should add this in the OP, Nougat builds with 2018 Security patch level behaves the same way as Oreo ROMs, they also have the init.qcom.rc and fstab.qcom in /system. So I would believe that latest LOS 14.1 also needs the exact same patching method as Oreo(if you can check and confirm this that'll be great). I haven't analysed the Nougat hellsgate and beastmode kernels so I'm not sure how to patch them, I'll let you know asap when I find out something. Sorry about the mistake, I didn't realise there's still a Nougat ROM being regularly updated
Great thanks for the guide and mods. Sorry for the late follow up, it did take awhile to get working. After some confusion and trouble with figuring out how some O ROMs still don't use the early mount method. While N ROM and kernels don't in fact need patching by this guide. Also B12 can't be dual booted with any N ROMs due to bootstack incompatibility (flashing bootstack after a DBP install doesn't seem to take effect to help). My target kernel was Hellsgate 3 for B32+10, which oddly needed fstab.qcom modded per guide but not init.qcom.rc all despite the kernel being for non early mount ROMs. Yes really, after all of that figured out, I got it working!
I'm glad to report it works as intended with the right setup. Now with B12 ROMs currently all affected by the wired audio cpu extra 50% load bug, using B32+10 is a working fallback. The trade off being apparently dual-sim issues (reported by some as present, some not), no GCam HDR support and improper hi-res audio support (though hi-fi DAC was already working and hi-res is debatably useless). In any case if dual booting O with N is desired B32+10 is the latest supported available with above stated differences. This is the only way presently for using a stable-ish O ROM and N's fully functioning Daydream and a couple of AAA games deprecated after N such as Fahrenheit: Indigo Prophecy and Jade Empire. Now I can also play around testing Kranoner's N Vertex EAS supported ROM and kernel.
I've attached the B32+10 Hellsgate 3 modded per this guide using Kranoner's 180511 RR-O for anyone interested in getting it straight working without the mess. A few pointers. The zip still needs needs to be patched to primary/secondary/whatever chosen slot before use. Magisk has to be reinstalled after installing the modified kernel, primary Magisk zip does not need DB patching. Using secondary slot, to fill up like huge wasted space 6GB system partition is smart if you're not installing many apps.
Sent from my ZTE Axon 7 using XDA Labs
////[removed]////
Tried this with my device and it didn't work. Alcatel Tetra with 8.1 Stock. Runs GSI images up to 10. MT6739 SOC. Doesn't boot if you simply remove the entry. Couldn't even change ro to rw and have it boot. I was able to remove verify and that was about it. I was able to get the fstab and init file migrated back to ramdisk and it booted once i modified the init file to point to the right locations. I got DBP supporting my treble device properly. The last step is to figure out how to disable/remove the system early mount. This topic seems dead but I figure it's worth a try. I've been working on this Project on and off for 2+ months now and would really like to hit paydirt.
you do realize this is an Axon7 thread , yes?
mrrocketdog said:
you do realize this is an Axon7 thread , yes?
Click to expand...
Click to collapse
I'm Sure he's not lost .
U realize this is a place Dev's take ideas from each other and try to port it to other devices Right?

[VENDOR] [surya/karna] Unified - All Custom ROMS [10] & [11]

PHP:
/*
* I'm not responsible for bricked devices, dead SD cards, thermonuclear war, or you getting fired because the alarm app failed (like it did for me...).
* Please do some research if you have any concerns about features included in the products you find here before flashing it!
* YOU are choosing to make these modifications, and if you point the finger at me for messing up your device, I will laugh at you.
* Your warranty will be void if you tamper with any part of your device / software.
* Same statement for XDA.
*/
FEATURES
. The first, the one and the only custom vendor for dynamic partition in the world : I challenge you all to show me who did it before !
. If you find any custom rom with similar work since the first release of this one : it is just a copied and a stolen work [fake Google roms +++] !!!
. Compatible with all regions / basebands / firmwares / device variants
. Works with All AOSP/CAF based ROMs [10] & [11], Experimental, Official & Unofficial [TESTED]
. May works on fake Google roms but i don't take any responsibility
. Mount RO/RW available with no bootloop after reboot ! [Magisk/SU required]
. SafetyNet passed
. Full test passed : audio, ril, wifi, bt, fm radio, camera, sensors, fp scanner, nfc, ...
. All known hardware issues on custom roms are fixed : camera, wifi, bt, hdr playback, chrome ... and overheating !
. Custom Kernel with stock zImage [untouched +++]
IMPORTANT !
. NO firmware change is needed from the user side, so don't repeat this question many times ... just read up again !
. Formatting /data is required when you flash this vendor the first time +++
. Never go back to the previous versions due to the possible build.fingerprint change [Old releases are automatically removed] +++
. Dirty Update : always delete with file/root explorer or in TWRP this folder :
/data/property and reboot
You must delete these files & folders in /product partition from your custom rom
[File/Root explorer needed] :
/product/vendor_overlay/29/etc/audio
/product/vendor_overlay/29/etc/audio_policy_configuration.xml
/product/vendor_overlay/29/etc/audio_policy_engine_configuration.xml
/product/vendor_overlay/29/lib/soundfx
/product/vendor_overlay/29/lib64/soundfx
&
/product/vendor_overlay/29/etc/wifi
/product/vendor_overlay/29/overlay
& finally
/product/vendor_overlay/29/etc/qdcm_calib_data_nt36672c_huaxing_fhd_video_mode_dsi_panel.xml
/product/vendor_overlay/29/etc/qdcm_calib_data_nt36672c_tianma_fhd_video_mode_dsi_panel.xml
Already included in this vendor ... and since i'm the original author !
[ OPTIONAL ]
If you have the madness and the paranoia with security like Google, you can still relock /vendor again to the stock RO state ... But you will not be able to mount /vendor RW again even with root until you reflash the provided vendor.zip again !
How to [terminal or adb shell] :
su
tune2fs -O verity /dev/block/dm-1
*******
!!!
MIUI Users : sorry for you, but this is for custom ROMS " ONLY "
TROLLS & NOOBS, stay away ... Please !
!!!​
Prerequisite:
POCO X3 NFC = surya
POCO X3 [no NFC] = karna
No matter where you live : india, china, russia, europe, usa or africa ... !
Kernel Source [Prebuilt] : Here
Created : 2021-02-27
Latest Update : 2021-03-21
DOWNLOAD
RESERVED for "Changelog"
Update : [2021-03-21] Highly Recommended !
- overlay folder [/vendor] : secure & total remove ... R.I.P forever !
You can now remove it from here too ... with no issue :
/product/vendor_overlay/29/overlay
[As always : no /data formatting is required if done in the previous builds !]
Update : [2021-03-20]
fix compatibility with all custom roms [10] & [11] +++ :
- build : preserve AVB structure [R/W still available in root mode]
- tune2fs : restore some stock feature flags [dir_index, huge_file, extra_isize]
- fstab [kernel & vendor] : small update
- vendor selinux : property_contexts fix
- build.prop : clean-up
Update : [2021-03-18]
clean-up & rework from scratch :
. all audio config [over 20 files +++]
. all media_codecs config
. new mixer_paths
[=> Exclusive]
- true resampling fix : r.i.p audio crackling and all audio issues in UX, Dialer, emulators ... etc [forever]
- improve audio & camera recording
- audio/video playback [Speaker, Headphones & BT] : Hi-Fi quality, loud & noiseless
[but first, you must delete these files with your File/Root Explorer:
/product/vendor_overlay/29/etc/audio
/product/vendor_overlay/29/etc/audio_policy_configuration.xml
/product/vendor_overlay/29/etc/audio_policy_engine_configuration.xml
/product/vendor_overlay/29/lib/soundfx
/product/vendor_overlay/29/lib64/soundfx]
Update : [2021-03-12]
- move to global 12.0.8.0 as firmware base [boot & vendor]
- ramdisk :
. disable mi_thermald and re-enable again thermal-engine
[on all custom roms : mi_thermald breaks the proximity sensor & suspend service in deepsleep => avoid hand wave gesture & AOD to work properly !]
. clean up & update
- vendor_selinux : add more camera permissions in property_contexts
- media_codecs : remove unused .xml
- ueventd.rc : rework from scratch
Update : [2021-03-07]
- ramdisk :
. update cpuset & schedtune settings
. improve memory multitasking
. make that "damn" fingerprint truly responsive
. enable UFS powersaving
. some clean-up & disable MIUI audio service
- media_profiles :
. rework from scratch
. add slow motion profile support : up to 1080p/120 fps & 720p/960 fps
. front video camera : add 4K support
- build.prop :
=> update parameters for : camera, ril, performance, playback ... and more
Update : [2021-03-05]
- rework from scratch : init.qcom.sh & init.qcom.post_boot.sh
- ramdisk : clean-up and add init.qcom.power.rc
. fix CPU instability : set 300 mHz as CPU minimum frequency for all cores / update schedutil governor parameters
. cpu_boost : improve touch responsiveness
. add built-in display power saving [for both huaxing & tianma panels]
- vendor permissions : rebuild from scratch / fix wronlgy settled paths (by Xiaomi) in some qti.xml
- camera : rework from scratch ISO/lowlight config
- remove dummy hbtp folder ... since there is no binary to load or device specific config
- targetconfig : update CoreCtlCpu to [0,6]
- build.prop : clean up and move NFC parameters to build_surya.prop
- [Bonus] : Wi-Fi signal improved (x2) !!!
. 2.4 Ghz : 144 => 300
. 5 GHz : 433 => 866
[but first, you must delete this folder, with your File/Root Explorer :
/product/vendor_overlay/29/etc/wifi ]
Update : [2021-03-01]
- update msm_irqbalance.conf
- update audio_effects.conf & remove audio_effects.xml
- universal vbmeta & vbmeta_system added
Update : [2021-02-27]
- initial release
- rework all build.prop (vendor & odm) from scratch
- debloated from unused MIUI folders, files & configs
- Kernel :
. enforcing selinux by default
. workqueue enabled in cmdline => better dynamic refresh rate handling by the CPU & stellar deep-sleep
. fstab reworked from scratch
the image you made is for enable rw or not?
my phone is poco x3 nfc surya
janhammer504 said:
To make things clear :
POCO X3 NFC = surya
POCO X3 (no NFC) = karna
No matter where you live (india, china, russia, europe, usa or africa) ... Choose the right vendor.img for your device !
[Both images were tested by me]
Click to expand...
Click to collapse
please share the surya image
aallii2 said:
please share the surya image
Click to expand...
Click to collapse
check the DOWNLOAD link up !
janhammer504 said:
check the DOWNLOAD link up !
Click to expand...
Click to collapse
tnx bro i'm downloading n i'll test
its not working after restart didnt boot n just go to recovry
aallii2 said:
its not working after restart didnt boot n just go to recovry
Click to expand...
Click to collapse
Wich firmware version you had just before flashing ???
The vendor provided must match the firmware version that you have !!!
janhammer504 said:
PREREQUISITE
- adb enabled (developer options)
- root (Magisk/SU)
- adb for Windows (Minimal ADB and Fastboot, provided)
- USB cable always connected
LIVE Flashing :
adb shell
su
dd if=/sdcard/vendor.img of=/dev/block/dm-1
View attachment 5232189
Reboot your phone right away ... then use your File/Root Explorer to test the mount RO/RW option and reboot again to check that there is no bootloop !
(Optional)
If you have the madness and the paranoia with security like Google, you can still re-enable AVB/Verity again ... But you will not be able to mount /vendor RW again even with root until you reflash the provided vendor.img again !
tune2fs -O verity /dev/block/dm-1
Check the full tutorial here to build your own custom vendor ... if you want !
DOWNLOAD
Click to expand...
Click to collapse
... so, I can confirm that this is indeed working nicely, flashed RW vendor for Surya, just for the sake of the functionality, because I'm not sure about benefits I can get from writeable vendor (forgive my ignorance)...
... Thank you very much for your hard work...
just FYI I did flash it in Ofox recovery in built-in terminal, and also directly from running Android via Termux, so you don't need PC for it, just saying...
jeryll said:
... so, I can confirm that this is indeed working nicely, flashed RW vendor for Surya, just for the sake of the functionality, because I'm not sure about benefits I can get from writeable vendor (forgive my ignorance)...
... Thank you very much for your hard work...
just FYI I did flash it in Ofox recovery in built-in terminal, and also directly from running Android via Termux, so you don't need PC for it, just saying...
Click to expand...
Click to collapse
i use adb shell because terminal is too small for me, and for making tutorial.
the benefit ??? well there are a bunch of fixes to do in /vendor... check here for example
(the images i provided are clean with no modification, so i let developers or users doing their own modifications)
janhammer504 said:
Wich firmware version you had just before flashing ???
The vendor provided must match the firmware version that you have !!!
Click to expand...
Click to collapse
india 12.0.9
magisk 21.4
jeryll said:
... so, I can confirm that this is indeed working nicely, flashed RW vendor for Surya, just for the sake of the functionality, because I'm not sure about benefits I can get from writeable vendor (forgive my ignorance)...
... Thank you very much for your hard work...
just FYI I did flash it in Ofox recovery in built-in terminal, and also directly from running Android via Termux, so you don't need PC for it, just saying...
Click to expand...
Click to collapse
hey bro how you flashed in orangefox?
i tried but this happened:
sh: adb: command not found
aallii2 said:
hey bro how you flashed in orangefox?
i tried but this happened:
sh: adb: command not found
Click to expand...
Click to collapse
in recovery adb not needed, just use
dd if=/sdcard/vendor.img of=/dev/block/dm-1
now i cant install any rom :
updater process ended with error 7
pls help
aallii2 said:
now i cant install any rom :
updater process ended with error 7
pls help
Click to expand...
Click to collapse
O.M.G
it looks like you never used terminal
this is not a flashable file, it's a command line.
open terminal in your recovery to do that.
or use adb shell
janhammer504 said:
O.M.G
it looks like you never used terminal
this is not a flashable file, it's a command line.
open terminal in your recovery to do that.
or use adb shell
Click to expand...
Click to collapse
jeryll said:
in recovery adb not needed, just use
dd if=/sdcard/vendor.img of=/dev/block/dm-1
Click to expand...
Click to collapse
Now this came:
write error: Operation not permitted
jeryll said:
in recovery adb not needed, just use
dd if=/sdcard/vendor.img of=/dev/block/dm-1
Click to expand...
Click to collapse
Now this came:
write error: Operation not permitted

			
				
Use Minimal ADB and Fastboot.zip, it's the simplest and the fastest way.
Unzip and click on Minimal ADB and Fastboot.exe
type :
adb shell
su
It works like terminal in Windows. You can't go wrong !
Follow the instructions (1 post) !
aallii2 said:
india 12.0.9
magisk 21.4
Click to expand...
Click to collapse
wtf man, you should pick vendor.img from karna folder not surya !
janhammer504 said:
Use Minimal ADB and Fastboot.zip, it's the simplest and the fastest way.
Unzip and click on Minimal ADB and Fastboot.exe
type :
adb shell
su
It works like terminal in Windows. You can't go wrong !
Follow the instructions (1 post) !
Click to expand...
Click to collapse
i installed 12.0.7.0 global with magisk 22.0 then flashed vendor.img v12.0.7.0 but when restarted it stucked n i pressed power .phone boot but root explorer can't mount rw n just added shell in magisk

Development High Resolution Mod for Xperia 1 IV

Hey everyone,
before the official Android 12 release from Sony it was possible to force the display to render at full 4K resolution via "wm size" command.
With the release of Android 12 this behaviour changed and it´s no longer possible to force 4K resolution that way.
I looked into quite a few ways go get full 4K rendering back and discovered that even for supported apps, where the kernel switches to timings for 4k resolution, the actual rendering for the displayed content is upscaled 2k.
That means there unfortunately is no way, that I was able to find, to force full 4k rendering on the device as of now.
The best I could do, is to force the default 4k mode where kernel panel timings are at 4k, but content is upscaled 2k for regular usage. The result is the following: Every app, except the ones you add to game optimizer app, will be rendered like apps that sony enabled 4k resolution for.
That´s the best I can do at the moment.
This mod might impact battery life, smoothness and other things, as more resources are needed.
However I didn´t have any problems during my usage.
The difference is not huge, but it´s visible if you look for it. For example the fonts at the bottom of Google Fotos app, like Fotos, Search etc are way more crisp.
You can check in logcat if high-resolution config is used via:
Code:
adb logcat | grep "high resolution"
While having this mod flashed, the following line means high-resolution mode (panel running at 4k, content is upscaled 2k at 120fps) is enabled:
Code:
11-11 18:56:49.801 1475 1758 D SDM : HWCDisplay::SetActiveConfigWithConstraints: Setting to a high resolution config: 1
While having this mod flashed, the following line means high-resolution mode (panel running at 4k, content is upscaled 2k at 60fps) is enabled:
Code:
11-11 18:56:56.725 1475 1761 D SDM : HWCDisplay::SetActiveConfigWithConstraints: Setting to a high resolution config: 0
Changelog:
update with dtbo.img for firmware 64.1.A.0.869
Requirements:
- Sony Xperia 1 IV running on A13, with at unlocked bootloader
- fastboot method does not require root
- method via kernel managers does require root
- backup your current dtbo.img or make sure you have a copy of the same (EXKM can backup dtbo.img, or you can grab it from xperifirm)
Installation:
1. Download one of the attached dtbo.imgs
Please note: This mod is made for Android 13 firmware, it will not work on Android 12 firmware
2. Do either 2a or 2b!
2.a Boot to fastboot and flash via:
Code:
fastboot flash dtbo filenameofdtbo.img
2.b Flash filenameofdtbo.img via EXKM or any app that allows flashing dtbo.img
3. reboot
this one is mine too
this as well
Anyone tried this yet, if so what was the impact on the battery?
sillygooes said:
Anyone tried this yet, if so what was the impact on the battery?
Click to expand...
Click to collapse
Please refrain from asking questions which can be answered with your own common sense lmao
Mijan94 said:
Please refrain from asking questions which can be answered with your own common sense lmao
Click to expand...
Click to collapse
Just flashed it and it seems to work pretty well so far, can notice a slight difference in sharpness of text and stuff with the new dtbo image flashed vs stock, only side effect was the boot animation being corrupted but it's fine once booted into Android.
A question though, should this be safe to flash for future Android 13-based firmware versions? Or is this specific to only the initial Android 13 firmware? (64.1.A.0.851)
OhayouBaka said:
Just flashed it and it seems to work pretty well so far, can notice a slight difference in sharpness of text and stuff with the new dtbo image flashed vs stock, only side effect was the boot animation being corrupted but it's fine once booted into Android.
A question though, should this be safe to flash for future Android 13-based firmware versions? Or is this specific to only the initial Android 13 firmware? (64.1.A.0.851)
Click to expand...
Click to collapse
Yes, boot animation can get scrambled up indeed.
It depends on changes done to future firmware updates. Can't foresee the future, but it's unlikely there are much changes.
It's easy to either backup dtbo.img before flashing the modded one or simply reflash Stock extracted from Xperiafirm/unsin tool though.
No Bootloader unlock needed. Still.
service call SurfaceFlinger 1035 i32 x
(x=0,1,2,3)
1. 1096x2560x60x397132cmd
2. 1644x3840x120x397108cmd
3. 1644x3840x60x397108cmd
4. 1096x2560x120x397132cmd
Google changed the behavior for native Resolution switches in the Android Settings. Just like Samsung has it since YEARS. Thanks for the alternative tho
Also note that some apps do not work with an unlocked bootloader, for security standards requires a locked bootloader.
All throughout the internetz, people have had issues with apps like banking/finance apps, Google proprietary finance apps like Wallet or Google pay, or apps store like Google play.
OhayouBaka said:
Just flashed it and it seems to work pretty well so far, can notice a slight difference in sharpness of text and stuff with the new dtbo image flashed vs stock, only side effect was the boot animation being corrupted but it's fine once booted into Android.
A question though, should this be safe to flash for future Android 13-based firmware versions? Or is this specific to only the initial Android 13 firmware? (64.1.A.0.851)
Click to expand...
Click to collapse
Figured out a more elegant method that doesn't corrupt the boot animation and should work on any future firmware updates. Simply flash this Magisk Module, which contains the commands that @Miustone provided. Yes, this does still require a bootloader unlock as you are only able to apply this command with root privileges or a Magisk script.
You should also be able to use this on other devices as well running Android 12 or newer, by following these steps to edit the Magisk module .zip provided:
Just run:
Code:
adb shell
Code:
su
Code:
dumpsys SurfaceFlinger | grep hwcId
Pick your id number according to resolution/refresh rate you desire from the list.
Here is an example output from Xperia 1 IV:
Code:
{id=0, hwcId=0, resolution=1096x2560, refreshRate=60.00 Hz, dpi=428.28x427.79, group=0}
{id=1, hwcId=1, resolution=1096x2560, refreshRate=120.00 Hz, dpi=428.28x427.79, group=0}
{id=2, hwcId=2, resolution=1644x3840, refreshRate=60.00 Hz, dpi=642.42x641.68, group=0}
{id=3, hwcId=3, resolution=1644x3840, refreshRate=120.00 Hz, dpi=642.42x641.68, group=0}
Edit the service.sh file inside the Magisk module zip
Code:
service call SurfaceFlinger 1035 i32 3
At this line, replace the number at the end with the id number you grabbed from the earlier adb commands
OhayouBaka said:
Figured out a more elegant method that doesn't corrupt the boot animation and should work on any future firmware updates. Simply flash this Magisk Module, which contains the commands that @Miustone provided. Yes, this does still require a bootloader unlock as you are only able to apply this command with root privileges or a Magisk script.
You should also be able to use this on other devices as well running Android 12 or newer, by following these steps to edit the Magisk module .zip provided:
Just run:
Code:
adb shell
Code:
dumpsys SurfaceFlinger | grep hwcId
Pick your id number according to resolution/refresh rate you desire from the list.
Here is an example output from Xperia 1 IV:
Code:
{id=0, hwcId=0, resolution=1096x2560, refreshRate=60.00 Hz, dpi=428.28x427.79, group=0}
{id=1, hwcId=1, resolution=1096x2560, refreshRate=120.00 Hz, dpi=428.28x427.79, group=0}
{id=2, hwcId=2, resolution=1644x3840, refreshRate=60.00 Hz, dpi=642.42x641.68, group=0}
{id=3, hwcId=3, resolution=1644x3840, refreshRate=120.00 Hz, dpi=642.42x641.68, group=0}
Edit the service.sh file inside the Magisk module zip
Code:
service call SurfaceFlinger 1035 i32 3
At this line, replace the number at the end with the id number you grabbed from the earlier adb commands
Click to expand...
Click to collapse
Was about to do a Module. Thanks for sharing the Details!
OhayouBaka said:
Figured out a more elegant method that doesn't corrupt the boot animation and should work on any future firmware updates. Simply flash this Magisk Module, which contains the commands that @Miustone provided. Yes, this does still require a bootloader unlock as you are only able to apply this command with root privileges or a Magisk script.
You should also be able to use this on other devices as well running Android 12 or newer, by following these steps to edit the Magisk module .zip provided:
Just run:
Code:
adb shell
Code:
dumpsys SurfaceFlinger | grep hwcId
Pick your id number according to resolution/refresh rate you desire from the list.
Here is an example output from Xperia 1 IV:
Code:
{id=0, hwcId=0, resolution=1096x2560, refreshRate=60.00 Hz, dpi=428.28x427.79, group=0}
{id=1, hwcId=1, resolution=1096x2560, refreshRate=120.00 Hz, dpi=428.28x427.79, group=0}
{id=2, hwcId=2, resolution=1644x3840, refreshRate=60.00 Hz, dpi=642.42x641.68, group=0}
{id=3, hwcId=3, resolution=1644x3840, refreshRate=120.00 Hz, dpi=642.42x641.68, group=0}
Edit the service.sh file inside the Magisk module zip
Code:
service call SurfaceFlinger 1035 i32 3
At this line, replace the number at the end with the id number you grabbed from the earlier adb commands
Click to expand...
Click to collapse
Thanks for this also I just found out you can add the script to fkm so you can easily switch between all resolution
Edit: Actually I think you can only run 2 res at a time 4k @120/60 or 1080 @120/60
Miustone said:
No Bootloader unlock needed. Still.
service call SurfaceFlinger 1035 i32 x
(x=0,1,2,3)
1. 1096x2560x60x397132cmd
2. 1644x3840x120x397108cmd
3. 1644x3840x60x397108cmd
4. 1096x2560x120x397132cmd
Google changed the behavior for native Resolution switches in the Android Settings. Just like Samsung has it since YEARS. Thanks for the alternative tho
Click to expand...
Click to collapse
OhayouBaka said:
Figured out a more elegant method that doesn't corrupt the boot animation and should work on any future firmware updates. Simply flash this Magisk Module, which contains the commands that @Miustone provided. Yes, this does still require a bootloader unlock as you are only able to apply this command with root privileges or a Magisk script.
You should also be able to use this on other devices as well running Android 12 or newer, by following these steps to edit the Magisk module .zip provided:
Just run:
Code:
adb shell
Code:
dumpsys SurfaceFlinger | grep hwcId
Pick your id number according to resolution/refresh rate you desire from the list.
Here is an example output from Xperia 1 IV:
Code:
{id=0, hwcId=0, resolution=1096x2560, refreshRate=60.00 Hz, dpi=428.28x427.79, group=0}
{id=1, hwcId=1, resolution=1096x2560, refreshRate=120.00 Hz, dpi=428.28x427.79, group=0}
{id=2, hwcId=2, resolution=1644x3840, refreshRate=60.00 Hz, dpi=642.42x641.68, group=0}
{id=3, hwcId=3, resolution=1644x3840, refreshRate=120.00 Hz, dpi=642.42x641.68, group=0}
Edit the service.sh file inside the Magisk module zip
Code:
service call SurfaceFlinger 1035 i32 3
At this line, replace the number at the end with the id number you grabbed from the earlier adb commands
Click to expand...
Click to collapse
raven213 said:
Thanks for this also I just found out you can add the script to fkm so you can easily switch between all resolution
Edit: Actually I think you can only run 2 res at a time 4k @120/60 or 1080 @120/60
Click to expand...
Click to collapse
nice, thanks for the information. Much appreciated!
Wasn´t aware of this command or this way to set the ID.
One thing I noticed. This way basically breaks refresh rate switching though. E.G. if a different FPS is set for any app via game enhancer that will break for some reason.
I use this little trick to set 60hz mode for video apps for example as colours and gamma are way better on 60fps, and it´s unnecessary to drive the phone at 120hz during 60fps videos.
Had a small hope this would circumvent the upscaled 2k content despite running 4k panel mode, but it´s still the same.
Is it available on xperia1iii?
1219545479 said:
Is it available on xperia1iii?
Click to expand...
Click to collapse
Check Sony xda TG I think someone created a zip file for the III
First thanks for this mod. But 4k 120hz is sooooo hot although my room's temp is 9°C .... Fxxk 8gen1 that's why I want to buy s23ultra
1219545479 said:
Is it available on xperia1iii?
Click to expand...
Click to collapse
Yeah see here.... 2nd post by me.....
High Resolution & High Refresh Guide for Xperia 1 III
Welcome! Short and painless for You No Root needed Download the Android Platform Tools from Google Extract the Folder Containing adb & fastboot open a Terminal in the extracted Folder run one by one: adb shell service call SurfaceFlinger 1035...
forum.xda-developers.com
updated for firmware 64.1.A.0.869
It's so awesome that this mod exists and I don't even have the phone! Thank you for this mod. I really do hope more people discover this, as I'm sure many Xperia 1 users would want it.

Categories

Resources