Database Develop

[WIP][2016.01.21] Android 6.0 Marshmallow [CLOSED]

All discussion should go the SuperSU BETA thread
Attached find modified boot.img for the Nexus firmwares released so far. Together with SuperSU v2.50+ these allow root with SELinux in Enforcing mode.
These are the stock boot images from Google, with the ramdisk modified as follows:
- patched sepolicy
- disabled dmverity (if applicable)
- disabled forceencrypt (if applicable)
Rooting procedure:
- flash/upgrade to Marshmellow
- flash modified boot.img
- flash/boot TWRP and sideload latest v2.50+
Acquiring root without modifying the boot images is still under investigation. Please note that the current method will not be officially supported. Future roots may require a clean system: we are at a very early stage of root for 6.0, methods used are subject to change.
For the modders, you can do the sepolicy modifications yourself as follows:
- root a reference device (4.4+ with SELinux enabled) with v2.50+
- extract the sepolicy file from the target boot image's ramdisk
- with the reference device connected to ADB:
Code:
adb push sepolicy /data/local/tmp/sepolicy
adb shell su -c "supolicy --file /data/local/tmp/sepolicy /data/local/tmp/sepolicy_out"
adb shell su -c "chmod 0644 /data/local/tmp/sepolicy_out"
adb pull /data/local/tmp/sepolicy_out sepolicy_out
- replace the sepolicy file in the boot image's ramdisk with the sepolicy_out file
- profit
(this trick should also work on the Samsung 5.1.1 kernels that people are having issues with lately)
Fugu requires v2.51+

EXPERIMENT: Root without modifying /system
EXPERIMENTAL, ARE YOU SURE YOU WANT THIS ?
All discussion should go the SuperSU BETA thread
Idea
To have root on modern Android versions, we need our files to be executable and our daemon to be started on boot. We normally do this by making modifications to /system, tapping into binaries and scripts executed by init. If we're also modifying the boot image, then we should be able to do all this without modifying system at all. A benefit of this is that it makes OTAs easier - reflashing the boot image is less hassle than reflashing system.
As the binaries should still be updatable, and we don't know the space we have available in the boot image itself, we're mounting a (writable) ext4 image with /su as mount point from /data, and modifying PATH accordingly. Interestingly, for reasons yet unknown to me, if the image is mounted r/o by init, later remounting it r/w causes a bunch of issues. So we're keeping it r/w (for root) for now.
An overlayfs/unionfs solution would be even more ideal, transparently placing files in /system without modifying the actual partition, but I have not been able to find one that is (a) compatible with all Android architectures and (b) not kernel dependent and (c) not GPL - or even just one of those requirements, really. It's technically all possible, it just needs to be done.
Caveats
- Apps with hardcoded paths to su (seriously?) will bork
- Factory reset unroots
- Factory reset wipes pin
- ...
- Bugs... Bugs everywhere!
Instructions
You must absolutely re-flash your stock /system partition, or the separate root instances will interfere with eachother. The installer for this experiment will not clean up old root files.
- Flash stock /system (and /vendor and /oem, if present)
- Flash the attached boot image
- Flash the attached SuperSU ZIP in TWRP
Ramdisk modifications
- include (post above this one)
- init.rc (devs: please open file for reference)
--- on init
------ mkdir /su ...
--- on post-fs-data
------ copy image from cache to data (for rooting without access to /data in custom recovery)
------ mount image to /su
--- service daemonsu
- init.environ.rc
--- export PATH, prepended with /su/bin
- file_contexts
--- /su(/.*)? ubject_r:system_file:s0
NOTE
- Not all SuperSU options are supported yet in this mode
- I have not tested with encrypted devices
- /system should never be remounted r/w, I hope I didn't miss anything here
- Root with modifying /system is also still operational. I can't predict what the exploiters will need.
- I'm not sure where we're going with this. Future roots may require a clean system.
BETA-SuperSU-v2.56-20151030013730.zip

Changes
(The changelogs for the specific SuperSU versions can be found here: http://forum.xda-developers.com/showpost.php?p=23427824&postcount=3)
2016.01.21
- v2.67 ZIP
2016.01.03
- v2.66 ZIP
2015.12.26
- v2.65 ZIP
2015.12.20
- v2.64 ZIP
2015.12.11
- v2.62-3 ZIP:
--- (systemless) ZIP: Fix calling wrong script name for custom patcher script
--- (systemless) ZIP: Improve APK overwrite
--- (systemless) ZIP: Do not move backups from /cache to /data, just copy them
(there are no changes to SuperSU itself compared to v2.62, just minor script changes in the ZIP)
2015.12.10
- v2.62 ZIP
2015.12.07
- v2.61 ZIP
2015.12.05
- v2.60 ZIP with automated boot image patcher
2015.10.30 #2
- Added systemless root experiment for other Nexus than hammerhead
2015.10.30
- Added systemless root experiment for hammerhead
2015.10.28
- Added Angler kernel
- Added Razor mra58u kernel
2015.10.20
- Added Bullhead kernel
2015.10.08
- New image for Fugu, requires v2.51
2015.10.07
- New images, should fix the factory reset issues some users with encrypted data were seeing

EXPERIMENT: Root without modifying /system #2: Automation
EXPERIMENTAL, ARE YOU SURE YOU WANT THIS ?
All discussion should go the SuperSU BETA thread
Continuing on the previous post, here is SuperSU v2.62 BETA, with automated boot image patching. It's been tested by myself on various Samsung's running anything from 4.3 to 5.1, and all of the recent Nexus devices on 6.0. Even on CM13. Other users have tested it with success on various other devices.
If you are coming from any SuperSU install in /system, you must re-flash the stock system (and vendor and oem, if present) partition contents prior to installing this.
If you are coming from a SuperSU 2.56 system-less install, you must re-flash the stock boot image prior to installing this.
If you are coming from a SuperSU 2.60 system-less install, or were not rooted at all, then you can just flash the ZIP without any special prior instructions.
If TWRP offers you to keep /system read-only, indeed keep it read-only.
If TWRP tells you SuperSU is not installed, and asks you to install it, do not do it, you will break things!
If on Android 6.0 or Samsung 5.1, the ZIP installer will install SuperSU in systemless mode and patch the boot image. The boot image patcher currently only supports gzip compressed ramdisks and the standard Android boot image format. Some devices do not use the standard format, and many custom kernels use a compression other than gzip. A backup is made (/data/stock_boot_<sha>.img.gz) of the original boot image before patching it.
Further implementation details (including an updated list of changes to the ramdisk) are explained in the installer script itself, as usual.
Notes on 2.62+
A poor man's overlay is used on /system/xbin. We are creating a copy of /system/xbin in /su/xbin_bind, adding a symlink to /su/bin/su there, then mounting the entire thing on top of the original /system/xbin. This is likely to fix some compatibility issues with some apps, without actually modifying /system. Removing /su/xbin_bind and rebooting will disable this feature, or "echo BINDSYSTEMXBIN=false>>/data/.supersu" in recovery root shell before a SuperSU ZIP flash.
If you have one of those devices that refuse to remount system r/w in Android such as the Nexus 6P, but you do want to do this, "echo FSTABSYSTEMRW=true>>/data/.supersu" in recovery root shell before a SuperSU ZIP flash will patch the boot image in such a way that remounting will work. This feature itself breaks OTA compatibility, regardless of if you end up writing to /system or not.
Both of these features are likely temporary.
Notes on 2.64+
There have been a lot of changes to the ZIP installer. Hopefully they won't break a lot of installs. If 2.64 works well, it is likely to be promoted to the "main beta" in place of 2.52, and the How-To SU document will be updated with the relevant information.
A major change in setup is that the ZIP installer will try to detect 6.0 firmwares that can be rooted without doing a systemless install. In other words, a root that modifies only /system, but not the boot image. If this is possible, the installer will install into /system (unless you override via "echo SYSTEMLESS=true>>/data/.supersu").
This may catch (a) firmwares that allow sepolicy reloading from /data but have a locked bootloader and (b) custom firmwares setup to handle this. Regarding the latter, while it is not as clean as systemless, those running custom firmwares are more likely to want to modify /system anyway, it is less likely to mess with updates to those firmwares, and it prevents the necessity of reflashing the ZIP after each kernel switch. Of course, the kernel's SELinux policies must support this! See this thread for details for devs.
Notes on 2.65+
As 2.65 adds /su/xbin, I recommend flashing the ZIP rather than installing the APK from the ZIP, as some people tend to do.
Notes on 2.67+
I recommend flashing the ZIP rather than installing the APK from the ZIP, as some people tend to do.
Downloads
BETA-SuperSU-v2.60-20151205163135.zip
BETA-SuperSU-v2.61-20151207213702.zip
BETA-SuperSU-v2.62-20151210170034.zip
BETA-SuperSU-v2.62-2-20151211155442.zip
BETA-SuperSU-v2.62-3-20151211162651.zip
BETA-SuperSU-v2.64-20151220185127.zip
BETA-SuperSU-v2.65-20151226141550.zip
BETA-SuperSU-v2.66-20160103015024.zip
BETA-SuperSU-v2.67-20160121175247.zip

The latest WIP version has become the main BETA version.
For all intents and purposes, this thread is closed. It will be cleaned up and unstickied in good time.

How-To Modify boot.img for DualBoot Patcher (Android 9)

One of the things I missed most since moving to Oreo and Pie on the Note 4 has been trying out the new ROMs without having to mess with my daily driver setup. After a ton of research and some training on building ROMs from source, I was finally able to make Android Pie boot from any slot on Dualboot patcher. *
What you need?
* An Android Pie ROM
* Android Image Kitchen (AIK)
* modified device tree binary (dtb)
* a text editor
* RAR or some other zip file manager.
Instructions
1) Download and extract AIK from https://forum.xda-developers.com/showthread.php?t=2073775
2) extract the boot.IMG from your ROM to the same folder where you extracted AIK.
3) unpack the boot image using the unpackimg.sh script. This will create a split_img folder and a ramdisk folder.
4) go to the split_img folder and delete boot.img_dt (or boot.img_dtb depending on which version of AIK you are using).
5) copy the attached dtb.img file to the split_img folder and rename it to the original file name (boot.img_dt or boot.img_dtb)
6) go to the ramdisk folder and edit fstab.qcom. change this line:
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1 wait,recoveryonly
To this:
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1,discard wait
7) still in the ramdisk folder, modify init.qcom.rc. change this line **:
mount_all fstab.qcom
To this:
mount_all /fstab.qcom
8) go back to the AIK folder and run repacking.sh. this will create a file called image_new.img.
9) rename image_new.img to boot.img
10) replace the boot.img in your ROM zip file with the new one you just created.
Now you can use DualBoot Patcher to patch the ROM file for any slot and flash the patched file.
Just a few extra notes here:
* I only built these images for Android Pie for Snapdragon Note 4 devices. Make sure you use the the correct file for your device.
** in step 7, I noticed that some ROMs have an earlymount flag. You must delete that flag, otherwise the phone reboots to download mode.
***If anyone has any ideas to make this a flashable process, let me know. I would push these change upstream, but I don't know know enough about Git to do that. And, I don't know if the other devs want these changes.

Ok, so that was the manual way, but these changes can also be added to the kernel and boot image files at the time you build your ROM. Here is where you make the changes:
In the kernel, go to the dts sources. The file to modify is this one:
kernel/samsung/apq8084/arch/arm/boot/dts/qcom/aps8084.dtsi
Find this section and delete it:
Code:
system {
compatible = "android,system";
dev = "/dev/block/platform/msm_sdcc.1/by-name/system";
type = "ext4";
mnt_flags = "ro,barrier=1,discard";
fsmgr_flags = "wait";
status = "ok";
};
In the boot image, there are 2 files to modify.
1) device/samsung/trlte-common/rootdir/etc/fstab.qcom
Change this line:
Code:
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1 wait,recoveryonly
to this:
Code:
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1,discard wait
2) device/samsung/trlte-common/rootdir/etc/init.qcom.rc
Change this line:
Code:
mount_all fstab.qcom
to this:
Code:
mount_all /fstab.qcom
That's it. Build the ROM and it will be compatible with DualBoot Patcher. Since those are common files across the TRLTE, TBLTE and DUOS devices, all of those builds will be compatible with dualboot patcher.

So, one more thing. There are limitations to what you can install with DualBoot Patcher. Most things are easy to get around, though.
1) Flashable zip's that use Aroma installer might not change their behavior after being patched, and might install to your primary ROM slot anyway. Just something to be aware of.
2) Any flashable zip that has a custom script for updater-binary will fail to flash after being patched. For example, all the MicroG installers that I know of use custom scripts instead of the real updater-binary.
3) you cannot install a patched Magisk zip. But, you can install the Magisk Manager in your ROM, tap the install button (and the next install button that shows up), choose "Select and Patch a file", then choose the boot image from the Multiboot folder on your internal storage (/sdcard). It will patch the boot image and leave a file called "magisk_patched.img" in your Download folder on the internal storage (/sdcard). Use TWRP to flash this file to your boot partition, then reboot. Open DualBoot Patcher, tap the 3-dot button next to the ROM name, and tap "Set Kernel" to replace the saved boot image with the Magisk patched boot image. Note: if you accidentally
4) Magisk doesn't do much. You can use it to grant superuser permissions, but modules only work on the primary ROM.
5) custom kernels probably include their own dtb files. Flashpoint is an example of this. You may have to update the zip to remove the existing dtb file and add one of the files attached to OP. Make sure you rename it to match the original name in the zip file.

I set up my primary ROM per the above instructions, installed it, and I am trying to get my secondary rom installed. Do I need to set it up the same way (it is a 7.1.2 rom). When I patch it (7.1.2) through Dual Boot and try to flash it I get the following error.... " Failed to create temporary image /raw/data/.system.img.tmp" and it fails to flash. I've tried setting it both as secondary and in slot 1.... Any help would be appreciated... Hopefully I am just missing something simple.

rickpub said:
I set up my primary ROM per the above instructions, installed it, and I am trying to get my secondary rom installed. Do I need to set it up the same way (it is a 7.1.2 rom). When I patch it (7.1.2) through Dual Boot and try to flash it I get the following error.... " Failed to create temporary image /raw/data/.system.img.tmp" and it fails to flash. I've tried setting it both as secondary and in slot 1.... Any help would be appreciated... Hopefully I am just missing something simple.
Click to expand...
Click to collapse
What Rom are you trying to flash? Do you have enough space available on system or cache to flash that Rom? If not, try patching it for a data slot instead.

thanks
why when i do this the rom that have modified wont turn wifi on ?
n910f
i try it on linageos pie and havocos 2.8 and both have same issue after doing this solution

samdakid said:
thanks
why when i do this the rom that have modified wont turn wifi on ?
n910f
i try it on linageos pie and havocos 2.8 and both have same issue after doing this solution
Click to expand...
Click to collapse
That's really odd. Maybe I need to update the dtb images here. I will try to do that this weekend.

Would love to try this out

propose: added option to skip check `patched boot image`

Hi mina-san,
I have a Huawei D-02H but for it to work on Android 6 i need to edit boot.img file as Huawei M2-802L so I'm pretty sure it won't affect Magisk's boot.img patch.
Can you add an option like --force to force patch boot.img?
Thanks for read!

Building/Flashing custom kernel to SM-G780F(Exynos) help

Obligatory first post on the forums here so hopefully this is the right place!
I have been lurking on the forums for the past month or so and have been working on building a custom kernel from source for the SM-G780F/DSC(Exynos) edition. I've built some kernels from source before so I have some experience there, but actually getting the kernel to flash and run on the device is a different story. I have built the kernel with the modifications that I wanted, fixed some flashing issues I was running into, finally got the boot.img to flash succefully to the device, rebooted the device and the phone just hangs at the Samsung logo. (See "Image from iOS.png").
Here is the steps that I did:
Unlock Bootloader on the device.USB Debugging on, OEM Unlocking enabled in dev settings/ OEM Lock: OFF(U) in DL mode.
Checked to make sure KG State is not Prenormal, it is in checking state.
Device is currently running stock G780FXXS7CUI5, so I download this version source from https://opensource.samsung.com/uploadSearch?searchValue=SM-G780F
Extract Kernel.tar.gz, update toolchain paths in the Makefile/build_kernel.sh, and I make some modifications to the defconfig file.
Code:
./build_kernel.sh
; Fix compiler errors/warnings as they appear. Rinse and repeat until the kernel is built.
Now that the kernel is built I pull the stock ROM that this device is currently running from Sammobile. https://www.sammobile.com/samsung/g.../SM-G780F/MID/download/G780FXXS7CUI5/1583411/
Extract the AP directory from the Sammobile ROM download.
Extract the boot.img.lz4 from the AP directory so I now have the uncompressed boot.img.
Copy over the the stock boot.img to my AIK directory. (AIK-Kinux-V3.8)
Code:
./unpackimg.sh boot.img
, cd into split_img, rm the stock boot.img-kernel
Move my custom kernel image to the AIK directory,
Code:
mv kernel_source/out/arch/arm64/boot/Image /AIK-Linux/split_img/boot.img-kernel
Run AIK repackimage.sh
Now I have a SM-G780G(Snapdragon edition) S20_FE with Magisk installed. So I copy over my image-new.img to this device and patch the image-new.img with Magisk
Move back the patched image to my linux enviroment. Rename my patched image boot.img.
Compress my boot img with
Code:
lz4 -B6 --content-size boot.img boot.img.lz4
.
Replace the stock boot.img.lz4 in my AP directory with my modded boot.img.lz4
Pull down a clean vbmeta.img from https://dl.google.com/developers/android/qt/images/gsi/vbmeta.img
Compress this image as well
Code:
lz4 -B6 --content-size vbmeta.img vbmeta.img.lz4
Replace the stock vbmeta.img.lz4 in the AP directory with my clean vbmeta.img.lz4 in the
So the contents of the AP directory currently is
Code:
22556009 Apr 7 12:57 boot.img.lz4
1155 Sep 23 2021 dqmdbg.img.lz4
219753 Sep 23 2021 dtbo.img.lz4
4096 Sep 23 2021 meta-data
1148 Sep 23 2021 metadata.img.lz4
2773 Sep 23 2021 misc.bin.lz4
35115127 Sep 23 2021 recovery.img.lz4
5457239441 Sep 23 2021 super.img.lz4
822394050 Sep 23 2021 userdata.img.lz4
2375 Apr 7 12:57 vbmeta.img.lz4
2812 Sep 23 2021 vbmeta_samsung.img.lz4
tarball all these files with
Code:
tar -cvf Modded_AP.tar *
Spin up latest version of ODIN
Place Custom AP into AP slot, Stock BL into BL slot, Stock CP into CP slot, and Stock HOME_CSC into CSC slot
Start Flashing.
Flashing is successful.
Device reboots, and hangs at the Samsung Galaxy S20FE Screen with the warning "I am not running samsungs official software."
A couple of questions I am asking myself is the stock vbmeta_samsung.img.lz4 necessary, as well as some of the other stock files? Is patching my boot.img with Magisk running on a different
device giving me issues? Am i missing a step somewhere or is there still extra steps I need to take to get a modded kernel running on this device. Any help would be greatly appreciated or if I need to provide any more insight please let me know! Thanks again!

you'd be extremely welcome in our little group
S20 FE Modding
Exynos AOSP: https://t.me/S20FE_Exy TurboUI: https://t.me/projectxs20fe Prime Kernel Snap: https:/t.mes20fesnapdragon Prime Kernel Exynos: https://t.me+vpzEK9kPMc41MmY9 Bandido Kernel https://t.me/bandidokernel Klimbo Kernel https://t.me/klimbokernel
t.me
there's also a kernel dev there from time to time who has built kernels for all versions FE completely blind, i.e. without being able to flash them himself. maybe we can get you two talking.

it sounds like you've added two kernels to your AP archive. as I understand it once you've built your kernel, compressed it to .lz4 you can just archive it inside a tar file and flash that alone (as long as it matches your firmware).

Hi there Buddy, so answering your questions- we dont need vbmeta everytime, we only use it once to flash twrp after which flashing vbmeta not necessary. Now yes patching boot.img with other device other than the one you are running causes problems here and device doesnt like to boot. As per the last kernel dev he just used our stock boot.img and compiled his changes. And we flash hi kernel like normal flash.
S20 FE Modding
Exynos AOSP: https://t.me/S20FE_Exy TurboUI: https://t.me/projectxs20fe Prime Kernel Snap: https:/t.mes20fesnapdragon Prime Kernel Exynos: https://t.me+vpzEK9kPMc41MmY9 Bandido Kernel https://t.me/bandidokernel Klimbo Kernel https://t.me/klimbokernel
t.me
You can even join this group, there are many people willing to help others.

Also i have been developing stock based roms for all the variants, so would be happy to test them once they get stable enough to boot.

Thanks for the responses everyone! I'll take my follow up questions to the group!

Hi. There are some kernel changes that is needed to be applied in order to successfully boot the custom kernel. I suggest you post the kernel source so I can review it. You don't need to place everything inside the AP. You can just archive the boot.img.lz4 as tar.
Also, a lot of your steps can be simplified by making a twrp-flashable zip instead. You can use my template here:
android_kernel_samsung_s20fe/AnyKernel3 at exynos · pascua28/android_kernel_samsung_s20fe
Custom kernel for Samsung S20 FE (Snapdragon and Exynos variants) - android_kernel_samsung_s20fe/AnyKernel3 at exynos · pascua28/android_kernel_samsung_s20fe
github.com
Just move the arch/arm64/boot/Image as zImage and you can zip the AnyKernel3 folder and there you have a twrp-flashable zip. It's a lot more convenient this way as people do not need to carry around their computers whenever they need to flash custom stuffs plus, it's more universal this way as they don't have to have a matching firmware version; it will just use the existing boot image, unpack it, replace the kernel, repack and then flash it back to the device.
If you have any questions, feel free to contact me on telegram (pascua14). I hope you succeed
Regards

Question How to edit hosts file without Magisk?

I'm using phhusson GSI rom (https://github.com/phhusson/treble_experimentations/releases) and since I'm failing to install Magisk (because there's no boot.img to patch), I wonder if there's a way to edit /system/etc/hosts file in a way that it persists (or is automatically restored) after a reboot.
Thanks!