Database Info

How to install GSI ROMs and pass SafetyNet on them

For those who use any official MIUI release (be it Global or Chinese, Stable or Dev):
Download your GSI of preference from Treble-compatible Devices Development section of XDA to your PC. Make sure you download an ARM64 A-only version.
In TWRP on your phone, hit Wipe and then Format Data and confirm it with typing „yes”
Connect your phone in fastboot mode to your PC
Open the command prompt in the folder where your fastboot.exe is located
Type: fastboot flash system path_to_your_GSI.img (Tip: you can also type fastboot flash system and drag and drop it on the command prompt window)
Type: fastboot reboot
The device should reboot to your freshly installed GSI.
For those who use xiaomi.eu ROM: (YMMV, it worked for me so I put it here, see below if it doesn't work for you)
Download your GSI of preference from Treble-compatible Devices Development section of XDA to your PC. Make sure you download an ARM64 A-only version.
Download vendor.img from here to your PC. You can also use any official vendor.img provided in official Xiaomi fastboot firmware packages if you know what you’re doing.
In TWRP on your phone, hit Wipe and then Format Data and confirm it with typing „yes”
Connect your phone in fastboot mode to your PC
Open the command prompt in the folder where your fastboot.exe is located
Type: fastboot flash system path_to_your_GSI.img (Tip: you can also type fastboot flash system and drag and drop it on the command prompt window)
Type: fastboot flash vendor path_to_your_vendor.img (you can drag and drop as well)
Type: fastboot reboot
Alternate, easier (and preferred) way:
Download and flash any official MIUI release like this one here
Follow instructions for official MIUI releases above
The device should reboot to your freshly installed GSI.
How to pass SafetyNet on GSI:
Download the latest Magisk 16.6 and flash it through TWRP
Reboot
In Magisk Manager app, open the side menu and tap Download
Download MagiskHide Props Config, install it and reboot
After reboot, go to Setting and Developer Options and enable Terminal app, right under ADB debugging option
A Terminal app should appear in your apps list. If not, you can also use any terminal emulator app from Play Store
Type „su”, hit enter and grant root permissions
Type „props” and hit enter
Type „1”, hit enter
Type „f”, hit enter
Type „11”, hit enter
Type „7”, hit enter
Type „y”, hit enter
Type „y”, hit enter and your device will reboot
If you care about auto-brightness (which i bet you do), you can also set the module manually to Mi MIX 2S fingerprint:
Follow steps 1-9 from above
Type:
Code:
Xiaomi/polaris/polaris:8.0.0/OPR1.170623.032/V9.5.19.0.ODGMIFA:user/release-keys
and hit enter (thanks @cnrd for the tip!)
Type "y", hit enter
Type "y", hit enter and your device will reboot
After booting successfully, your device will pass SafetyNet, you can check it in Magisk Manager. Tested on my Chinese (XE model) device with the latest Resurrection Remix official GSI, Google Pay is working fine.

Using the Mi 6 ctsProfile kills the background light (at least on phh-treble), use the Mi Mix 2S profile instead:
Code:
Xiaomi/polaris/polaris:8.0.0/OPR1.170623.032/V9.5.19.0.ODGMIFA:user/release-keys

cnrd said:
Using the Mi 6 ctsProfile kills the background light (at least on phh-treble), use the Mi Mix 2S profile instead:
Code:
Xiaomi/polaris/polaris:8.0.0/OPR1.170623.032/V9.5.19.0.ODGMIFA:user/release-keys
Click to expand...
Click to collapse
Added, thanks!

Great tutorial, thank you very much!
Has anyone tried this with the latest pixel experience gsi? Resurrection Remix is running fine but pixel experience always reboots to the fastboot screen.
I used the instructions from the pixel experience thread, but without success. I read the whole thread again and again and did it step by step as mentioned to be sure not to miss any important steps. Not luck.
Can you try it with the Mix2S and confirm that it works and how you it?
Don't want to capture this thread. I'm just desperately trying to get this done to boot.
Best regards
Kleinholzinferno

Thanks for the explain.
Is the OP using this method on a different device? I don't recall seeing any ROMs for the Mix 2S.

napes22 said:
Thanks for the explain.
Is the OP using this method on a different device? I don't recall seeing any ROMs for the Mix 2S.
Click to expand...
Click to collapse
OP is using a Treble ROM. If you go to the Treble section of XDA, there's a bunch of ROMs that will work for the 2s. Instead of flashing a device specific zip file you can flash a generic image file that will work on any phone that supports treble, like the Mi Mix 2s.
This guide walks you through flashing those images, and getting Magisk to work on the 2s.

russphil said:
OP is using a Treble ROM. If you go to the Treble section of XDA, there's a bunch of ROMs that will work for the 2s. Instead of flashing a device specific zip file you can flash a generic image file that will work on any phone that supports treble, like the Mi Mix 2s.
This guide walks you through flashing those images, and getting Magisk to work on the 2s.
Click to expand...
Click to collapse
Thanks, although I had upgraded the Beta to 8.7.10, so probably won't be flashing anything until a workaround comes along. I'm waiting for someone to confirm if it's only for Redmi Note 5.

Thank you for the tutorial, maybe you could add the fact that you have to use the fastboot.exe from miflash.
I´ve used the Minimal ADB and Fastboot Files but they make write Errors and the Rom won´t boot.

Hope I could try this method on my Mi 6X, will report back once I can unlock my Bootloader.

marcii-ec said:
Thank you for the tutorial, maybe you could add the fact that you have to use the fastboot.exe from miflash.
I´ve used the Minimal ADB and Fastboot Files but they make write Errors and the Rom won´t boot.
Click to expand...
Click to collapse
I've done it through Minimal ADB and Fastboot on Windows and through Fastboot on macOS and both work fine.

napes22 said:
Thanks, although I had upgraded the Beta to 8.7.10, so probably won't be flashing anything until a workaround comes along. I'm waiting for someone to confirm if it's only for Redmi Note 5.
Click to expand...
Click to collapse
You can check it if you reboot to Fastboot and see if "fastboot getvar anti" returns anything. If it does, your device has anti-rollback protection enabled.
As far as I know, anti-rollback is enabled on MIX 2S from 8.7.16 onwards, so you should be safe.

woofwoof75 said:
Hope I could try this method on my Mi 6X, will report back once I can unlock my Bootloader.
Click to expand...
Click to collapse
If your device is Treble-compatible, it should work with no problems, however keep in mind that should you run into any issues when using the provided fingerprint, you have to look up some from a stable MIUI for your device.

teddy74eva said:
You can check it if you reboot to Fastboot and see if "fastboot getvar anti" returns anything. If it does, your device has anti-rollback protection enabled.
As far as I know, anti-rollback is enabled on MIX 2S from 8.7.16 onwards, so you should be safe.
Click to expand...
Click to collapse
Yeah, when I run "fastboot getvar anti" I get invalid variable. Which leads me to believe that I don't have any issues at the moment. I won't upgrade from 12, but I'd like to move to Treble at some point.
EDIT: Just checked the "flash_all.bat" file within the 8.7.12 file and saw the following
::set CURRENT_ANTI_VER=1
::for /f "tokens=2 delims=: " %%i in ('fastboot %* getvar anti 2^>^&1 ^| findstr /r /c:"anti:"') do (set version=%%i)
::if [%version%] EQU [] set version=0
::if %version% GTR %CURRENT_ANTI_VER% (
Click to expand...
Click to collapse
Looks like 8.7.12 for Mi Mix 2S is not screwed.

Hello fellow gsi users. I'm new to this props editing thing and wanted to ask two questions for noobs.
If I follow the terminal commands in the OP the device fingerprint shows Xiaomi Mi 6 8.0.0 right? Is this right to use for the MiMix2S? I think so otherwise it wouldn't be mentioned to use.
And i don't understand the command for the auto brightness. What exactly does this do? Enable the automatic brightness settings from the original rom?
Need advice please. Maybe there's a thread that I haven't found yet that explains this topic. I'm eager to get more information but all I found was too general and not the answers I was looking for.

kleinholzinferno said:
Hello fellow gsi users. I'm new to this props editing thing and wanted to ask two questions for noobs.
If I follow the terminal commands in the OP the device fingerprint shows Xiaomi Mi 6 8.0.0 right? Is this right to use for the MiMix2S? I think so otherwise it wouldn't be mentioned to use.
And i don't understand the command for the auto brightness. What exactly does this do? Enable the automatic brightness settings from the original rom?
Need advice please. Maybe there's a thread that I haven't found yet that explains this topic. I'm eager to get more information but all I found was too general and not the answers I was looking for.
Click to expand...
Click to collapse
Basically, setting your fingerprint to Mi6 8.0 fools Google's checks of your installed system's certification, telling them that you are currently running a certified and tested Mi6 firmware. Every firmware has to follow Google's standards and rules for it to be able to fully use Google Services.
Now, I've included Mi6 fingerprint in my guide because it's readily available in MagiskHide Props, thus making it easier to set everything up to a workable state. However, as one user mentioned, if you use Mi6 fingerprint on MIX 2S, it breaks autobrightness. So, in order to be fully certified and keep autobrightness working, you can manually enter a fingerprint provided in the first post, which comes from MIX 2S 8.0 firmware. The only downside is that you have to be careful not to make any mistake when typing, so it's a little bit harder.
If you can live without autobrightness (since, as of now, it's terribly slow), feel free to use the Mi6 preset fingerprint. If you care or if you want to do things as they should be done, go for the manual route. Both of them will make your device Google certified and both of them will allow you to pass SafetyNet checks.
I may generalized some things or not mention them due to my lack of knowledge. If anybody would like to correct something, please do so
P.S. I may completely delete the preset fingerprint guide, as I don't think it's that hard to enter the proper fingerprint manually and it would definitely make things clearer.

Thank you very much for this information, makes everything much clearer for me.
Regarding auto brightness: I don't mind if it works for now, I can live with the manual settings. Better than a laggy auto settings thingy that doesn't worm properly.
The only thing that bothers me is that the screen is much too bright at night (or with night light activated) even in the lowest setting. Is there any possibility to change the minimum value?
Could you explain how to enter the proper fingerprint manually?
Best regards
Edit: nevermind the last question, I found it. In the newer version there's an entry for the mi mix 2s. Xiaomi devices are now listed under number 12, not 11 and the mi mix 2s is listed as own device. Works perfectly fine! Safety net passed, all green now!

Amazing Temp Root for MediaTek ARMv8 [2020-08-24]

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Software root method for MediaTek MT67xx, MT816x, and MT817x!​
So it's no big secret that not too long ago, I found a way to achieve temporary root on MediaTek chipsets. No preinstalled root solution or device unlock was needed. The tool I created, MTK-SU, was originally aimed at helping Amazon Fire HD owners to easily root and unlock their tablets. (Without it, most models need a hardware mod to achieve root & unlock. This tool made rooting accessible to many times the number of owners. It also made possible to root the Fire TV gen 2.) But funny story: this method actually works on virtually all of MediaTek's 64-bit chips. Many devices of various vendors have already been confirmed.
So in case it's not clear, what mtk-su does is give you a root shell to do with as you please. It's like running 'su', but without the need to have su installed. That may be a holy grail for locked devices. On some devices, it may be possible to install a root manager for permanent root using mtk-su as a springboard.
The original thread is here: Rapid Temporary Root for HD 8 & HD 10. It's a great resource for info. But please avoid posting there about non-Amazon devices. This new thread is a catchall topic for other devices and vendors.
DISCLAIMER​Anything you do that is described in this thread is at your own risk. No one else is responsible for any data loss, corruption or damage of your device, including that which results from bugs in this software. There is a nonzero chance of any of these events happening as a result of using the tools or methods here.
REQUIREMENTS​Mastery of the Thanks button under XDA posts
A phone or tablet based on Mediatek MT67xx, MT816x, MT817x or MT6580 chipsets
Either:
A PC with ADB installed to interact with your device, or
A terminal emulator app
Familiarity with ADB (if using PC) and basic Linux shell commands
You agree to post the model name of any unconfirmed device which ran mtk-su successfully
INSTRUCTIONS FOR ADB​
Make sure you meet all the requirements listed above, especially the first and last ones.
Download the current mtk-su zip file to your PC and unzip it. Inside will be 2 directories: 'arm' & 'arm64' with an 'mtk-su' binary in each. Pick one for your device. Differences between the flavors:
arm64: 64-bit kernel and userspace
arm: 32-bit userspace on a 64-bit or 32-bit kernel (will also work in 64-bit userspace)
Connect your device to ADB and push mtk-su to your /data/local/tmp folder
adb push path/to/mtk-su /data/local/tmp/
Open an adb shell
adb shell
Change to your tmp directory
cd /data/local/tmp
Add executable permissions to the binary
chmod 755 mtk-su
At this point keep your device screen on and don't let it go to sleep. Run the command
./mtk-su
It should only take a second or two. If the program gets stuck for more than a few seconds and your device is awake, press Ctrl+C to close it.
The -v option turns on verbose printing, which is necessary for me to debug any problems.
The output of ./mtk-su -v is similar to this:
Spoiler
Code:
$ ./mtk-su -v
param1: 0x3000, param2: 0x18040, type: 2
Building symbol table
kallsyms_addresses pa 0x40bdd500
kallsyms_num_syms 70337, addr_count 70337
kallsyms_names pa 0x40c66d00, size 862960
kallsyms_markers pa 0x40d39800
kallsyms_token_table pa 0x40d3a100
kallsyms_token_index pa 0x40d3a500
Patching credentials
Parsing current_is_single_threaded
ffffffc000354868+50: ADRP x0, 0xffffffc000fa2000
ffffffc000354868+54: ADD xd, x0, 2592
init_task VA: 0xffffffc000fa2a20
Potential list_head tasks at offset 0x340
comm swapper/0 at offset 0x5c0
Found own task_struct at node 1
cred VA: 0xffffffc0358ac0c0
Parsing avc_denied
ffffffc0002f13bc+24: ADRP x0, 0xffffffc001113000
ffffffc0002f13bc+28: LDR [x0, 404]
selinux_enforcing VA: 0xffffffc001113194
Setting selinux_enforcing
Switched selinux to permissive
starting /system/bin/sh
UID: 0 cap: 3fffffffff selinux: permissive
#
Some other options:
mtk-su -c <command>: Runs <command> as root. Default command is /system/bin/sh.​mtk-su -s: Prints the kernel symbol table​mtk-su -Z <context>: Runs shell in a new selinux context. Example: ./mtk-su -Z u:r:logd:s0​If you see any errors other than about unsupported or incompatible platform or don't get a root shell, report it here. When reporting a problem with a device, please post a link to the firmware and/or the kernel sources.
Please post the model of any device that works with mtk-su that's not already confirmed.
Important: in rare cases, it may be necessary to run the tool multiple times before you hit UID 0 and get selinux permissive. If you don't achieve root on a particular run, the "UID: N cap: xxxxx...." line will reflect that. If it doesn't say "UID: 0 cap: 3fffffffff selinux: permissive", type exit to close the subshell and try mtk-su again.
WARNING If you have a device with Android 6 or higher, it likely has dm-verity enabled. On such a device one does not simply remount the system partition as read/write. The remount command will probably fail. But if you succeed in forcing it somehow it will trigger dm-verity, which will result in a very bad day. Your device will become inoperable until you restore the stock system partition.
DOWNLOAD​Current Version
Release 23
Spoiler: Changelog
Release 23 - August 24, 2020
Add support for some early Linux 3.10 tablet firmware
Add support for kernels with some debug features enabled
Release 22 - May 8, 2020
Expand kernel support
Enable seccomp handling for Android 8
Release 21 - March 14, 2020
Add support for more devices
Fix seccomp on 3.18 arm kernels
Release 20 - Dec 28, 2019
Add support for MT6580
Add support for some MT8183 versions
Fix handling of some 32-bit 4.x kernels with stack protection
Move to NDK build
Release 19 - October 20, 2019
Add -Z option for setting custom selinux context
Fix seccomp on armv7
Fix seccomp handling on late-revision 3.18 kernels
Improve error printing for critical failures
Strip supplementary groups in root shell
Do not spawn root shell on critical failures
Release 18 - July 29, 2019
Add support for kernel address space layout randomization (KASLR)
Change status output format
Release 17 - July 13, 2019
Fix missing capabilities under adb shell in Android 9.x
Disable seccomp in app mode of Android 9.x
Add support for MT6771 on Android 8.x
Reliability improvements
Release 16 - June 9, 2019
Add support for 32 & 64-bit kernels compiled with CONFIG_KALLSYMS_BASE_RELATIVE
Add support for MT676x on Android 7.x
Speedups
Release 15 - May 29, 2019
Run shell/command in global mount namespace -- mounting from apps is now visible to the whole system
Release 14 - May 22, 2019
Remove restriction for adb shell initial run on Android 8.0+
Add support for 32-bit kernels compiled under Android 8.0+
Add initial support for MT6771 on Android 9+
Minor bug fixes
Release 13 - May 16, 2019
Improve stack protection detection -- add support for some armv7-kernel 3.x phones
Release 12 - April 26, 2019
Unify the arm and armv7-kernel binaries into one
Support Linux 4.9.x
Improve speed and possibly reliability
Fix arm64 support for phones on kernel 3.10.65
Fix stack protection workaround for armv7 kernels
Update readme file
Release 11 - April 10, 2019
Fix up and enable rooting for 32-bit kernels -- first such device confirmed (thanks @anthonykb)
Improve criteria for detecting strong stack protection
Release 10 - April 7, 2019
Fix support for the latest Oreo devices
Add compatibility for kernels with stack protection (Nokia phones)
Improve reliability
Initial support for 32-bit (armv7) kernels -- needs testing
Release 9 - April 1, 2019
Confirmed support for at least some Oreo devices
Fix bugs with R8
Release 8 - March 30, 2019 (REMOVED)
Lay the groundwork for Oreo devices
Improve performance
Improve reliability
Release 7 - March 17, 2019
Add/fix support for many Linux ver. ≤ 3.18.22 devices
Fix arm binary on Fire HD 10
Release 6 - March 13, 2019
Add support for some devices with kernel 4.4.x (MT8167 confirmed by @cybersaga)
Minor bug fixes
Release 5 - March 7, 2019
Support kernels with CONFIG_KALLSYMS_ALL disabled
Improve reliability
Release 4 - March 4, 2019
Improve compatibility with phones
Support Fire TV 2 new FW
Minor bug fixes
Improve reliability
Release 3 - March 1, 2019
Add support for HD 10 7th gen
Add support for 3.10 kernel layout
Add possible support for MT67xx phones
Improve reliability
Release 2 - Feb. 27, 2019
Add support for HD 8 8th gen and 32-bit only user stacks
FAQ​I got the error, "This firmware cannot be supported". What's up with that?
This means that your device's firmware is not prone to the mechanism used by mtk-su. It may be a new device or it may have started from a firmware update. It will not be feasible to add root support for the current or future firmware versions. Check the last supported firmware version in post 4. If the last working FW is not listed and your device used to work with mtk-su, please report the last working version and/or your current version. In those cases, it may be possible to get mtk-su support by downgrading the firmware.
I got the error, "Firmware support not implemented". What gives?
That means that mtk-su does not recognize the type of firmware on your device. While It's technically possible to add basic detection, most of the time this error happens on devices that have already blocked mtk-su access. So implementing it would only kick the can down the road and probably lead to a, "This firmware cannot be supported" message (see above). If your device has Android 10+ or a security patch level at 03-2020 or higher, or if your firmware is newer than the last compatible version in post 4, there is no need to report this error.
Will this work on my phone?
Yes, it will work on your phone, unless it doesn't. But to be serious, there is no point in asking this question. If you have the device in hand, it is much quicker to just try out the above procedure than to wait for a response. You are usually the best person to answer that question. If your device is listed among the confirmed models or, to a lesser extent, your chipset is supported, that's a good indication that mtk-su will succeed, but that is not guaranteed. You should report your success or failure in this thread, along with the requested materials if it fails.
Why don't you reply to my post?
I read every post in this thread, and respond to practically every post that warrants a response. Sometimes I will only click a Thanks as an acknowledgement. The reasons I may not answer your question are:
It has already been answered in the FAQ or multiple times in the thread.
Your post is unrelated to this project. It may be specific to your device, which would make it off topic for this thread.
Your question is extremely vague and you appear to be intentionally leaving out basic information (e.g. fishing).
After getting a root shell I'm still getting 'permission denied' errors. WTH?
It may be that selinux is still being enforced. Having root with selinux enabled somehow ends up being more restrictive than a normal shell user. First, check that mtk-su succeeded in setting selinux to permissive by running getenforce. If it says Enforcing, then exit your shell and run mtk-su again.
Will this work on an MT65xx or MT8127?
There is no support for most 32-bit chips. But there may be a couple where it's possible.
Does this thing unlock the bootloader?
No, it does nothing to unlock the bootloader.
I ran mtk-su successfully, but my apps still don't have root permissions.
Mtk-su does not give apps root permissions. It is not a permanent root solution in and of itself. It opens a command shell that has root and administrative capabilities within the context of that shell. It's up to you what you want to do with it. But also, there is a way to load Magisk using this tool without the need to unlock your bootloader. Just follow this guide.
How does this tool work?
It overwrites the process credentials & capabilities in the kernel in order to gain privileges. It also turns off selinux enforcement by overwriting the kernel's selinux_enforcing variable. As for how it accesses that memory, the tool involves making use of the vulnerability known as CVE-2020-0069.
Can I include mtk-su in my app or meta-tool?
Generally speaking, you may not distribute any mtk-su zip or binaries with your software. That includes doing any automatic download of those files into your app. You can still use it with your tools. But you should ask your users to visit this thread and download the current release zip themselves. No apps have been permitted to bundle or auto-download mtk-su.
CREDITS​
Thank you to everyone who has tested and provided feedback to help me add support for the large variety of MTK-based devices out there. There are simply too many people to list.
MediaTek, Inc., who leave holes and backdoors in their OS to make software like this possible :good:
Thank you to everyone who has donated. You're the best!

INSTRUCTIONS FOR TERMINAL APP​You can optionally run mtk-su on a terminal emulator such as Terminal Emulator for Android (recommended) or Termux. The basic idea is to copy the executable to the terminal app's internal directory and run it from there. These are the instructions for Termux, but a similar procedure applies to all terminal shell apps.
Make sure you meet all the requirements from the first post, especially the first and last ones.
Download the current mtk_su zip to your device and unzip it. Take note of where you extracted it. Pick the variant that fits your device. (See above.)
Open Termux and copy the mtk-su binary to its home directory, which in this case is the shell's initial working directory.
General idea: cp path/to/mtk-su ./
For example,
cp /sdcard/mtk-su_r14/arm64/mtk-su ./
For this to work, you have to enable the Storage permission for your term app. Do not try to circumvent the cp command with clever copying methods involving file managers or external tools. Mtk-su will not get the right permissions that way.
Make file executable
chmod 700 mtk-su
Run the program
./mtk-su
If mtk-su fails, post the output of ./mtk-su -v here along with a link to firmware and/or kernel sources, if possible.
Note that for most terminal shell apps, the internal app directory is stored in the variable $HOME. So in general you would do
cd
cp path/to/mtk-su ./
chmod 700 mtk-su
./mtk-su

PROJECTS USING THIS TEMP ROOT​
Partition Backup Helper for Termux by @mrmazak
Creates a script that automatically backs up your device's partitions, which may come in handy for repairs or experimenting.
Full bootless root with Magisk (for 20.x to 21.4) by @diplomatic
Loads Magisk without modifying the firmware.
Full bootless root with Magisk for 22.x+ by @HemanthJabalpuri
Loads the latest Magisk version without modifying the firmware.

Status
NOTE: Any firmware update released after March, 2020 is bound to block this temp root. Think twice before updating your device if you would like to keep using mtk-su.
Confirmed Devices
Acer Iconia One 10 B3-A30/B3-A40/B3-A50 series
Acer Iconia One 8 B1-860 series
Acer Iconia Talk S
Alba tablet series
Alcatel 1 5033 series
Alcatel 1C
Alcatel 3L (2018) 5034 series
Alcatel 3T 8
Alcatel A5 LED 5085 series
Alcatel A30 5049 series
Alcatel Idol 5
Alcatel/TCL A1 A501DL
Alcatel/TCL LX A502DL
Alcatel Tetra 5041C
Alcatel U5 / Orange Rise 52
Alldocube iPlay10 Pro
Alldocube iPlay8
Amazon Fire 7 2019 -- up to Fire OS 6.3.1.2 build 0002517050244 only
Amazon Fire HD 8 2016 -- up to Fire OS 5.3.6.4 build 626533320
Amazon Fire HD 8 2017 -- up to Fire OS 5.6.4.0 build 636558520 only
Amazon Fire HD 8 2018 -- up to Fire OS 6.3.0.1 only
Amazon Fire HD 10 2017 -- up to Fire OS 5.6.4.0 build 636558520 only
Amazon Fire HD 10 2019 -- up to Fire OS 7.3.1.0 only
Amazon Fire TV 2 -- up to Fire OS 5.2.6.9 only
ANRY S20
ASUS ZenFone 3 Max ZC520TL
ASUS ZenFone Max Plus X018D
ASUS ZenPad 3s 10 Z500M
ASUS ZenPad Z3xxM(F) MT8163-based series
Barnes & Noble NOOK Tablet 7" BNTV450 & BNTV460
Barnes & Noble NOOK Tablet 10.1" BNTV650
Blackview A8 Max
Blackview BV9600 Pro (Helio P60)
BLU Life Max
BLU Life One X
BLU R1 series
BLU R2 LTE
BLU S1
BLU Tank Xtreme Pro
BLU Vivo 8L
BLU Vivo XI
BLU Vivo XL4
Bluboo S8
BQ Aquaris M4.5
BQ Aquaris M8
CAT S41
Coolpad Cool Play 8 Lite
Coolpad Legacy S(R)
Cubot Power
Doogee X70
Dragon Touch K10
Echo Feeling
Evercoss Genpro X Pro S50
Gionee F103 Pro
Gionee M7
Gionee S9
HiSense Infinity H12 Lite
HTC Desire 12
HomTom HT20
Huawei GR3 series
Huawei Y5II
Huawei Y6II MT6735 series
ION Gravity
Lava Iris 88S
Lenovo A5
Lenovo C2 series
Lenovo Tab E7
Lenovo Tab E8
Lenovo Tab2 A10-70F
Lenovo Tab3 10
Lenovo Vibe K5 Note
LG K8+ (2018) X210ULMA (MTK)
LG K10--K430 series
LG K10 (2017)
LG K50
LG Q7 (MTK)
LG Stylo 4 (MTK) -- up to Q710AL11k
LG Tribute Dynasty
LG X power 2/M320 series (MTK)
LG Xpression Plus 2/Harmony 3/K40 LMX420 series
Lumigon T3
Meizu M5c
Meizu M6
Meizu Pro 7 Plus
Motorola Moto C series
Motorola Moto E3 series (MTK)
Motorola Moto E4 series (MTK)
Nokia 1
Nokia 1 Plus
Nokia 3
Nokia 3.1
Nokia 3.1 Plus
Nokia 5.1
Nokia 5.1 Plus/X5
Odys PACE 10 (MT8163)
Onn 7" Android tablet
Onn 8" & 10" tablet series (MT8163) -- up to 10/2019 FW only
Oppo A59 series
Oppo A5s -- up to A.30 only
Oppo A7x -- up to Android 8.x
Oppo F5 series/A73 -- up to A.39
Oppo F7 series -- Android 8.x only
Oppo F9 series -- Android 8.x only
Oppo R9xm series
Oukitel K6
Oukitel K9
Oukitel K12
Oukitel U18
Philips E518
Protruly D7
RCA Voyager III - RCT6973W43MDN
Realme 1
Realme 3
Snopow M10 series
Sony Xperia C4
Sony Xperia C5 series
Sony Xperia L1
Sony Xperia L3
Sony Xperia M5 series
Sony Xperia XA series
Sony Xperia XA1 series
Southern Telecom Smartab ST1009X (MT8167)
Teclast M30
TECNO Spark 3 series
Umidigi F1 series
Umidigi Power
Verizon Ellipsis 10 HD QTAXIA1
Vernee Mix 2
Wiko Ride
Wiko Sunny
Wiko View3
Xiaomi Redmi 6/6A series
ZTE Blade 10 Prime
ZTE Blade A530
ZTE Blade A7 Prime
ZTE Blade D6/V6
ZTE Blade V8 Lite
ZTE Quest 5 Z3351S
ZTE Voyage 4S/Blade A611/Blade A610
Support Problematic*
Most/all Vivo phones
Most/all Huawei/Honor models with Android 8+
Most Oppo phones in app mode
Oppo F11 -- up to CPH1911EX_11_A.22 only
Most/all Samsung MTK-based phones
Supported Chipsets
Including, but not limited to: MT6735, MT6737, MT6738, MT6739, MT6750, MT6752, MT6753, MT6755, MT6757, MT6758, MT6761, MT6762, MT6763, MT6765, MT6771, MT6779, MT6795, MT6797, MT6799, MT8163, MT8167, MT8173, MT8176, MT8183, MT6580, MT6595
* These devices typically use kernel modifications to deter root access via exploits. But this temp root method can still attain root on most of these models in theory. However, I will not be adding support for such non-standard kernels in the main release versions. A tailored version of mtk-su can be made to handle a protected kernel in a specific firmware. This is not something I'm usually motivated to do. But it's possible to make such a version if you can somehow encourage me.

Re-re-reserved

Great work mate!! I would liked to of kept secret till I got myself a new Sony L3 and backup the ta thought.
:laugh:
:highfive:

LOL... thanks!
Don't worry man, no one reads this forum

Great work. Having used both a hardware root method and this method on a pair of devices I have, mtk-su was waaaaaaay easier to work with. Big thanks!

looks great ...i want to try it on a Vodafone carrier branded mtk67__ device in Spain / Europe to see what happens ...
ultimately i would want to use su to pull a copy of stock recovery to sd card / that and boot partition.img
what about after pulling stock recovery & porting twrp i flash twrp with flashfire or similar and after booting directly to recovery flash dm-verity disable .zip ...
reason being that bootloader is locked and this device is on marshmallow ...
*so my question is ...
will mounting rw on marshmallow trip dm-verity immediately and bootloop instantly or only on reboot ...if it's on reboot it would serve my purpose ..
* next question is if im running as su in shell how will I "give" escalated privileges to third party apk like flashfire for example or is it possible to disable dm-verity from root shell using commands ?
or installing mixplorer with root privileges for examle ..

KevMetal said:
looks great ...i want to try it on a Vodafone carrier branded mtk67__ device in Spain / Europe to see what happens ...
ultimately i would want to use su to pull a copy of stock recovery to sd card / that and boot partition.img
what about after pulling stock recovery & porting twrp i flash twrp with flashfire or similar and after booting directly to recovery flash dm-verity disable .zip ...
reason being that bootloader is locked and this device is on marshmallow ...
*so my question is ...
will mounting rw on marshmallow trip dm-verity immediately and bootloop instantly or only on reboot ...if it's on reboot it would serve my purpose ..
* next question is if im running as su in shell how will I "give" escalated privileges to third party apk like flashfire for example or is it possible to disable dm-verity from root shell using commands ?
or installing mixplorer with root privileges for examle ..
Click to expand...
Click to collapse
@diplomatic made a good outline of the the steps to "jump" into full root. At least until rebooted.
I will add the link to the post, but keep the discussion that follows , here in this thread
*Copied from post https://forum.xda-developers.com/showpost.php?p=79348378&postcount=569
diplomatic said:
For advanced users or devs: here's a general overview for a method to get root with Magisk without having to modify your boot image.
Get a Magisk zip file and extract the magiskinit binary. Push magiskinit to your device.
Extract the magisk binary from magiskinit with ./magiskinit -x magisk
Make a symbolic link to (or a copy of) magiskinit and call it magiskpolicy.
Make a symbolic link to (or a copy of) magisk and call it su.
Make a small ext4 image of about 2 to 4MB (using something like make_ext4fs -J -l 2MB). In it, place Magisk's magisk and su binaries. The su binary could be either a link to magisk or a copy of it. (Idea borrowed from @k4y0z's unlock method.)
Get a root shell with mtk-su
Patch the running sepolicy with a magisk context using ./magiskpolicy --live --magisk 'allow magisk * * *' .
Start a temporary Magisk daemon with ./magisk --daemon
Start a temporary Magisk root shell with ./su. This may involve prompts from Magisk Manager.
Check to make sure the new root shell has the context u:r:magisk:s0. Don't proceed if it's not that context.
From the magisk context shell, mount the ext4 image to /system/xbin with
losetup /dev/block/loop0 magisk.img
mount /dev/block/loop0 /system/xbin​You may be able to combine those 2 commands into one, but I wasn't able to on my device.
Kill the temporary magisk daemon with killall magiskd. The point of this is to launch a new daemon from within the magisk se-context. Otherwise there will be problems with selinux.
Start a new daemon with magisk --daemon. Notice that there's no ./ at the start. This is to test the loopback img.
Exit the temporary ./su shell. You may get an error message, but that's fine. At this point you should be back to the mtk-su shell.
Exit the mtk-su shell.
Check if su works. You should get a prompt from Magisk Manager.
At this point, if you get a normal root shell, you can do setenforce 1.
Now all apps that want su access will have it with proper prompting.
Have some app execute steps 6 through 17 at every startup.
Steps 1-5 are done once. Step 6 onward are done at every boot session. A script would probably help. I'm sure this is missing some details, but I just wanted to convey the general idea.
EDIT: If you get this system up and running, you of course want to avoid updating Magisk binaries through MM. That's pretty important because doing so will probably stop your device from booting.
Click to expand...
Click to collapse

KevMetal said:
looks great ...i want to try it on a Vodafone carrier branded mtk67__ device in Spain / Europe to see what happens ...
ultimately i would want to use su to pull a copy of stock recovery to sd card / that and boot partition.img
what about after pulling stock recovery & porting twrp i flash twrp with flashfire or similar and after booting directly to recovery flash dm-verity disable .zip ...
reason being that bootloader is locked and this device is on marshmallow ...
*so my question is ...
will mounting rw on marshmallow trip dm-verity immediately and bootloop instantly or only on reboot ...if it's on reboot it would serve my purpose ..
* next question is if im running as su in shell how will I "give" escalated privileges to third party apk like flashfire for example or is it possible to disable dm-verity from root shell using commands ?
or installing mixplorer with root privileges for examle ..
Click to expand...
Click to collapse
Cool... let us know the results of running mtk-su on that phone, as well as the full model name so I can list it.
So you're on the right track about installing permanent root. I was pretty vague about it in the OP because it's a complex topic and it's pretty risky territory. Before trying to mod your boot image with systemless root and/or verity disabled, you have to check how restrictive your BL is. It's very possible that it can accept self-signed or unsigned images without needing to unlock. You can check this in a minesweeper fashion by flashing your stock recovery with the OEM signature removed and see if it boots. If not, Android will restore the stock recovery automatically, no harm done.
If you want to flash partitions from a root shell, you can use the dd command. FlashFire is a glorified dd flasher. For example, to flash a recovery image you would do
dd if=recovery.img of=/dev/block/platform/mtk-msdc.0/11230000.MSDC0/by-name/recovery
The exact path of the dev node varies by device. You should do more research about it if you're interested. To dump partitions, essentially do the reverse of if= and of=.
If you want, you can post your stock recovery image and I can modify it so you can test how restrictive your BL is. There's no need to jump ahead to TWRP yet.

diplomatic said:
If you want, you can post your stock recovery image and I can modify it so you can test how restrictive your BL is. There's no need to jump ahead to TWRP yet.
Click to expand...
Click to collapse
Most MTK's allow the boot probably due to difficulties during OTA patches indeed a lot of the OEM OTA's I have seen actually flash the recovery.img to the boot partition first then reboot do the update flash the recovery to recovery partition then reboot to recovery do the final check then reflash the boot.img back to the boot partition.
I think this is so if the OTA fails at any point they are always in recovery mode. If any of that makes sense :laugh:
Some mtk fstab's I have seen even have a flag that states verify "recoveryonly" so you can flash a TWRP recovery.img to the boot and it will boot up but it will not if flashed to the recovery of course OEM's may have other ideas and implementations so caution and a way back are definitely needed.
It's definitely a game of Russian roulette with a one in six chance of you finding the loaded chamber.
Been too secure can backfire on OEM's and cost them as with the Amazon Fire Phone I brick 3 or 4 of those suckers trying to unlock it and even they could do nothing with them so they would just give me a new one and I am convinced they actually locked themselves out on that devices and that's why it never got a version update or bootloader unlock which is a shame because it was a good phone. :silly:

bigrammy said:
Most MTK's allow the boot probably due to difficulties during OTA patches
Click to expand...
Click to collapse
OK, but I don't see how any of this would prevent cryptographic signature checking and enforcement at any OTA installation stage. Do you have any reason to believe that most devices that are not unlockable have support for unsigned images?

diplomatic said:
OK, but I don't see how any of this would prevent cryptographic signature checking and enforcement at any OTA installation stage. Do you have any reason to believe that most devices that are not unlockable have support for unsigned images?
Click to expand...
Click to collapse
Depends on oem I guess eg: Lenovo TAB2 never unlock the bootloader, Infocus Never unlocked the bootloader, All China brands various I never unlocked the bootloaders yet all rooted with custom recovery's installed although most of these were Android 6.0 so AVB used by Magisk SuperSU etc works for them.
Nokia3 I did unlock the bootloader but I beginning to think maybe I didn't need to and maybe I can test that theory soon when I get one back I loaned out.
Big brands like Sony Defo need to be unlocked but lessor brands I am not so sure about.

OK, good to know, @bigrammy

diplomatic said:
OK, good to know, @bigrammy
Click to expand...
Click to collapse
I might try flash the boot of my Sony XA1 (bootloader locked) with a TWRP recovery over the weekend and see what happens. It just means me having to boot windows to recover it if it fails and I have not done that in 18 months or more :laugh:
EDIT: Unsigned TWRP Failed to boot so now I will try with a AVB signed image and see what happens.
EDIT 2: AVB signed TWRP Failed verification check too. :laugh:
PS: Never unlocked the Lumigon T3 (my daily driver) either and that was marketed a secure device it took me about 30 min's to to make a scatter file then pull the boot with SPFlashTool ported over TWRP from my Infocus pre patched the boot with Magisk flashed them back done. Again it seems AVB sig was enough for this device too but again Android 6.0. :laugh:

OK.... it would be interesting what happens with the Sony...
It's pretty much the same deal with the Asus Zenpad series. The Z3xxM series, based on MT8163, can be flashed without unlocking the BL. On the old Android 6 FW, you needed to have an AVB signature for it go through. On Android 7, you don't even need that. However, for the high-end MT8176-based Zenpad Z500M, they locked it down so that you'd need to unlock before installing a custom boot/recovery--OEM sig support only.
bigrammy said:
EDIT: Unsigned TWRP Failed to boot so now I will try with a AVB signed image and see what happens.
EDIT 2: AVB signed TWRP Failed verification check too. :laugh:
Click to expand...
Click to collapse
LOL... I guess I'll have to stick to unlocking my Sonys before installing root.

I have a question
I have been looking ways to root redmi 6a. Xiaomi have been imposing 15d grace period one any request to unlock boot loader. Very annoyed
My question is if I manage to root it and install TWRP. can I still modify the boot loader without unlocking it?
Tia
Sent from my Redmi 6A using Tapatalk

Hi, @ahhl
If you can install and boot TWRP without unlocking the bootloader, you can almost definitely install permanent root to a boot image. The question is whether the locked BL on that phone will boot an image that is unsigned or wipe out instead. This is what bigrammy and I were just talking about above. I'd love to know if mtk-su works on that phone, btw....

i will try. but i am just novice?. i read thru the conversation between you and bigrammy, only to 30% goes thru my head?
if i manage run mtk-su, then flash twrp, if the flashing did not work, it will just reboot back using stock boot.? i do not have to worry something i need to do just like bigrammy did for 30min, just to get the phone running? as the reboot just wipe twrp? is this true?

Is Realme 5 Pro VNDK compliant?

Hello, I'm interested in buying Realme 5 Pro, since it only costs 189 USD in my country for the 4GB/128GB combination. I think that's quite a steal.
But, since development were quite slow, I'm looking forward on using GSI thanks to Project Treble. So my question is, like the title, does Realme 5 Pro fully support Treble with being VNDK compliant? VNDK is used to support newer GSI so it's possible to flash Android 10 or R for this device.
to check, you could use the guide here.
or I'll just paste it here.
1) Root your device
2) Open terminal (download from play store)
3) write this
Code:
adb shell cat /system/etc/ld.config.version_identifier.txt \
| grep -A 20 "\[vendor\]"
4) press enter
5) in the output, check [vendor] section and look for
Code:
namespace.default.isolated
if the value is "true", then this device fully support VNDK.
Could anybody check it for me?
Thanks in advance!

Ah, I tried to check it on android terminal ?* I'm quite tired. Will check tomorrow.
Edit.: Realme 5 Pro seems to support treble but not seamless system updates for it has only one partition for system not A and B.

Can someone plz give appropriate answer to this?
I am looking forward to it!

namespace.default.isolated = false
but the file name is /system/etc/ld.config.vndk_lite.txt
What a loss..

Well. Theoretically it doesn't support AB but in fact it completely supports treble and AB. Tried a load of GSI and ROMs till now and they all work AB.

[Guide] Re-locking the bootloader on the Google Pixel 5 with a self-signed build of LOS 19.1

What is this tutorial?
This tutorial will:
Creating an unofficial build of LineageOS 19.1 suitable for using to re-lock the bootloader on a Google Pixel 5
Take you through the process of re-locking your bootloader after installing the above
This tutorial will NOT:
Remove *all* warning messages during boot (the yellow "Custom OS" message will be present though the orange "Unlocked bootloader" message will not)
Allow you to use official builds of LineageOS 19.1 on your device with a re-locked bootloader (more details near the end of the tutorial)
This tutorial will assume you are working on an Ubuntu 20.04 installation, if you are using Windows or another Linux distro, the commands may be different or not work at all.
Supported devices:
The following devices have been tested and confirmed to work:
OnePlus 5T (dumpling)
OnePlus 6 (enchilada)
OnePlus 6T (fajita)
OnePlus 7 (guacamoleb)
OnePlus 7 Pro (guacamole)
Google Pixel 4 (flame)
Google Pixel 5 (redfin)
Note: As of OxygenOS 12, OnePlus no longer supports bootloader relocking with custom keys, as such, any OnePlus device that receives official Android 12 and has LineageOS 19.1 based on it (which include the 8/8T/9 models) cannot be supported.
For simplicities sake, all further references will only be to the Google Pixel 5 (redfin).
Pre-requisites:
a mid level knowledge of terminal commands and features
a supported phone
a PC with enough CPU/RAM to build LineageOS 19.1 (recommended 8 cores, 32g of RAM)
a working USB cable
fastboot/adb installed and functional
LineageOS 19.1 source code downloaded
at least one successful build of LineageOS
at least one successful signing of your build with your own keys
Misc. notes:
the basics of building/signing of LineageOS is outside the scope of this tutorial, refer to the LineageOS Wiki (https://wiki.lineageos.org/devices/redfin/build) for details on how to complete these tasks
if you have generated your signing keys at some significant time in the past, you may have generated 2048 bit keys. 4096 bit keys are now supported and recommended, so you may want to generate new keys for LineageOS 19.1. If you decided to continue to use the 2048 bit keys make sure to make the appropriate changes in step 2 and 3 below.
signing with keys that have passwords set can cause problems, the easiest way around this is to *not* set a password when you generate your signing keys, however this does add risk that if your key files are stolen, no password is required to use them.
you'll be modifying some code in LineageOS, so if you are not comfortable using basic editing utilities as well as patch, do not proceed any further
the path to your LineageOS source code is going to be assumed to be ~/android/lineageos, if it is somewhere else, substitute the correct path in the tutorial
the path to your private certificate files is going to be assumed to be ~/.android-certs, if it is somewhere else, substitute the correct path in the tutorial
*** WARNING ****
This process may brick your device. Do not proceed unless you are comfortable taking this risk.
*** WARNING ****
This process will delete all data on your phone! Do not proceed unless you have backed up your data!
*** WARNING ****
Make sure you have read through this entire process at least once before attempting, if you are uncomfortable with any steps include in this guide, do not continue.
And now on with the show!
Step 1: Basic setup
You need a few places to store things, so create some working directories:
Code:
mkdir ~/android/redfin
mkdir ~/android/redfin/patches
mkdir ~/android/redfin/pkmd
You also need to add "~/android/lineageos/out/host/linux-x86/bin" to your shell's profile path. Make sure to close and restart your session afterwards otherwise the signing will fail later on with a "file not found" error message (this may no longer be required).
Step 2: Update the signing keys to use & enable AVB
The Pixel 5 device files are mostly contained in the shared "redbull" device for the Pixel 5 and 5 Pro. You will need to add a few parameters to the shared make file found here: ~/android/lineageos/device/google/redbull/BoardConfigLineage.mk, they are:
Code:
BOARD_AVB_ALGORITHM := SHA256_RSA4096
BOARD_AVB_KEY_PATH := /home/<userid>/.android-certs/releasekey.key
Note you cannot use "~" in the path names above to signify your home directory, so give the full absolute path to make sure the files are found.
LineageOS by default disables Android Verified Boot's partition verification, but you can enable it now as all the required parts will be in place.
To enable partition verification do the following:
Code:
cd ~/android/lineageos/device/google/redbull
sed -i 's/^BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS += --flags 3/#BOARD_AVB_MAKE_VBMETA_IMAGE_ARGS += --flags 3/' BoardConfigLineage.mk
Step 3: Set the AVB key to use
To set the correct signing key to use for AVB, do the following:
Code:
cd ~/android/lineageos/device/google/redbull
sed -i 's/external\/avb\/test\/data\/testkey_rsa2048.pem/\/home\/<userid>\/.android-certs\/releasekey.key/' BoardConfig-common.mk
sed -i 's/SHA256_RSA2048/SHA256_RSA4096/' BoardConfig-common.mk
Don't forget to replace your <userid> in the first sed command above with your current logged in user id.
Step 4: Patch the AOSP and Device Makefile
You also need to patch the Makefile included with AOSP as it will otherwise fail during the build.
The required patch can be found here:
https://raw.githubusercontent.com/Wunderment/build_tasks/master/source/core_Makefile-19.1.patch
Download it and store in ~/android/redfin/patches.
Now apply it with the following command:
Code:
cd ~/android/lineageos/build/core
patch Makefile ~/android/redfin/patches/core-Makefile-fix-19.1.patch
If you would like to know more about this patch, see the additional info at the bottom of this post.
Step 5: Build LineageOS
You are now ready to build:
Code:
cd ~/android/lineageos
source build/envsetup.sh
breakfast redfin
croot
mka target-files-package otatools
Step 6: Sign the APKs
You are now ready to sign the apks with sign_target_files_apks:
Code:
./build/tools/releasetools/sign_target_files_apks -o -d ~/.android-certs $OUT/obj/PACKAGING/target_files_intermediates/*-target_files-*.zip signed-target_files.zip
Step 7: Build the OTA
Now it is time to complete the OTA package:
Code:
./build/tools/releasetools/ota_from_target_files -k ~/.android-certs/releasekey --block signed-target_files.zip lineage-19.1-[date]-UNOFFICIAL-redfin-signed.zip
Note, replace [date] with today's date in YYYYMMDD format.
Step 8: Create pkmd.bin for your phone
Before you can lock your phone, you have to tell it what your public key is so it knows it can trust your build.
To do this you need to create a pkmd.bin file:
Code:
~/android/lineageos/external/avb/avbtool extract_public_key --key ~/.android-certs/releasekey.key --output ~/android/redfin/pkmd/pkmd.bin
Note: if you don't have a releasekey.key file in your certificate directory, use the following command to generate one:
Code:
openssl pkcs8 -in releasekey.pk8 -inform DER -out releasekey.key -nocrypt
Step 9: Flashing your LineageOS build
It's time to flash your build to your phone. The following steps assume you have already unlocked your phone and have flashed an official version of LineageOS to it. You don't need to have flashed LineageOS yet, you could use TWRP through "fastboot boot" if you prefer. Or, if you want to use the recovery that was just created, it is located in ~/android/lineageos/out/target/product/redfin and is called vendor_boot.img.
Reboot your phone in to recovery mode
In LineageOS Recovery return to the main menu and select "Apply update", then "Apply from ADB".
From your PC, run:
Code:
adb sideload ~/android/lineageos/lineage-19.1-[date]-UNOFFICIAL-redfin-signed.zip
When the sideload is complete, reboot into LineageOS. Make sure everything looks good with your build.
You may also need to format your data partition at this time depending on what you had installed on your phone previously, it's best to do so anyway. In LineageOS Recovery return to the main menu and select "Factory reset", then "Format data/factory reset", then confirm with "Format data".
Step 10: Flashing your signing key
Now it's time to add your signing key to the Android Verified Boot process. To do so, do the following:
Reboot your phone in to fastboot mode
From your PC, run:
Code:
fastboot flash avb_custom_key ~/android/redfin/pkmd/pkmd.bin
fastboot reboot bootloader
fastboot flashing lock
On your phone, confirm you want to re-lock and it will reboot
Note: If you have already flashed a custom avb key you must erase it before flashing the new one, use "fastboot erase avb_custom_key" to do so.
Your phone will then factory reset and then reboot in to LineageOS.
Which of course means you have to go through the first time setup wizard, so do so now.
Step 11: Disable OEM unlock
Congratulations! Your boot loader is now locked, but you can still unlock it again using fastboot, so it's time to disable that as well.
Unlock you phone and go to Settings->About phone
Scroll to the bottom and find "Build number"
Tap on it you enable the developer options
Go to Settings->System->Advanced->Developer options
Disable the "OEM unlocking" slider
Reboot
Step 12: Profit!
Other things
The above will build a standard USERDEBUG version of LineageOS, however this will still allow LineageOS Recovery to sideload non-signed files as well as give you root shell access through ADB. Step 3/4 above protects your system/vendor/boot/dtbo/etc. partitions, but none of the others. Likewise USERDEBUG builds will allow for rolling back to a previous builds/versions of LineageOS. To increase security and disallow both of these scenarios you may want to build a USER version of LineageOS to install. However this brings in other issues, such as flashing newer firmware from OnePlus so make sure you understand the implications of both choices. For more details on build types, see https://source.android.com/setup/develop/new-device#build-variants.
The above build will not include other items like GAPPS or Magisk. Those are outside the scope of this tutorial.
If you want to remove you signing key from your phone, you can do it by running "fastboot erase avb_custom_key".
The changes you made to the AOSP Makefile may conflict with future updates that you pull from LineageOS through repo sync, if you have to reset the file to get repo sync to complete successfully, you'll have to reapply the changes afterwards.
So why can't I do this with official LineageOS builds?
You can! See https://forum.xda-developers.com/t/...ustom-rom-such-as-lineageos-official.4260825/ for more details.
For Android Verified Boot (AVB) to work, it must have the hash values for each of the system/vendor/boot/dtbo/etc. partitions stored in vbmeta. Official LineageOS builds for redfin do include the vendor.img in them along with everything else that is needed, however that is not true for all phones.
An "issue" that might stop someone from using the official redfin builds is that AVB is enabled in the official LineageOS builds but does not validate the hash trees during boot which limits the protection offered.
Ok, what messages do I see during the boot process then?
During a boot you will of course see the standard OnePlus power up screen, followed by the yellow "custom os" message and then the standard LineageOS boot animation.
For more details on AVB boot messages, see https://source.android.com/security/verifiedboot/boot-flow
So what does that patch to the Makefile do?
AOSP's default Makefile makes an assumption that when AVB is enabled, that all the img files will be available well before vbmeta.img is created. This is simply NOT true and AOSP seems to know this as well from the following comment in the Makefile:
Code:
# Not using INSTALLED_VBMETA_SYSTEMIMAGE_TARGET as it won't be set yet.
ifdef BOARD_AVB_VBMETA_SYSTEM
$(eval $(call check-and-set-avb-args,vbmeta_system))
endif
ifdef BOARD_AVB_VBMETA_VENDOR
$(eval $(call check-and-set-avb-args,vbmeta_vendor))
endif
These two calls eventual evaluate to returning the path to the partitions based upon the INSTALLED_*IMAGE_TARGET variable, which isn't created until later in the build process.
Because of this, the command to build vbmeta.img gets corrupted due to the missing make variable being empty and an invalid command line is passed to avbtool near the end of the build.
The corruption happens due to the fact that the following line from the original Makefile:
Code:
--include_descriptors_from_image $(call images-for-partitions,$(1))))))
Gets added to the avbtool call even if "$(call images-for-partitions,$(1))" turns out to be an empty string. Avbtool then throws an error message as it is expecting a parameter after the "--include_descriptors_from_image" flag that is added for the "empty" partition path.
The fix is to call "$(call images-for-partitions,$(1))" earlier, set it to a variable and check to make sure it isn't an empty string before letting the "--include_descriptors_from_image" be added to the avbtool command line to be used later.
This technically generates an incomplete vbmeta.img file during the build process, but since the signing process recreates it from scratch anyway; no harm, no foul.
Thank-Yous
Obviously to all of the members of the LineageOS team!
aleasto & mikeioannina for supporting redfin
optimumpro for the OnePlus 5/5t re-locking guide which inspired this one
Quark.23 for helping with the process and testing on enchilada
Related guides
OnePlus 5/5t re-locking guide (https://forum.xda-developers.com/oneplus-5/how-to/guide-relock-bootloader-custom-rom-t3849299)
Re-locking the bootloader with a pre-built custom ROM, such as LineageOS official (https://forum.xda-developers.com/t/...ustom-rom-such-as-lineageos-official.4260825/)
Re-locking the bootloader on the OnePlus 6t with a self-signed build of LOS 17.1 (https://forum.xda-developers.com/t/...s-6t-with-a-self-signed-build-of-los.4113743/)
Re-locking the bootloader on the OnePlus 8t with a self-signed build of LOS 18.1 (https://forum.xda-developers.com/t/...with-a-self-signed-build-of-los-18-1.4259409/)
A discussion about bootloader locking/unlocking... AKA I want to relock my bootloader, should I? (over on [reddit]/ r/LineageOS/comments/n7yo7u/a_discussion_about_bootloader_lockingunlocking/) (link broken on purpose to avoid the linked post being embedded here)

Thank you for your guides on bootloader relocking. They have helped to enable bootloader relocking on other devices.
After "all further references will only be to the Google Pixel 5 (redfin)" but before the "Thank-Yous", there are a few (typos?) that refer to the oneplus. In particular, beneath "Other things" and "under what messages do I see during the boot process then?"
HTH

If anyone is interested, I made a tool to automate all this using Hetzner Cloud. This tool's client can pretty much run on anything, including android itself on Termux(since it's a terminal app). You can make the tool upload the finished builds to your private repo so no need to worry about letters from Google for using GAPPS.
Bash:
wget -O ham "https://github.com/antony-jr/ham/releases/download/stable/ham-linux-amd64"
chmod a+x ham
./ham init # Init with your Hetzner Cloud API (Only Once)
./ham get [email protected]/enchilada-los19.1:gapps
# Without gapps
./ham get [email protected]/enchilada-los19.1
# You can close the terminal app after it starts tracking remote build
# the build continues to run on the cloud until finishes or errors out,
# in both cases the server destroys itself to save you a lot of cost.
# It cost me 0.30 euros for single build which ran for about 3 hours.
Thanks for the OP though, I copied a lot of scripts from WundermintOS.
Now the output of the build can be flashed like the OP described for OnePlus 6 and the pkmd.bin file will be included in the recovery zip file along with the boot/recovery image. The tool will ask you question before it starts the build for the variables, like the path to Android Certs in a zip file which will be used for signing.

For anyone that is interested, I've posted an updated guide for LineageOS 20.0 on the Pixel 6 here.

Please Custom Rom for OPPO A5s

Can someone please make a custom rom for oppo a5s i'm begging
i tried like 10 gsi roms and none of them worked properly

Because GSI ROMs require Android supports Project Treble, have you checked phone supports Project Treble?
Using ADB simply type the following command:
Code:
adb shell "getprop ro.treble.enabled"
It will return a boolean value, true if your device supports Treble and false if it doesn't.

jwoegerbauer said:
Because GSI ROMs require Android supports Project Treble, have you checked phone supports Project Treble?
Using ADB simply type the following command:
Code:
adb shell "getprop ro.treble.enabled"
It will return a boolean value, true if your device supports Treble and false if it doesn't.
Click to expand...
Click to collapse
when i said worked properly i meant being stable because i know my phone is treble supported a only system and i tried many os like arrowos, havocos, phh aosp (10-9-8.1) but they all crash a lot and a lot of hardware does not work like fingerprint and face unlock and the brightness is at max 50%

If you flash a GSI ROM all OEM / vendor specific files ( the drivers ) are missing by default, hence you must not be surprised that a lot of hardware isn't working as expected.

jwoegerbauer said:
If you flash a GSI ROM all OEM / vendor specific files ( the drivers ) are missing by default, hence you must not be surprised that a lot of hardware isn't working as expected.
Click to expand...
Click to collapse
yea that's why it kinda disappointing
i was trying to make the gsi rom recognize the hardware but i couldn't find a solution