Here's the latest release 6.2.8.1_r3_4054 of the pre-rooted rom I've combined into one patched ota removed zip which packs the downgraded older interface with accessibility settings working again. After flashing, clear data in settings/applications/Appstore to prevent issues with apps and reboot.
There's no bugs in this rom that I know of.
No efuse is present in this rom and is completely safe to flash. Remember to not flash stock images that are 6.2.8.0 and higher. Only flash the pre-rooted roms from @rbox so that the efuse doesn't burn.
Nothing is removed in this rom, only re-edited for system app downgrades that include the com.amazon.tv.launcher (KFTV launcher), com.amazon.tv.settings.v2 (Amazon Settings), and lastly, com.amazon.venezia (Appstore) with options to hide cloud apps, to adjust AV Sync Tuning, as well with the Wi-Fi icons when connecting wirelessly altogether with the older interface.
Things that don't work
Amazon FreeTime
Profiles
Some apps that recognize a bootloader is unlocked and forcibly closes i.e Peacock TV
OTA updates?? Of course ota updates no longer work. This rom removes the fota and any type of updates from occurring
Amazon Live Shopping (The app does work, but the older UI somehow doesn't recognize it as one)
For those that prefer using the newer interface with the same patches, download this rom from this link:
https://forum.xda-developers.com/attachments/6-2-8-1_r3_4054_patched-zip.5425403/
I created 6.2.9.5 for (mantis) with a patched DeviceSoftwareOTA that never updates the system ever again and I used the pre-rooted 6.2.8.1 updater-script to remove the ewriter and efuse_check.sh. I'll need help making the accessibility patches. More are to follow with testings of the older interface and features removed within the newer software.
Is eFuse removed in the firmware?
9lalex9 said:
Is eFuse removed in the firmware?
Click to expand...
Click to collapse
I'm sure it is. I double checked the updater-script and it says this
(getprop("ro.product.device") == "mantis" || getprop("ro.build.product") == "mantis") || abort("This package is for \"mantis\" devices
this is a \"" + getprop("ro.product.device") + "\".");
ifelse(is_mounted("/system"), unmount("/system"));
package_extract_dir("install", "/tmp");
set_metadata("/tmp/backuptool.sh", "uid", 0, "gid", 0, "mode", 0755);
mount("ext4", "EMMC", "/dev/block/platform/soc/11230000.mmc/by-name/system", "/system", "");
run_program("/tmp/backuptool.sh", "backup");
unmount("/system");
ui_print("Copying system image...");
block_image_update("/dev/block/platform/soc/11230000.mmc/by-name/system", package_extract_file("system.transfer.list"), "system.new.dat", "system.patch.dat");
ui_print("Copying vendor image...");
block_image_update("/dev/block/platform/soc/11230000.mmc/by-name/vendor", package_extract_file("vendor.transfer.list"), "vendor.new.dat", "vendor.patch.dat");
mount("ext4", "EMMC", "/dev/block/platform/soc/11230000.mmc/by-name/system", "/system", "");
delete("/system/bin/efuse_check.sh",
"/system/bin/ewriter");
unmount("/system");
ui_print("Copying kernel...");
package_extract_file("boot.img", "/dev/block/platform/soc/11230000.mmc/by-name/boot");
package_extract_dir("magisk", "/dev/tmp/install");
set_metadata("/dev/tmp/install/install-magisk.sh", "uid", 0, "gid", 0, "mode", 0755);
run_program("/dev/tmp/install/install-magisk.sh");
mount("ext4", "EMMC", "/dev/block/platform/soc/11230000.mmc/by-name/system", "/system", "");
run_program("/sbin/mkdir", "/system/addon.d");
run_program("/tmp/backuptool.sh", "restore");
unmount("/system");
Whereas with the original stock 6.2.8.0_3236, it activates some type of blocklist from Amazon without the disable efuse_check in this updater-script:
So to answer your question, yes it disables the efuse in the modded rom. The script is important when flashing zips and why only flashing rbox's pre-rooted roms are necessary. He edits the scripts from the stock rom to make it compatible with rooted 4K devices so the efuse stays disabled under that line he added above.
So in conclusion, when you extract the pre-rooted rom, you'll see the META-INF/com/ without all the Amazon stuff added to it to make it disable the efuse under their scripts because these scripts tell the operating system to block anything from being modified
getprop("ro.product.device") == "mantis" || abort("E3004: This package is for \"mantis\" devices; this is a \"" + getprop("ro.product.device") + "\".");
ui_print("Target: Amazon/mantis/mantis:6.0/NS6280/3236N:user/amz-p,release-keys");
show_progress(0.650000, 0);
ui_print("Patching system image unconditionally...");
block_image_update("/dev/block/platform/soc/11230000.mmc/by-name/system", package_extract_file("system.transfer.list"), "system.new.dat", "system.patch.dat") ||
abort("E1001: Failed to update system image.");
show_progress(0.100000, 0);
ui_print("Patching vendor image unconditionally...");
block_image_update("/dev/block/platform/soc/11230000.mmc/by-name/vendor", package_extract_file("vendor.transfer.list"), "vendor.new.dat", "vendor.patch.dat") ||
abort("E2001: Failed to update vendor image.");
show_progress(0.050000, 5);
package_extract_file("boot.img", "/dev/block/platform/soc/11230000.mmc/by-name/boot");
show_progress(0.200000, 10);
package_extract_file("images/logo.bin", "/dev/block/platform/soc/11230000.mmc/by-name/logo");
package_extract_file("images/lk.bin", "/dev/block/platform/soc/11230000.mmc/by-name/lk");
package_extract_file("images/tz.img", "/dev/block/platform/soc/11230000.mmc/by-name/tee1");
package_extract_file("images/tz.img", "/dev/block/platform/soc/11230000.mmc/by-name/tee2");
package_extract_file("images/preloader.img", "/dev/block/platform/soc/11230000.mmc/mmcblk0boot0");
package_extract_file("META-INF/com/amazon/android/target.blocklist", "/cache/recovery/last_blocklist");
set_metadata("/cache/recovery/last_blocklist", "uid", 0, "gid", 0, "mode", 0444, "capabilities", 0x0);
set_progress(1.000000);
Skel40 said:
I'm sure it is. I double checked the updater-script
Click to expand...
Click to collapse
Afaik the efuse doesn't burn during ROM flashing (i.e. you can't find the efuse burning in the updater scripts).
Afaik it can only burn, if TZ gets an update during ROM flashing, then the efuse gets burned at the next reboot (only possible in case of a locked Stick = stock recovery).
But as you know, for an unlocked stick, TWRP recovery will block updating/flashing TZ to tee1 and 2, same for LK and PL images. No LK/TZ updates = no fuse burning
I think @9lalex9 asked about what rbox did with his last prerooted, cuz rbox removed the kernel script that burns the efuse in the boot.img of his prerooted Rom. This is not needed as long as TWRP is always there, but it if you like you can do it too. Maybe ask @Pretoriano80 I guess he can tell you some detailed things about the kernel Another way may be to grab the prerooted rom as source for your modded rom...
Skel40 said:
Added back the old interface because the new ui is horrendous.
Click to expand...
Click to collapse
Yes. You're right, it's awful, the most terrible thing they did in the last years^^
So keep going on with this, please
Skel40 said:
I'd like to introduce you all rooted Fire TV Stick 4K users a mod I've been working on to get the old interface back on your devices without the new interface. In this beta release, you will find the old interface on this version and the current version of this stock rom is 6.2.8.0_3236. Everything works. Apps install just fine as if you were on the previous OS, 6.2.7.7. What you'll also find in this mod is notable improvements in performance. Before doing any changes to your Fire TV Stick 4K, make a full backup of your system and data before proceeding. Flash this zip in TWRP after wiping everything in recovery. Be sure to block updates so the old ui isn't overwritten with the new ui.
Bugs:
The UI will lag occasionally, don't know what's causing this issue. This isn't really considered a bug but the 'Who's watching Fire TV' screen will appear without the actual icon because of this being an older launcher.
Notes:
Added back the old interface because the new ui is horrendous. I can't even go to my apps like I would before so this mod prevents me from staying on an older OS. What I've done with this mod is very simple. Amazon only updated the interface so I downgraded back to a previous version with AV Sync Tuning as well with the Wi-Fi Icons. Feel free to leave any feedback about adding or removing features if this rom isn't working right and please report any bugs.
The efuse is also disabled with this rom. It's found in the script to disable the efuse_check.
Requirements: A rooted and unlocked Fire TV Stick 4K without the eFuse chip blown after 6.2.7.7, basic knowledge that this stock modded rom is beta so there will be a few bugs.
Official Modded Pre-Rooted Rom Latest (6.2.8.0_3236):
Click to expand...
Click to collapse
Can you also fix Accessibility? Only thing which is keeping me from upgrading
@
Sus_i[EDIT]
So I was thinking of patching to fix Accessibility,
I have deodexed the ROMs and I was thinking of following few approaches.
1. Replace logan
2. Replace Services with older version
3. Try to patch the jar of Services.
Even though i have some experience with smali jar and basic stuff but i have no experience with binary files.
Now i have some questions relating some problems.
Changing stuff in TWRP does not affect the System
So i have to find a way to flash without taking to much time.
And what's the matter with efuse??
On which version does it blow up and what are the caveats?
Hi again,
I have patched this file (fosservices.jar) its from 6.2.7.3, can anyone check if it fixes accessibility.
SweenWolf said:
Hi again,
I have patched this file (fosservices.jar) its from 6.2.7.3, can anyone check if it fixes accessibility.
Click to expand...
Click to collapse
Where can I overwrite this file? 6.2.7.3 patches accessibility. Get the file from 6.2.7.1. I'm glad to test it out rn
Skel40 said:
Where can I overwrite this file? 6.2.7.3 patches accessibility. Get the file from 6.2.7.1. I'm glad to test it out rn
Click to expand...
Click to collapse
replace this with /system/framework/fosservices.jar , there should also be an odex file in /system/framework/oat/arm/fosservices.odex (delete this file).
this file is from 6.2.7.3 where accessibility services are restricted to system apps only.
on 6.2.7.1 there is no such restriction.
if you are on 6.2.7.1 then theres no need to test because accessibility works just fine. i need to test this on newer version, and i am also unable to download your zip file for whatever reason. if i had then i could have gave you patched version from 6.2.8.0
The reason why I am not doing is because i have removed root and TWRP.
if this worked on 6.2.8.0 then i will update to that using TWRP, remove OTA apps, and patch this file and lock the bootloader again.
[Question] If i relock the bootloader and it replaces the boot image with stock one. will it blow the efuse?
SweenWolf said:
replace this with /system/framework/fosservices.jar , there should also be an odex file in /system/framework/oat/arm/fosservices.odex (delete this file).
this file is from 6.2.7.3 where accessibility services are restricted to system apps only.
on 6.2.7.1 there is no such restriction.
if you are on 6.2.7.1 then theres no need to test because accessibility works just fine. i need to test this on newer version, and i am also unable to download your zip file for whatever reason. if i had then i could have gave you patched version from 6.2.8.0
The reason why I am not doing is because i have removed root and TWRP.
if this worked on 6.2.8.0 then i will update to that using TWRP, remove OTA apps, and patch this file and lock the bootloader again.
[Question] If i relock the bootloader and it replaces the boot image with stock one. will it blow the efuse?
Click to expand...
Click to collapse
Thanks for getting back to me. That's strange. It's downloading fine on my end. I'll try to upload it on mega or something like that. That's not recommended. Any OS after 6.2.7.7 will blow the efuse on a locked bootloader so the exploit is no longer working unless you kept your device in an unlocked state like mine. I own 3 4K's fully unlocked with 6.2.7.7 because of older easy to navigate ui and the efuse being disabled as well thanks to TWRP. Once you're unlocked you're safe. What I should recommend instead is getting one of the latest pre-rooted roms available due to the efuse check being removed then replace the boot.img. Don't update with the official stock version as that will keep your device locked for good. No bootrom to access anymore. It's impossible so if you want to take the risk go ahead but I don't advise doing so.
Skel40 said:
Thanks for getting back to me. That's strange. It's downloading fine on my end. I'll try to upload it on mega or something like that. That's not recommended. Any OS after 6.2.7.7 will blow the efuse on a locked bootloader so the exploit is no longer working unless you kept your device in an unlocked state like mine. I own 3 4K's fully unlocked with 6.2.7.7 because of older easy to navigate ui and the efuse being disabled as well thanks to TWRP. Once you're unlocked you're safe. What I should recommend instead is getting one of the latest pre-rooted roms available due to the efuse check being removed then replace the boot.img. Don't update with the official stock version as that will keep your device locked for good. No bootrom to access anymore. It's impossible so if you want to take the risk go ahead but I don't advise doing so.
Click to expand...
Click to collapse
Thanks, I was reading other post on XDA where people are stuck with locked bootloader on 6.2.8.0, I do not do OTA updates, and I certainly don't update without assurance that my apps work fine on it. i was thinking of getting an image and make some changes by removing the efuse binaries from bin and also was thinking of unlocking ADB on Boot.img and if found removing efuse from there, the thing is i have to patch boot.img as my stick becomes unstable with TWRP. but for now I just wanted to go 6.2.7.3 and check if everything goes right i will stay on it else jump back to 6.2.7.1
Sorry for bothering you, what version introduced profile in FireTV?
SweenWolf said:
Thanks, I was reading other post on XDA where people are stuck with locked bootloader on 6.2.8.0, I do not do OTA updates, and I certainly don't update without assurance that my apps work fine on it. i was thinking of getting an image and make some changes by removing the efuse binaries from bin and also was thinking of unlocking ADB on Boot.img and if found removing efuse from there, the thing is i have to patch boot.img as my stick becomes unstable with TWRP. but for now I just wanted to go 6.2.7.3 and check if everything goes right i will stay on it else jump back to 6.2.7.1
Sorry for bothering you, what version introduced profile in FireTV?
Click to expand...
Click to collapse
That makes sense! I don't update thru ota either. This is off topic but do you know why updating the settings V2 app on 6.2.7.1 won't do anything to add av sync tuning and wifi icons by any chance? It acts like an update but doesn't add those features in. Maybe it's the .jar files? I also have a slight issue with my old UI rom too. Its laggy as if something heavy is running in the background. Do you think I should run a logcat? I'll need to upload the rom to mega for you to see and possibly fix. The version that introduced profiles was 6.2.8.0_3233
@SweenWolf I tried the .jar file. It bootloops on version 6.2.8.0_3236
Skel40 said:
@SweenWolf I tried the .jar file. It bootloops on version 6.2.8.0_3236
Click to expand...
Click to collapse
Thanks for trying but this is to be installed on 6.2.7.3 not 6.2.8.0, I thought you had that, let me download the app from mega and then patch the file of 6.2.8.0
SweenWolf said:
Thanks for trying but this is to be installed on 6.2.7.3 not 6.2.8.0, I thought you had that, let me download the app from mega and then patch the file of 6.2.8.0
Click to expand...
Click to collapse
My fault. I should've paid attention..
Skel40 said:
That makes sense! I don't update thru ota either. This is off topic but do you know why updating the settings V2 app on 6.2.7.1 won't do anything to add av sync tuning and wifi icons by any chance? It acts like an update but doesn't add those features in. Maybe it's the .jar files? I also have a slight issue with my old UI rom too. Its laggy as if something heavy is running in the background. Do you think I should run a logcat? I'll need to upload the rom to mega for you to see and possibly fix. The version that introduced profiles was 6.2.8.0_3233
Click to expand...
Click to collapse
i haven't checked but as far as i know, the actual code is in the settings V2, but the shortcuts are embedded in the amazon launcher, so there will be two icons in two different places one in the network activity of the Settings apk where as the other is on Amazon Launcher itself.
Skel40 said:
My fault. I should've paid attention..
Click to expand...
Click to collapse
here is the patched version from the rom you provided.
try this one and make sure you have given correct permissions i.e. 644
SweenWolf said:
Thanks, I was reading other post on XDA where people are stuck with locked bootloader on 6.2.8.0, I do not do OTA updates, and I certainly don't update without assurance that my apps work fine on it. i was thinking of getting an image and make some changes by removing the efuse binaries from bin and also was thinking of unlocking ADB on Boot.img and if found removing efuse from there, the thing is i have to patch boot.img as my stick becomes unstable with TWRP. but for now I just wanted to go 6.2.7.3 and check if everything goes right i will stay on it else jump back to 6.2.7.1
Sorry for bothering you, what version introduced profile in FireTV?
Click to expand...
Click to collapse
People stuck with locked bootloader on 6.2.8.0 most likely never unlocked it before updating to 6.2.8.0.
Devices unlocked previously, before 6.2.8.0 are fine, unless you restore everything to stock, including boot, recovery, bootloader, and tz.
Also, as long as you keep TWRP (i don't know why you removed yours) then you are pretty safe, even if you install a full stock rom (TWRP has a failsafe mechanism which prevents flashing the critical images (recovery, tz, and bootloader).
As for modifying the boot image, there's not much to do, just disabling the efuse_check or anything efuse related from the ramdisk.
Pretoriano80 said:
People stuck with locked bootloader on 6.2.8.0 most likely never unlocked it before updating to 6.2.8.0.
Devices unlocked previously, before 6.2.8.0 are fine, unless you restore everything to stock, including boot, recovery, bootloader, and tz.
Also, as long as you keep TWRP (i don't know why you removed yours) then you are pretty safe, even if you install a full stock rom (TWRP has a failsafe mechanism which prevents flashing the critical images (recovery, tz, and bootloader).
As for modifying the boot image, there's not much to do, just disabling the efuse_check or anything efuse related from the ramdisk.
Click to expand...
Click to collapse
Thanks for the info, my stick randomly reboots itself if i have TWRP installed.
And File Manager of TWRP had no affect on the System partition (for me atleast)
And I also always has a pendrive attached with the stick with some movies and videos on it.
Which cause boot delay also because it waits for TWRP.
I upgraded to 6273 and there was no Accessibility, so i had to unlock the bootloader once again to go back to 6271.
I use many apps which requires Accessibility like and two main ones are for Launcher and for Mouse Services.
As i don't use google play services or make any changes to the system and with 6271 being last version to support Accessibility i decided to stick with it and just disable updates. And relocked the bootloader, because i had no use of TWRP anymore. Until now, if Accessibility is fixed i might upgrade.
But like you said, it burns the fuse when we update the TZ and that can only be updated by the recovery, TWRP will never update the TZ so we are safe, but even the stock recovery needs an update package to flash the TZ right?
Because of the script it will delete the efuse check and ewriter then it will not blow the fuse, Just like in OP.
Even if i then relock the bootloader, and the updates will be blocked to the system, because there are some update apps which sideloads the OTA package (i read their codes) then if their are no offline update file present in the system how will the stock recovery flash the TZ.
I'm just asking, i know amazon also has some tricks under their sleeves and they can do something notorious.
I confirm Accessibility works on 6.2.8.0 3236. Thanks @SweenWolf
I used Total Commander for chmod without commands too
Skel40 said:
I confirm Accessibility works on 6.2.8.0 3236. Thanks @SweenWolf
I used Total Commander for chmod without commands too
Click to expand...
Click to collapse
Good to hear, one more question. How have you disabled the OTA check, i was thinking of patching OTA files also
Related
http://forum.xda-developers.com/showthread.php?t=1847860
Do not use this, the posts below are just quoting from the HTC EVO 4G LTE section. For Dev's to look at to possibly get working for our S-ON DNA's... Kernel Flashing
All Credit goes to xHausx (this is all his work im just posting it here for our dev's)
xHausx said:
Now that the new hboot doesn't allow S-ON devices to flash kernels I went ahead and adapted this for the LTE. It's something I started for the Evo 3D back in January, but when a new way to get S-OFF was found I sat it aside and had forgotten about it.
When used it tries to flash the kernel like normal and doesn't do anything special if able to, otherwise it will copy a script to the system partition and install the kernel when the ROM tries to boot up. All that's needed is for a few lines to be added to the updater-script and it can do the rest.
I'll update this with more information at a later time, but for now I just want to say thank you to everyone who has helped contribute ideas and tested. As always, any help with improving it is welcomed.
How To Use It
This is mainly for ROM and kernel devs to use before releasing, but it can easily be added to any that don't normally use it. For more detailed instructions see Page 3.
Download and add the "kernel" folder to your update zip
Edit your updater-script and use the following when you are ready to install the boot.img
Code:
ui_print("Installing Kernel, please wait...");
package_extract_file("boot.img", "/tmp/boot.img");
package_extract_dir("kernel", "/tmp/kernel");
set_perm_recursive(0, 2000, 0777, 0777, "/tmp/kernel");
run_program("/tmp/kernel/install_kernel.sh", "/tmp/boot.img", "/tmp/bootready.tmp");;
ifelse(file_getprop("/tmp/bootready.tmp","kernel.ready") != "READY",(
ifelse(file_getprop("/tmp/bootready.tmp","kernel.ready") == "STARTUP",
ui_print("Kernel Will Be Installed On Startup."),
ui_print("ERROR: Kernel Not Installed!")
)
));
Sign the zip and it can then be installed like normal from any device with a custom recovery
Changes
v0.57
flashboot.sh - Fixed the case statement that verifies the kernel flashed properly
flashboot.sh - Moved the call for DD to save the old kernel so that it always gets used
Downloads/Sources
Kernel Folder on DevHost (MD5: 27eB86aae3562e147d86b8dfe7a04786)
Google Code
Github - All files including the flashboot binary source
Click to expand...
Click to collapse
xHausx said:
How Can I Test It With S-OFF?
If you comment out the dd command that writes the boot.img it will act like your device has S-ON.
Edit install_kernel.sh and change:
Code:
echo "-Trying to write the new boot.img and verify it's MD5"
$BBDD if=$BOOTPADDED of=$BLOCKBOOT; sync
rm -f $BOOTOLD
to:
Code:
echo "-Trying to write the new boot.img and verify it's MD5"
#$BBDD if=$BOOTPADDED of=$BLOCKBOOT; sync
rm -f $BOOTOLD
Where Are The Log Files?
In the recovery it uses: /tmp/recovery.log
On boot it uses: /data/local/bootinfo.txt
What Does This Need To Work?
A custom recovery
A valid kernel already installed with init scripts to start either /system/bin/app_process or /system/bin/netd
What Recoveries Does It work With?
Most of my testing has been done with TWRP, but it should work just as well with any other recovery
Why Did My Phone Reboot Back To The Recovery?
If it is unable to flash the kernel it will leave the old one in place and reboot back to the recovery. If you are able to, please pull the log file from /data/local/bootinfo.txt and send it to me so I can see what needs to be fixed.
What If I Get A Bootloop?
Either the kernel you flashed doesn't work with your ROM or there was an error and it's unable to reboot back to the recovery. If you hold volume down it should bring up the bootloader, from there use the volume and power buttons to select 'Recovery'.
Why Does My Phone Boot Straight To The Bootloader?
You either managed to wipe your boot partition (kernel) or sometimes this will happen when upgrading hboots. If you are S-ON you will need flash a new boot image from fastboot.
Click to expand...
Click to collapse
.torrented said:
http://forum.xda-developers.com/showthread.php?t=1847860
Do not use this, the posts below are just quoting from the HTC EVO 4G LTE section. For Dev's to look at to possibly get working for our S-ON DNA's... Kernel Flashing
All Credit goes to xHausx (this is all his work im just posting it here for our dev's)
Click to expand...
Click to collapse
It's in the works, I just sacrificed a tablet I dearly loved to get a DNA in the hands of a friend of mine who does a lot with developing aroma installer features, install scripts for devs, and has ported some s on kernel installers on other devices. I'm sure there's other guys working on similar things as well.
*** WARNING ***
Do NOT flash this on an H918, you will brick your phone.
This is for the AT&T H910 ONLY
Thanks to @toastyp for the dump of 10r.
Thanks to @askermk2000 for the kernel. Dude doesn't even have a V20 anymore, but he jumped in and helped when I lost my dev environment to build the kernel. That is what XDA is supposed to be about. Seriously man, huge thanks.
With that said, this is the v10r firmware + boot + system. For now, it is possible to dirty flash this, but if there are a lot of posts about problems, I will force a wipe in the zip since most people will be coming from 10m or even earlier (I think NATF is based on 10l, and I don't know what WETA is based on).
So, please, just backup your data and do a clean install
This is 100% stock v10r, bloat and all. It is ARB 0, so if you don't like it, you can go back to any older version.
This include v1.0 of the mk2000 kernel, please check his thread here for any updates.
Also, the 10r firmware doesn't work with 10m or lower system images -- 10p or 10q only. Since there are no custom ROMs currently that are based on 10p, 10q, or 10r, there is no reason to flash JUST the firmware without boot and system.
If you choose to dirty flash, then you MUST reinstall Magisk or SuperSU before rebooting. If you don't, then your data will be encrypted when the phone boots.
With the new firmware, the engineering aboot is able to init the screen correctly so the nasty warning message is clearly visible. This is the same warning as before, but it was garbled and you couldn't read it. Ignore it... your phone will boot.
Download here.
SHA: 5451146030393e490dcfba3558b620badefe75cd
-- Brian
Awesome work wi'll be trying this later
Awesome! Thank you!
runningnak3d said:
Thanks to @crackness for the dump of 10q before he rooted his device.
Thanks to @askermk2000 for the kernel. Dude doesn't even have a V20 anymore, but he jumped in and helped when I lost my dev environment to build the kernel. That is what XDA is supposed to be about. Seriously man, huge thanks.
With that said, this is the v10q firmware + boot + system. For now, it is possible to dirty flash this, but if there are a lot of posts about problems, I will force a wipe in the zip since most people will be coming from 10m or even earlier (I think NATF is based on 10l, and I don't know what WETA is based on).
So, please, just backup your data and do a clean install
This is 100% stock v10q, bloat and all. It is ARB 0, so if you don't like it, you can go back to any older version.
Also, the 10q firmware doesn't work with 10m or lower system images -- 10p or 10q only. Since there are no custom ROMs currently that are based on 10q, there is no reason to flash JUST the firmware without boot and system.
You will need to reinstall Magisk or SuperSU.
With the new firmware, the engineering aboot is able to init the screen correctly so the nasty warning message is clearly visible. This is the same warning as before, but it was garbled and you couldn't read it. Ignore it... your phone will boot.
Download here.
SHA: 6bbc1bc160baff3f44bd6b68b27b10324b0d087d
-- Brian
Click to expand...
Click to collapse
If I wanted to root, I could download this to my H91010q and go back to stock?
Apologies in advance if already obvious, but can someone on 10j or 10k flash this without first being on p or q?
The reason I ask is that you mentioned this "It is ARB 0, so if you don't like it, you can go back to any older version." and " 10q firmware doesn't work with 10m or lower system images -- 10p or 10q only."
My build number is NRD90M and my software version is H91810j.
I just want confirmation that this will work without me having to upgrade my firmware first.
Thanks for all your hard work!
@Jburd23 This does not root your phone. You flash this in TWRP if you are already rooted and want to upgrade to 10q.
@Quiksmage Yes, you can flash this no matter what version you are on. It includes system, so your current system will be wiped. It also contains the rest of the 10q firmware.
-- Brian
runningnak3d said:
@Jburd23 This does not root your phone. You flash this in TWRP if you are already rooted and want to upgrade to 10q.
@Quiksmage Yes, you can flash this no matter what version you are on. It includes system, so your current system will be wiped. It also contains the rest of the 10q firmware.
-- Brian
Click to expand...
Click to collapse
I should have also added the following. I can go back to a j based firmware after flashing this, correct?
It doesn't flash the modem/bootloader?
Sorry about the repeated questions, but I just want to be absolutely sure I don't end up in a place where I can't go back to the rootable firmware. Thanks
Nice to see some love for our v20, nice work.
Quiksmage said:
I should have also added the following. I can go back to a j based firmware after flashing this, correct?
Click to expand...
Click to collapse
Yes, you can revert to any older firmware. However, I don't know of any that was dumped. The H910 doesn't have a KDZ so the only way to get new (or older) firmware, is to have someone that hasn't rooted dump it.
If you are currently on 10j, then use the patched LG UP to dump your phone so that you will have a copy of the complete 10j firmware (minus an untouched system). At least that way you can flash back to it if you want. I only have dumps of 10m, 10p, and 10q. If you do dump your phone, please zip up the firmware and send it to me. You just need the files that are in this 10q zip.
It doesn't flash the modem/bootloader?
Click to expand...
Click to collapse
Yes it does. When a post says firmware + boot + system, the firmware is the bootloader, modem, hypervisor, trustzone, etc.... Boot is the kernel, and system is the actual Android install.[/quote]
Sorry about the repeated questions, but I just want to be absolutely sure I don't end up in a place where I can't go back to the rootable firmware. Thanks
Click to expand...
Click to collapse
Don't quite understand this question. You don't lose TWRP if you flash this, so you can root with Magisk again. Also, ALL H910 firmware is currently rootable. The H910 and the unlocked US996 are the last two V20s that can be rooted on the latest firmware.
-- Brian
Hey Brian, that was my fault. I thought I had read H918 v10q. The t-mobile variant cannot go back once updated past K. Apologies!
First post updated to 10r with mk2000 v1.0 kernel.
-- Brian
runningnak3d said:
Thanks to @toastyp for the dump of 10r.
Thanks to @askermk2000 for the kernel. Dude doesn't even have a V20 anymore, but he jumped in and helped when I lost my dev environment to build the kernel. That is what XDA is supposed to be about. Seriously man, huge thanks.
With that said, this is the v10r firmware + boot + system. For now, it is possible to dirty flash this, but if there are a lot of posts about problems, I will force a wipe in the zip since most people will be coming from 10m or even earlier (I think NATF is based on 10l, and I don't know what WETA is based on).
So, please, just backup your data and do a clean install
This is 100% stock v10r, bloat and all. It is ARB 0, so if you don't like it, you can go back to any older version.
Also, the 10r firmware doesn't work with 10m or lower system images -- 10p or 10q only. Since there are no custom ROMs currently that are based on 10p, 10q, or 10r, there is no reason to flash JUST the firmware without boot and system.
You will need to reinstall Magisk or SuperSU.
With the new firmware, the engineering aboot is able to init the screen correctly so the nasty warning message is clearly visible. This is the same warning as before, but it was garbled and you couldn't read it. Ignore it... your phone will boot.
Download here.
SHA: 5451146030393e490dcfba3558b620badefe75cd
-- Brian
Click to expand...
Click to collapse
You should really put a device check in the updater-script.... I couldve sworn this said H918 (8 and 0 look VERY similar on mobile), flashed it, full hard-bricked it.....
Qualcomm HS-USB QDLoader 9008
RIP
Tiny line in updater-script would have prevented this
Tilde88 said:
You should really put a device check in the updater-script.... I couldve sworn this said H918 (8 and 0 look VERY similar on mobile), flashed it, full hard-bricked it.....
Qualcomm HS-USB QDLoader 9008
RIP
Tiny line in updater-script would have prevented this
Click to expand...
Click to collapse
As much as I like and appreciate your work, you screwed up dude lol its ok to admit it
Sent from my LG-H910 using Tapatalk
@Tilde88 I did use an assert line at first, but I got tired of having to keep editing it and adding additional checks.
H910 || US996 || H915 || elsa || H910a
I am pretty sure that covers all the possibilities now, so I should probably put it back -- but at the end of the day, just have to be careful.
I could understand misreading the H910 on the forum post, but the zip file as well? That is an awful lot of seeing 8 instead of 0.....
I am sorry you toasted your device. Even if you bought it used, as long as it is still under the 2 year warranty, LG will fix it.
I am updating the first post with a big red warning....
-- Brian
runningnak3d said:
@Tilde88 I did use an assert line at first, but I got tired of having to keep editing it and adding additional checks.
H910 || US996 || H915 || elsa || H910a
I am pretty sure that covers all the possibilities now, so I should probably put it back -- but at the end of the day, just have to be careful.
I could understand misreading the H910 on the forum post, but the zip file as well? That is an awful lot of seeing 8 instead of 0.....
I am sorry you toasted your device. Even if you bought it used, as long as it is still under the 2 year warranty, LG will fix it.
I am updating the first post with a big red warning....
-- Brian
Click to expand...
Click to collapse
Lol I don't blame you at all. I flashed it, I did it. It will get repaired and I have other phones, so not a big deal. I meant it mostly for others. 2nd phone I brick in 10 years (other one was the HTC touch pro2 back in windows mobile days). I just hope there will be root for 10q in a few weeks, BC I'm sure lg will send a refurb with that.
As for the recovery, I saw the file and just flashed, who needs to read anyway lmao. /s
Anyway, thanks for your work. It flashed beautifully, and its a great way to update
Ok flashed and running decent. But twrp asked for encrypt password. Wasnt encrypted. I can get past it but its showing 0mb for internal storage. Anyone else get this? Any idea how to fix it? I flashed supersu but it wont install I'm thinking because of this error.
You flashed SuperSU before rebooting or after?
-- Brian
runningnak3d said:
You flashed SuperSU before rebooting or after?
-- Brian
Click to expand...
Click to collapse
The initial reboot? After. I went through setup and got everything done. Went back into twrp. Asked for a password to decrypt. I can hit cancel to get past it. Flashed supersu. Rebooted. No su app or root. I'm guessing because twrp thinks data is encrypted.
TWRP thinks your data is encrypted because it IS encrypted. If you don't flash SuperSU or Magisk before rebooting, then /data gets encrypted on the first boot. Now that it is encrypted, the only way to fix it is to format data in TWRP.
There is no way for you to back it up now either.
-- Brian
runningnak3d said:
TWRP thinks your data is encrypted because it IS encrypted. If you don't flash SuperSU or Magisk before rebooting, then /data gets encrypted on the first boot. Now that it is encrypted, the only way to fix it is to format data in TWRP.
There is no way for you to back it up now either.
-- Brian
Click to expand...
Click to collapse
Eh a wipe/format isnt the end of the world. Save my pics onto external and do it. Thanks for the help man and for the Rom. She is smooth. Btw I saw you thank askermk2000 for the kernel. Is that the same one as in a thread of its own? I was thinking of flashing his updated 1.1 version but if its the same I wont bother. Thanka again.
Important notice! : iLLNiSS made me aware of a serious risk!
If you play with the firmwares manually and not with the flash all bat then DO NOT flash the blobs!
These are the actual bootloader files and stuffing up here will cause a hard brick!
I have to stress this out as it is serious thanks to not having working APX drivers a flshing programs for the Shield!
For starters, I uploaded a copy of the 7.2 developer firmware here:
7.2 developer ZIP on Dropbox
It is the full 1.1Gb update and not the 422mb block based one.
I have done some extensive tests since the first block based update wrecked my rooted Shield.
Some of it will end up in this post as info for everyone.
But lets start with what seems to be the problem for a lot of users right now who run a rooted Shield : Fixing the problem
A downgrade is officially not supported by Nvidia but my tests showed it works just fine if you only go back to the 7.1.
So far my tests showed differen sources for a Shield no longer working after the OTA.
1. The device had an unlocked bootloader and you got the 422mb block update.
This would have stuffed your bootloader and the Shield won't go past 1/4 on the progress bar for the update.
You are in luck as just flashing the 7.1 bootloader will fix it.
After that just dismiss the update and change the settings to manual updates.https://forum.xda-developers.com/editpost.php?do=editpost&p=78466377
2. Your device was already fully rooted and you got the full update that resulted in your Shield doing all sorts of thing but nothing properly anymore.
As long as your apps are still there and the Shield is still somhow usable you are lucky again.
A downgrade to 7.1 will fix it, I will explain the steps required further down.
3. You made bid mods, used Magisk or other rooting tools and now your Shield complains that your system is corrupt.
Bad luck if your bootloader is locked as you loose it all.
Lucky if the bootloader is unlocked as you might be able to keep most if not all during the downgrade.
General words of warning:
Even if your bootloader was unlocked from day one I can not garantee that the downgrade will keep all settings, apps, databases and so on.
For me it works fine as I kept all vital databases on external storage.
The procedures are all based on the developer firmware, on the stock firmware some things can still be done but then again you should not have more than software problems.
On the stock firmware the bootloader is locked by default and you can use some things required to owngrade due to the restrictions of a stock system.
General downgrade procedure for the developer firmware to get back to 7.1 :
If the update did get stuck on the progess bar early on and a reboot won't fix it so you can dismiss the update you just follow the steps.
If you can reboot into the 7.1 then just dismiss the update.
Trust issues or curruption warnings at boot but an otherwise working shield on 7.1 require to flash the 7.1 bootloader again.
In some cases it is possible to skip the corruption warning with a connected controller.
A reboot once you got to the homescreen will determine how bad it is.
Reboot goes fine: You are good.
Reboot keeps nagging with warnings other than the unlocked bootloader: Downgrade.
The downgrade is only required if you have problems or the Shield already runs on the 7.2!
In almost all other cases just flashing the 7.1 bootloader is sufficient.
Fixing a stuffed Shield by sideloading the 7.1 firmware while keping all apps and things:
Enable USB debugging and allow the connections for the computer if you still have access to the settings.
Otherwise you need to flash the 7.1 fresh and might loose vital things that need to install again.
Reboot into the stock recovery, if you use TWRP flashed on the Shield already then please flash the recovery from the 7.1 firmware first.
Hook up the controller and pressing A or B should get you into the normal recover screen past the dead droid.
ADB sideload XXX - where the xxx stands for the filename you have for the developer ZIP.
After the rebbot you should be back on your 7.1 homescreen and can dismiss the 7.2 update.
Also change the update settings while at it
Fixing a fully stuffed Shield and then downgrading to the 7.1 firmware:
If all went down south then you tried a few things and realised there is no way to get your data back and even less to prevent the 7.2 update.
Installing the 7.1 from scratch forces the setup wizard and before you can get anywhere you need to update to 7.2
So much easier to use the linked 7.2 update from above until Nvidia provides it on their download servers.
A vital thing to do is to keep the bootloader locked!!
Same for NOT having TWRP installed on the Shield!
If in doubt flash the 7.1 boot and recovery partitions first then go back into the stock recovery and wipe the cache.
Coming from a stock developer firmware with just an unlocked bootloader you are good to go.
Sideload the 7.2 update.
Unplug when the reboot starts and go into fastboot to lock the bootloader: Fastboot oem lock.
This is a vital step as the new kernel otherwise could ruin the completion of the install.
Ignore the double hassles and go through the wizard so you can enter the settings again to enable the developer mode and USB debugging.
Unlock the bootloader so you can do it all again Last time I promise!
Once you have both the bootloader unlocked AND the Shield in a usable condition past the setup wizard:
Reboot into the recovery to sideload the 7.1 firmware.
After the next reboot you are back on the 7.1 homescreen drirectly and can dismiss the update.
Possible tricks that can help you to prevent the installation of the 7.2 update if you come from a fresh 7.1 install instead:
Don't allow the reboot and instead use ADB to reboot into the recovery.
Wipe the cache - this will remove the scripts required to start the update after the reboot.
The next reboot should bring you back to the homescreen where you can stop the new download of the update and change the update settings.
TWRP, full root and new security measures in 7.2:
The 4.9 kernel used also makes use of a Fstab configuration that no longer includes the system partition.
This and other restrictions currently make the normal use of Magisk impossible.
With no system partition available to Magisk the changes in the boot process come to a stop and the Shield gets stuck during boot.
The added restrictions also make it very, very hard to manually add SU and busybox.
At least without getting the currupt system popup on every boot and finding out that a lot of things still don't work properly.
A final 7.2 firmware is said to be available on the download servers today.
If this final is no different from the current OTA then it will not be of any use for users requiring a fully rooted devices.
With the stock recovery still using the old kernel all attempts to use recovery functions to alter the system for rooting fail as well.
Can't blame the company as all this is part of Google revamp og security and closing backdoors and loopholes for possible attackers.
Personally I think it is Googles way of keeping control over devices they don't actually own.
Anyways I did make some little progress:
Plans for the near future:
Security is good but I like to know what my Android devices are doing and especially what Google likes to collect if I can not find ways to stop it.
So I will not try to use any backdoors or secrurity vulnerablilites in the new kernel to allow a full root on my Shield.
I will go the route I know best: Manual labour
The bootloader is already fixed to allow what we are used to from previous developer firmwares.
As SU and busybox can not be manually entered at this stage I will try to include them directly in the stock 7.1 firmware while renaming the OTA updater to have it a bit easier.
Assuming that works as expected I will do the same on the 7.2 firmware and compare the corresponding scripts and so on.
If the standard SU still works on an "unlocked" 7.2 I should be able to adjust the Magisk ZIP accordingly to implement it into the bootloader.
Only need to figure out if Magisk then has enough rights to work and the system is still happy to accept the changes.
I noly have the 16Gb 2017 model to work with but since the bootloader seems to be same for all Shield models I think if it works then it should do so for all models.
In the meantime I hope the infos here will help some pople to get their shield back without the need to sent it in.
Update 25/12/18: I got TWRP working on 7.2
This is only true for the 2017 model though as I have only this for testing.
Currently creating a backup to the internal storage.
If the restore works then I will upload the new TWRP - for the said model only!
Give me a day or two to fix it for the other models too.
There is progress on the rooting front as well.
Created new scripts for my kitchen to be able to handle the new file_context thing.
A fully pre-rooted and totally unsecure (in terms of ABD, DM-verity and such) is already cooked, just did not dare yet to try it out as I have a real life job too.
As for the pre-rooted firmware:
Things have changed quite a bit with the new kernel in terms of "just adding SU or Magisk".
Magisk might see an update for this problem soon, SU however seems to tally fail on two levels.
So far I was unable to do a full install of the modded firmware.
Flashed all at once and the boot just hangs.
Bootloader, reboot, then the rest seems to work.
At least for the basic install of the system.
If I add SU and busybox the system still ends up with a corrup notice during boot and then it fails.
Tune in over the next few days for progress updates at the end of the thread.
Major developments will be added right here.
Just a matter of finding the last restrictions.
Once that is done Magisk should be possible as well.
Ok, TWRP boot fine, does a backup but fails to restore the system to a bootable state.
Will now check if at least installing a zip works.
Well, it did not, so TWRP has to wait a few more days
I edited post 3 with instructions on how to "unbrick" and go back to 7.1.
Update 27/12/18: A friend of mine found some intersting stuff.
A 7.2 firmware offering a pure Android without any TV stuff but also a full root possible.
I hope he will share his finding here soon or allow me post it all in his name.
For now lets just say: It really works if done the rght way!
Full write rights, installing Magisk modules and all.
All thanks to an undocumented flaw in the device security structures, so even without any hidden backdoors or such LOL
Update: Whiteak was so kind to provide a working root solution in post 36, please check it.
I can confirm it is working as promised.
So the credits for this one go to Whiteak and the credits for the idea and use of the DTB file to Zulu99 - great idea!
To prevent any problems I advise to perform a factory wipe after the install and before the first boot.
Switch to the stock recovery to do this then boot as normal an enjoy.
A complete firmware with the required mods is sitting on my PC just waiting for idiot behing the keyboard to figure out how to pack it properly for flashing.
Once that problem is sorted and also TWRP working again things will get a lot easier.
Annoying update:
I was not able to confirm my web findings on the 7.2 firmwares bootloader but it seems other devices running the same type of kernel and bootloader and a bit lost now.
AVB is fully implemented on the latest level.
(Again I am working on confirming or denying these findings!)
This means any alteration to vital parts of the system will fail with a corruption warning or worse.
Custom recovery access is limited if not fully restricted.
But even if it works you still need a firmware to flash that either is able to disable all this crap, hoping the bootloader alone will allow it, or
to hope Nvidia will provide a future bootloader update with these restrictions removed.
We can not downgrade the bootloader and even if there is some old one out there that would actually be flashable the risk is high to end with a brick anyway.
The DTB, at least in my tests gives us the required system wide write access but I have no information about the AVM verfified boot other than that Zulu99's firmware works.
But if it was compiled with the NVidia developer suite then it will be signed accordingly so the bootloader accepts it.
Could not find any info on how his firmware was actually created.
It gives me the hope though that once I have a fully working TWRP again that my modded 7.2 will work as expected and with no restrictions anymore.
Thanks for the info.
Edit: Will use this post to list options to recover the Shield is all seems lost.
As a result of far too much rom cooking and mods I needed a 100% working way to recover the Shield in case things turn very ugly.
So lets sum up what I define as very ugly when playing with firmwares:
1. Firmware installed but the Shield just hangs on the logo.
2. Firmware installed and now the system is corrupt and even it is boots it takes forever to get around the nag screens.
3. Firmware downgrade attempted but now the Shield won't even boot anymore.
4. Anything that would qualify for a soft brick.
My worst case when I only got a flashing white screen after trying to restore a TWRP backup under 7.2.
There any many way that work for a variety of boot problems but it takes too long to list all cases I encountered with a list of fixes that work or a comment that only the below way works.
So just to be clear here: This is not for any recovery purpose other than fixing what can't be fixed through a factory reset or fresh flashing of the firmware!
1. Get the Shield into Fastboot mode: Connect wired controller and male to male USB cable.
2. Power the Shield up while holding A and B on the controller.
Keep holding until you see the fastboot menu on the screen.
3. Install the 7.1 recovery firmware for your Shield type after unpacking it.
With Fastboot connection working type: flash-all.bat and hit enter.
4. Keep an eye on the progess!
5. Once the Shield is finnished and reboots, hold the A and B buttons on the controller again to enter fastboot mode!
Do not let the Shield boot up other than into the fastboot mode!
6. Lock the bootloader! Fastboot oem lock
Confirm with the controller, then go down and select the recovery kernel.
7. Once the dead droid is on the screen press B on the controller to enter the real recovery.
If B does not work try A
8. Select the factory reset option to wipe all!
9. Once the wipe is done you can boot into 7.1 as normal again.
10. With a bit of chance you might even get directly to the homescreen if the previous setup was completed.
If you need the full seup wizard again and are forced to update to 7.2 then at least the update will work fine this time around.
In case you desire to go back to the 7.1:
If you just finnished the above only to end with the 7.2 then set it up and flash the 7.1 - you won't get the setup wizard again and can skip the update.
If you are on a working 7.2 that was update the OTA way but want to go back:
1. Install the 7.1 firmware.
2. Lock the bootloader.
3. Boot and then skip the update to 7.2.
Any idea what to do if the Shield sticks at the NVidia logo when you select Recovery from Fastboot? I reflashed boot and got the same result.
psycho_asylum said:
Any idea what to do if the Shield sticks at the NVidia logo when you select Recovery from Fastboot? I reflashed boot and got the same result.
Click to expand...
Click to collapse
It won't work from fastboot.
Fastboot operates on a different level and calling the recovery from there lets it end up in nowhere with no access to the system.
You need to boot into recovery through ADB as (for the new model) without a power button and usable hardware buttons we can't get into it otherwise.
Having said that, the fastboot way should still work with an unmodified bootloader.
When the dead droid is on the screen the recovery should be available after pressing the A button on the wired up controller.
But during my tests on 7.2 it did not always work, so you might have to try a few times and also try the B button.
Downunder35m said:
It won't work from fastboot.
Fastboot operates on a different level and calling the recovery from there lets it end up in nowhere with no access to the system.
You need to boot into recovery through ADB as (for the new model) without a power button and usable hardware buttons we can't get into it otherwise.
Having said that, the fastboot way should still work with an unmodified bootloader.
When the dead droid is on the screen the recovery should be available after pressing the A button on the wired up controller.
But during my tests on 7.2 it did not always work, so you might have to try a few times and also try the B button.
Click to expand...
Click to collapse
I have not been able to get to the dead droid screen.
Downunder35m said:
For starters, I uploaded a copy of the 7.2 developer firmware here:
7.2 developer ZIP on Dropbox
It is the full 1.1Gb update and not the 422mb block based one.
(snip)
Click to expand...
Click to collapse
Thanks for posting this, but please note that this firmware is only for the 2017 16GB model and cannot be used with a 2015 or Pro model.
I just got a 7.2.1 update that forced me to update. Wouldn't give me an option to skip it... As soon as I turned on my Shield, it said something about the 7.2.1 update and then rebooted and installed.
I was holding off on updating too so I didn't lose root. Now I'm unrooted and am unable to get Magisk working again until I can get my hands on a 7.2.1 bootloader... Bleh.
Weird, I am not getting the 7.2.1 at all here.
And since yesterday the OTA only tries the block based but not the full image.
AthieN said:
I just got a 7.2.1 update that forced me to update. Wouldn't give me an option to skip it... As soon as I turned on my Shield, it said something about the 7.2.1 update and then rebooted and installed.
I was holding off on updating too so I didn't lose root. Now I'm unrooted and am unable to get Magisk working again until I can get my hands on a 7.2.1 bootloader... Bleh.
Click to expand...
Click to collapse
I was able to downgrade using the 7.2 image after setting up the device on 7.2.1 OTA just make sure you disable automatic updates
Thanks downunder this kind of in-depth info is always appriciated man........i like to learn these kind of things, having bits here and bits there gives a better picture of the whole, while also giving us upto date current info.
Thanks for taking the time to write this :good:
---------- Post added at 07:35 AM ---------- Previous post was at 07:27 AM ----------
Edit
Hi downunder, could you confirm i have this correctly
With no access to fastboot thus no twrp or root, are you implying, assuming your able to inject root into stock firmware, that, i'd be able to flash this stock+root rom in STOCK recovery, which i do have access to?
Edit: im under the impression that stock firmware zips are checked by stock recoveries, so modifying a stock firmware zip tends to fail this check and thus wont install/flash.......which makes me think im misunderstanding here......or just hoping im not
If so, im interested
Edit
i just read your second post which near enought answers my curiousity, so that'll teach me to read beyond the first post before asking answered questions ........even if the post excites me............ahhh, who am i kidding, ill probabably do it again........the equivelancy of a mental post boner........not controllable
Sorry for the disgusting analogy
SyberHexen said:
I was able to downgrade using the 7.2 image after setting up the device on 7.2.1 OTA just make sure you disable automatic updates
Click to expand...
Click to collapse
Did I understand it correctly? You successfully downgraded from 7.2.1 to 7.2?
ErAzOr2k said:
Did I understand it correctly? You successfully downgraded from 7.2.1 to 7.2?
Click to expand...
Click to collapse
Yes,
Just ran flash all from the bootloader. For the newly released 7.2 developer_rooted factory image.
As long as we don't jump to Android 9 we should always be able to downgrade through a full factory firmware.
Once Android 9 comes this might not work anymore due to the massive changes involved for the boot and system checks.
@banderos101: Unless you really did something bad you should always be able to enter the fastboot mode to flash a full firmware.
If I have some time after xmas I will have another look on the options of signing the zip properly or simply to fake it.
Biggest problem will be to generate the corret SHA checksums ince all is installed so I can use the same checksums in the check files.
The bootloader needs them to identify the system and vendor as genuine.
The system needs them to confirm all is actually unmodified as otherwise all fails to boot at some stage.
Modding a proper userdebug firmware is not really that hard, but converting a release version that also is a true and secure user release...
Lets just say that it won't be an easy task.
As it looks like the kernel is a keeper I might have to figure something out unless TopJohnWu won't enjoy a break after his exams and works on a way to get Magisk working with out kernel.
At least I figured out why the recovery trick isn't working for me.
The system partition is not mounted for the sideload mode.
To apply an update the stuff is written directly onto the partition, so no file level access left to play with and break things
In comparison you could say the shield is now like a modern car with keyless operation only.
You know you can start it with ease, if you only could the remote that you left in the drivers seat when you locked the door
SyberHexen said:
Yes,
Just ran flash all from the bootloader. For the newly released 7.2 developer_rooted factory image.
Click to expand...
Click to collapse
Just wondering what is achieved by going back to 7.2?
What do you mean "going back"?
Right now the 7.2 is the official and latest firmware.
I was unable to get my hands in the 7.2.1 but guess it might have been a testversion for certain models only.
I wasted a few hours trying to fix the system image.
First stage was only to get the basic "features" back, like full ADB support, enabling the support to use SU and busybox....
Just what is required to actually allow these nice apps we like to gain root to work.
This backfired badly as right after the start the bootloader complained about the system being corrup and no override to get past this worked.
So of course I then removed the known restrictions from the bootloader...
As you guessed it the damn thing then did not even boot at all, just jumped right into the (locked) recovery mode.
A half decent comparision with my last manual root on a tv box that was a success showed I still did the right things...
If anyone wondered why we needed a new bootloader for the support of smart helpers an some codes stuff:
We didn't as all this could have been done with the 7.1 bootloader as well.
Since my root attempts so far all ended either in disaster or in a root access that failed shortly after/corrupted the system, I took a look of the general kernel changes that were published for other devices.
Before I could find anything meaningful I realised the 4.9 kernel is actually a requirement for Android Pie!
With that info sorted I started digging inti the new "security" features Pie can offer.
I will try to keep it simple and to the stuff that actually concerns us for rooting purposes:
The new boot process with Pie is aimed at being secure from the hardware level up and all the way into the system partion once the boot is completed.
So the hardware checks if the bootloader is actually usable - we had that for a long time, nothing new.
Once the bootloader starts and reaches the point of actually getting somewhere, all partitions required will be checks by either a hash check or a trusted certificate gererated at boot time that is compared to the previous certificate.
Only if that is fine the bootloader will call upon the system and vendor partitions.
The handover of control from bootloader to the system is made far more secure as well.
SELinux is called early on to ensure that only trusted apps and tasks can work but also to all a new control level.
System related apps no longer run as root or with special permissions.
Instead every single app and service runs as its own user!
And under SELinux conditions this means nothing can access anything that it is not entitled to unless included as a user for the other app.
And with that sorted the vendor stuff is called to ensure all hardware and vendor related stuff is still genuine - this include the required certs but also the recovery and bootloader hash codes and certs.
So if something is fishy either SELinux will stop us or the vendor stuff will just overwrite it all.
Once we finally reach the system stage the recovery is checked if called from within the system, if fully implemented it could mean that using an official update on a modded firmware will delete all data as the encryption from the old system is declared invalid.
Sadly it does not stop there because even with full rigths (faked or otherwise) to access the system partition with write access we still can not just change things.
If something belongs to a user (a secure app) than a change will corrupt the system.
To overcome all this without using vulnerabilities that so far no one has found, a compatible userdebug release has to be created from the official user firmware.
DM-Verity needs to be disabled as well as all partition encryption stuff.
The bootloader needs to be adjusted to reflect these changes and the required turst certificates generated and included in both system and boot images.
The only problem here is that the kernel won't allow these changes unless it itself is a userdebug kernel.
After that it is only the little efford to go through about 60 different scripts to remove or redirect the calls for all boot and system security related things.
If then by some chance all this actually boots up and goes all the way into a usable homescreen the entire stuff needs to be secured again.
This time so that the final system has a correct cert and checksum that matches those we need to include in the bootloader.
Anyone knows how to gain full access to the trusted keystore on the 4.9 kernel? LOL
For the moment I don't really care about all the stuff above.
I would be happy to figue out what to make out of these new fstab configurations without the vital partitions listed.
The real aprtitions used have not changed but it is impossible include them in the fastab, doing so causes the bootloader to fail.
Presumably because the kernel realised we try to get around the verification process.
This and some other minor things are also the reason TWRP fails so badly, same for the stock recovery by the way.
Since TWRP is toy a lot us like:
TWRP and 7.2....
Without a system partion in the bootloader fastab TWRP can not mount it.
Same for all other things TWRP needs to mount as it simply does not have the right to access these areas.
To make things worse, we need system access to even start TWRP through fastboot.
So, now matter if we flash or start it through fastboot: The bootloader and system will realise our recovery does not match the checksum.
What does al this now mean in terms a lot more people are able to understand?
Let me try...
Imagine the 7.2 in a running version would be just some encrypted file with a lot of folders in it.
And like PGP or other encryptions software we know there is a private and a public key.
With the public key you can see a lot and use most the encrypted file - but only to a level that is required, nothing above your low level clearance.
For every attempt to write into this file or to make changes we need the private key.
If you follow so far then lets just say the recovery (stock) and Fastboot can be, to some extent, used for this access.
But since every folder in the encrypted file also uses private and public keys it is like tracing a tree.
Although it is getting too long, let me give you the example of just adding SU to the sytem partition:
Adding SU into the system image is no big deal.
Singing this image to get a usable key and including this key into the keystore is.
Assume we would just be able to do it....
SU needs to be called quite early in the boot process.
It then elevates the access level for certain things and also intercepts all root related requests from apps and services.
Except of course those that already had these rights by default.
Problem here is that adding the scripts we need plus changing some others means violating the tree of trust on the device and we get locked out.
Finding a spot to add the required rights for SU might be still possible.
On the other hand it will be impossible to give SU any rights or access to "trusted user" owned parts, files, folders, partitions....
The entire concept of SU just fails.
I will have to check how much of the new features are active in the 7.2 kernel that hinder us.
If I find enough it might be possible it enough to call for a Magisk update.
But I guess it is of little use for just one set of devices, so maybe once more devices on the 4.9 kernel fail to work with Magisk it will be easier to spot a usable pattern.
In case someone else if already working ona mdified system: Please let me know how you made it boot after the changes
Shield Tv 16 2017 - OTA update 7.2.1 Ready for updating
Im on 7.1. I have been waiting for 7.2 developer image, which is now out and just noticed 7.2.1 is available OTA. I'm really confused what to do. I want to keep root without bricking my Shield. Should I Stay with what I have as it is running well.
I am not even sure if it is safe trying to update to dev 7.2 image (or if I would want to) by hooking to computer and using ADB Fastboot tools.
Is there any good reason to update to 7.2 or 7.21? and if so how would I go about doing it? Which program is good for flashing developer images or OTA updates. I used to use flash-fire, which seems to be obsolete now and have heard TWRP is incompatible rooting with SU with OREO updates????
Should I play it safe and stay with what I have rather than experiment and end up with a brick? (wouldn't be the first time)
Anyone know if 7.21 is some-kind of bug fix?
Alot of questions but hope someone has some answers.
Thanks for any info.
"You know you can start it with ease, if you only could the remote that you left in the drivers seat when you locked the door "
My fastboot issue
Yeah, i think i busted the microusb somehow with a faulty usb hub, whenever i plug the usb to my raspberrypi/windows box(for adb/fastboot) now, it turns off all usb ports on the pi aswell as the windows box, even when the shield is unplugged, some sort of earth problem maybe
......all i have is adb over network, adb reboot bootloader simply reboots back to system, adb reboot recovery works though.
ive read that fastboot over tcp(ethernet) had been introduced a couple of android versions ago, but i dont think its been implemented in our shields
infact heres a link
https://www.androidpolice.com/2016/...-capabilities-wireless-flashing-isnt-far-off/
Looks like it needs to be specifically added onto a build
As far as you making a stock root build, if you can, that would awesome, more then awesome, but if it becomes more work then you thought dont worry about it, its not like their making it easy
Also, sounds like 4.9/future android is gonna be a nightmare for root......... having the ability to root so that the option is there to see whats going on in the background of these devices, these devices posessing cameras/microphones/old+latest sensors/personal files/personal info, which reside on our personal beings or in our homes........is just one reason why i dont want to see root go away
So what is the purpose of the developer image of 7.2?
Rather, I know the stated purpose of the developer image, but if it is locked in the way described it sounds like the benefit is negated for typical developers.
(e.g. sometimes I debug an application without permissions in order to benchmark or debug a problem).
For casual users of the shield, using ad blockers and whatnot, is there any benefit to derive from installing the developer rom over stock? Does "adb root" still work?
What is left as the difference. It doesn't sound like they produced a userdebug build of the OS.
Thanks
The 2 new updates are horrible. I have gone back to 7.1. They have crippled my shield. I'll wait for a new update.
As usual, this WILL void your warranty and I am NOT responsible for anything you do with this. Installing it properly won't brick your Fire TV, but doing stupid things with it might.
First, you must be unlocked. You can follow the instructions here for making that happen.
If you are first starting, you should first unlock, then install this ROM, and THEN install Magisk for root or any other addons. This rom uses addon.d to preserve Magisk and any other addons, but any system modifications like Magisk, gapps, etc, that you have installed prior to this ROM will NOT be preserved.
If you've already unlocked and installed Magisk, then after installing this ROM you need to reinstall Magisk in TWRP.
Starting with 6.2.6.6, Magisk is always installed.
Beyond that, Magisk and any other addons will be preserved as you flash newer roms. Consequently, if you would like to remove root, you will need to wipe /system in TWRP prior to installing this ROM. That will prevent it from being restored when installing the ROM.
Thanks to @k4y0z and @xyz` for the unlock.
NEVER FLASH A STOCK ROM >= 6.2.8.0 AFTER FLASHING 6.2.8.1_r2 OR LATER! THIS WILL BLOW AN EFUSE.
Changelog and Downloads:
October 24, 2021 - 6.2.8.1_r3 (md5sum: 3795edc2d640932a88da39da8a0811c5)
July 17, 2021 - 6.2.8.1_r2 (md5sum: e9e37a2d485a3397df041938818421e9)
This includes updated tz firmware to fix the device locking up when trying to play video.
April 3, 2021 - 6.2.8.0_r1 (md5sum: 2efdfc5728caba2953a351a082023a59)
December 26, 2020 - 6.2.7.7_r1 (md5sum: b835e29bb29458004063121a422c1bf7)
May 3, 2020 - 6.2.7.1_r1 (md5sum: 56ec885e5bd258682c90e8f08371301d)
November 10, 2019 - 6.2.6.8_r1 (md5sum: 8cdc16239df36c8640004232918c5477)
October 19, 2019 - 6.2.6.6_r1 (md5sum: df8f3d033fddf66a1b4aa3a6b228196b)
Starting with this version, Magisk will always be installed.
This includes updated tz firmware to fix LICENSE_ERROR with Prime video.
October 13, 2019 - 6.2.6.5_r1 (md5sum: bdde0303d8db5495ac6dc2aaf476d2f4)
Awesome!! Thanks!!
@rbox,
Quick question,
Initial unlocking and rooting was successful. However, I did what I usually do which is update Magisk using the manager and after the reboot, it is looping @ the amazon image. Any idea?
vasir13 said:
@rbox,
Quick question,
Initial unlocking and rooting was successful. However, I did what I usually do which is update Magisk using the manager and after the reboot, it is looping @ the amazon image. Any idea?
Click to expand...
Click to collapse
From the unlock page:
Important information
Don't flash boot/recovery images from FireOS (FlashFire, MagiskManager etc.)
rbox said:
From the unlock page:
Important information
Don't flash boot/recovery images from FireOS (FlashFire, MagiskManager etc.)
Click to expand...
Click to collapse
Yes .... I know ... called selective reading .... I got into TWRP and will try your image now ...
Happy to see the pre-rooted roms from you on mantis! It's starting to feel like the good old days again
Thank you, I feel safer already.
Any idea what version of gapps would work on this? Also, any idea if installing nanodroid, patched playstore & patching the ROM for signature spoofing be dangerous (as in bugger up the BL/TWRP)?
Awesome. This community is great.
Does this work for european (Italian) Sticks? (Prime video, Alexa etc etc).
Regards and Thanks a bunch!
Hi,
I successfully installed the hacked bootloader and TWRP a few days ago, but I did not do anything else. I was still on the original 6.2.5.8 version.
Today I wanted to flash the prerooted 6.2.6.5 and I can't manage to boot it (and since I did not expect problems, I did not make a backup of the old system). I cannot go past the "firetv" boot logo and in this stage "adb logcat" is not yet working, so I don't see any logs.
First boot was just installing the ROM. Second boot with previously wiping Cache / Dalvik. Finally I wiped also data (and Cache/Dalvik again). I cannot get past the boot logo.
So what can I do? Was there a firmware update between 6.2.5.8 and 6.2.6.5, which I need and is not included in the prerooted image? I'm just guessing since I cannot explain anything else...
Thanks Tim
tehlers said:
So what can I do? Was there a firmware update between 6.2.5.8 and 6.2.6.5, which I need and is not included in the prerooted image? I'm just guessing since I cannot explain anything else...
Click to expand...
Click to collapse
Have you compared the md5 of the download (push the md5file + ROM and let TWRP check this during install)?
Sus_i said:
Have you compared the md5 of the download (push the md5file + ROM and let TWRP check this during install)?
Click to expand...
Click to collapse
Yes, I have checked MD5 on my notebook after download, but not after pushing the file to the stick. I will do that now and post it here (with edit). But I doubt this being the issue.
EDIT: MD5 of the zip in the stick is also ok.
tehlers said:
EDIT: MD5 of the zip in the stick is also ok.
Click to expand...
Click to collapse
Ok. The prerooted Rom should be a full stock update, rbox said that a few days ago.
Any hardware damages or missing parts on your stick?
Edit: Have you flashed the magisk.zip behind the ROM?
Sus_i said:
Ok. The prerooted Rom should be a full stock update, rbox said that a few days ago.
Any hardware damages or missing parts on your stick?
Click to expand...
Click to collapse
The hardware is fully ok. The installation of hacked BL worked very smoothly and the stick did work with the original firmware until I flashed the prerooted one today. I have two guesses, but I don't know how to proceed:
1. I know there are sometimes firmware updates on specific fire OS versions, which need to be installed for later versions (for example version 5.2.6.7 on fireTV 2 [sloane]). So if I need a firmware update for 6.2.6.5 (from 6.2.5.8) I should probably flash 6.2.5.8 back and let the fire OS do the first update.
2. Or there is something left from the old version (in one of the partitions) which prevents this version from booting. This would mean that you need to be already on 6.2.6.5 (or at least on a higher version than me), that this ROM works.
In both cases, I would probably recover when getting the original firmware version 6.2.5.8 from somewhere.
EDIT: As I said in the first post, I did not do anything with the original ROM, except flashing the hacked BL and TWRP, no Magisk or whatever.
Best
Tim
tehlers said:
The hardware is fully ok. The installation of hacked BL worked very smoothly and the stick did work with the original firmware until I flashed the prerooted one today. I have two guesses, but I don't know how to proceed:
1. I know there are sometimes firmware updates on specific fire OS versions, which need to be installed for later versions (for example version 5.2.6.7 on fireTV 2 [sloane]). So if I need a firmware update for 6.2.6.5 (from 6.2.5.8) I should probably flash 6.2.5.8 back and let the fire OS do the first update.
2. Or there is something left from the old version (in one of the partitions) which prevents this version from booting. This would mean that you need to be already on 6.2.6.5 (or at least on a higher version than me), that this ROM works.
In both cases, I would probably recover when getting the original firmware version 6.2.5.8 from somewhere.
Best
Tim
Click to expand...
Click to collapse
OK :good:
Have you installed the magisk.zip behind the rom? May be it won't start without that? You may try that...
May be that dm-verity and/or SELinux enforcing is a problem without magisk, as magisk take care of that automatically...
No mouse Emulator support in TWRP with the 4K stick?
How do you install the rom if you don't have USB OTG cable?
Sus_i said:
OK :good:
Have you installed the magisk.zip behind the rom? May be it won't start without that? You may try that...
May be that dm-verity and/or SELinux enforcing is a problem without magisk, as magisk take care of that automatically...
Click to expand...
Click to collapse
Yes, that's it. Magisk needs to be installed after the "prerooted" image! Now the stick boots up!
Amazing, thank's!
I thought a prerooted image is prerooted.
@rbox: It would be nice, if you could mention this in the first post.
T1inkering said:
No mouse Emulator support in TWRP with the 4K stick?
How do you install the rom if you don't have USB OTG cable?
Click to expand...
Click to collapse
for example with ADB / TWRP Commands, something like that...
Code:
adb push ~/Desktop/mantis-6.2.6.5-rooted_r1.zip /sdcard/
adb push ~/Desktop/Magisk-v19.3.zip /sdcard/
adb reboot recovery
adb shell
twrp install /sdcard/mantis-6.2.6.5-rooted_r1.zip
twrp install /sdcard/Magisk-v19.3.zip
twrp wipe cache
twrp wipe dalvik
reboot -p
tehlers said:
Yes, that's it. Magisk needs to be installed after the "prerooted" image! Now the stick boots up!
Amazing, thank's!
I thought a prerooted image is prerooted.
@rbox: It would be nice, if you could mention this in the first post.
Click to expand...
Click to collapse
It is mentioned.. but not thats an issue without flashing magisk
Sus_i said:
It is mentioned.. but not thats an issue without flashing magisk
Click to expand...
Click to collapse
That's what I mean. It's not mentioned that you need Magisk in any case (to boot the image as such *and* probably also to get root [which is not prerooted then?]).
Thanks again!
puppinoo said:
Awesome. This community is great.
Does this work for european (Italian) Sticks? (Prime video, Alexa etc etc).
Regards and Thanks a bunch!
Click to expand...
Click to collapse
I reply to myself and happy to confirm I installed this "generic" image to my US Stick 4K and after I accept terms of use *Italian* Alexa and Prime video seem to wotk fine.
If I remember well my previous image was the 6.2.5.8 (basically the one I installed when the exploit for Fire TV Stick 2 (Tank) was released but can't be 100% sure.
Now I have to try it on my *Italian* Stick 4k (bought on amazon.it).
Amazing and thanks a lot again.
Puppinoo.
So great to see @rbox 'es prerooted roms for the Fire TV Stick 4k
There are some things that I am not familiar with:
1. What is magisk for and what if I don't install it?
2. Does root not work without magisk?
On the older Fire TV Devices we did never have to install magisk or so and it was prerooted with rboxes roms and root was working. Why is everybody talking about magisk? Can magisk break anything or be critical like xposed was on the Fire TV 2 box? I remember that xposed framework was a pretty messy issue for recent Fire TV 2 (Sloane) pre-rooted roms. Magisk seems to go deeply into the system, similar to xposed framework, isn't it?
Hi everyone,
Got my RedMagic 7 today. Rooting was straightforward with Magisk 23. I have the patched boot.img in the Android Device Database - http://NewAndroidBook.com/ddb - in case anyone wants. Apparently, "Fastboot boot ..." won't be recognized, so you'd need "fastboot flash" of this image.
(Note that rooting voids warranty, etc, and also might interfere with fingerprint scanner and/or TrustZone applets)
morpheus______ said:
Hi everyone,
Got my RedMagic 7 today. Rooting was straightforward with Magisk 23. I have the patched boot.img in the Android Device Database - http://NewAndroidBook.com/ddb - in case anyone wants. Apparently, "Fastboot boot ..." won't be recognized, so you'd need "fastboot flash" of this image.
(Note that rooting voids warranty, etc, and also might interfere with fingerprint scanner and/or TrustZone applets)
Click to expand...
Click to collapse
Hello! Thx for posting this info. I have a few of questions. Can you post a simple set of instructions on how to apply this root? I have never rooted a Nubia device before but I want to root this. Will the flashing of the boot image require the bootloader unlock? Might you know if the viper4Android is working from the modules install in magisk? Thx in advance for any info you may be able to provide!
RngrYogi said:
Hello! Thx for posting this info. I have a few of questions. Can you post a simple set of instructions on how to apply this root? I have never rooted a Nubia device before but I want to root this. Will the flashing of the boot image require the bootloader unlock? Might you know if the viper4Android is working from the modules install in magisk? Thx in advance for any info you may be able to provide!
Click to expand...
Click to collapse
Also using your method would it require a user data wipe?
RngrYogi said:
Also using your method would it require a user data wipe?
Click to expand...
Click to collapse
yes, of course. it's like any standard boot loader unlocked. Which is why you do it first thing when you get the device.
Edit: I didn't see the question how to apply it -
just OEM unlock the device, and then
adb reboot bootloader
(wait for it too boot to boot loader)
fastboot flashing unlock
(accept unlocking voiding warranty, etc by pressing volume down and power)
fastboot flash boot <the boot.img>
Note that they don't recognize "fastboot boot" , which is my favorite way of rooting since it leaves the original image intact - and thus flashing is irreversible unless you get the stock OTA at a later time and flash it over. But this will not bring back the warranty and warnings.
morpheus______ said:
Hi everyone,
Got my RedMagic 7 today. Rooting was straightforward with Magisk 23. I have the patched boot.img in the Android Device Database - http://NewAndroidBook.com/ddb - in case anyone wants. Apparently, "Fastboot boot ..." won't be recognized, so you'd need "fastboot flash" of this image.
(Note that rooting voids warranty, etc, and also might interfere with fingerprint scanner and/or TrustZone applets)
Click to expand...
Click to collapse
greetings bro thanks for sharing the vbmeta.img file? didn't you use it?
few questions:
1. were did you find the stock firmware to pull the clean boot.img? Can you link it, I would like to have a backup if anything goes wrong
2. Is the patched boot.img for the North American Version?
So to lpedrot: Didn't need a vbmeta.
To superrama: Since it's the kernel, the CN/US/etc versions don't matter. That's handled at a much higher level of Android build, which is user mode. So same boot.img can be used anywhere (which btw is true in all cases - boot.img s only have kernel + Ramdisk anyway)
1. I found the original by looking for NX679 OTA . It was a rather large OTA payload.bin, which I used my imjtool to unpack the boot.img from. Don't have the link handy now, but I can probably dig up the payload.bin and put it in a link since I have it stored somewhere.
morpheus______ said:
So to lpedrot: Didn't need a vbmeta.
To superrama: Since it's the kernel, the CN/US/etc versions don't matter. That's handled at a much higher level of Android build, which is user mode. So same boot.img can be used anywhere (which btw is true in all cases - boot.img s only have kernel + Ramdisk anyway)
1. I found the original by looking for NX679 OTA . It was a rather large OTA payload.bin, which I used my imjtool to unpack the boot.img from. Don't have the link handy now, but I can probably dig up the payload.bin and put it in a link since I have it stored somewhere.
Click to expand...
Click to collapse
nice, thanks for the quick reply
morpheus______ said:
Hi everyone,
Got my RedMagic 7 today. Rooting was straightforward with Magisk 23. I have the patched boot.img in the Android Device Database - http://NewAndroidBook.com/ddb - in case anyone wants. Apparently, "Fastboot boot ..." won't be recognized, so you'd need "fastboot flash" of this image.
(Note that rooting voids warranty, etc, and also might interfere with fingerprint scanner and/or TrustZone applets)
Click to expand...
Click to collapse
On which rom you use it? Aparently its taken out from a Ianuary rom, latest being v2.32 afaik
Just whichever random firmware image I found. But you're overlooking one major thing which is - the kernel barely, if at all, changes between firmware versions . You can use this book image with any other firmware image of any date, earlier or later, and there's no reason why it wouldn't work. The Android OTA images are user mode, this is just the kernel + Ramdisk - and so are largely independent of each other. Only exception would be if there's some kernel vulnerability in that particular version of the kernel, which as far as we know now - there isn't.
Hi, thanks for the guide. I did the steps to unlock bootloader and do flash your provided boot.img.
They both worked successfully but not sure if the boot img did anything.
I have the chinese phone and I want to convert it to global. Going to the settings and choosing the local update file provided by the official website doesn't work.
Any tips?
LeonFresh said:
Hi, thanks for the guide. I did the steps to unlock bootloader and do flash your provided boot.img.
They both worked successfully but not sure if the boot img did anything.
I have the chinese phone and I want to convert it to global. Going to the settings and choosing the local update file provided by the official website doesn't work.
Any tips?
Click to expand...
Click to collapse
”we” have a telegram channel for RM7 users, join since most of them don't use XDA anymore and you'll get faster help here
D1stRU3T0R said:
”we” have a telegram channel for RM7 users, join since most of them don't use XDA anymore and you'll get faster help here
Click to expand...
Click to collapse
Rooting != Image locale change. To do an image locale change you need to get the device image for whichever locale you want (if you can find it) and then apply the usual Magisk method.
D1stRU3T0R said:
”we” have a telegram channel for RM7 users, join since most of them don't use XDA anymore and you'll get faster help here
Click to expand...
Click to collapse
Hi I just joined the TG but got banned any chance of unbanning me?
User is Indiana_Gems on TG I'm looking to change my RM7 CN to global
morpheus______ said:
Rooting != Image locale change. To do an image locale change you need to get the device image for whichever locale you want (if you can find it) and then apply the usual Magisk method.
Click to expand...
Click to collapse
Thanks, I thought the two was related. I can't find any of the img files, which is why I'm stuck I guess. For older versions of the phone like Red Magic 5 they exist.
If they don't exist, is there a process to make one? Or do I have to wait
LeonFresh said:
Thanks, I thought the two was related. I can't find any of the img files, which is why I'm stuck I guess. For older versions of the phone like Red Magic 5 they exist.
If they don't exist, is there a process to make one? Or do I have to wait
Click to expand...
Click to collapse
There is a long and painful process to make one, and it's not guaranteed to work. I'll explain:
If a given vendor (in our case, Nubia, but this applies to others as well) adheres to Google's specification their /system partition should effectively be identical to that of all other Android devices (of same version). The vendor is supposed to put the BSP or ODM specific files in /system_ext, /vendor, /product and /odm.
The language, in this case, is just a locale setting, and several other "overlay" files (which supersede those in /system) laid out in the vendor/odm/product partitions. The problem here is that all these partitions will A) differ by vendor B) be read/only and DM-verity enabled.
Thus, it would take going over the vendor's overlay files and locale settings, and changing every one. Impractical.
You're better off just going in the language settings and setting en_US, and working from there. Even on non-rooted device, you can always adb install any app you want.
morpheus______ said:
There is a long and painful process to make one, and it's not guaranteed to work. I'll explain:
If a given vendor (in our case, Nubia, but this applies to others as well) adheres to Google's specification their /system partition should effectively be identical to that of all other Android devices (of same version). The vendor is supposed to put the BSP or ODM specific files in /system_ext, /vendor, /product and /odm.
The language, in this case, is just a locale setting, and several other "overlay" files (which supersede those in /system) laid out in the vendor/odm/product partitions. The problem here is that all these partitions will A) differ by vendor B) be read/only and DM-verity enabled.
Thus, it would take going over the vendor's overlay files and locale settings, and changing every one. Impractical.
You're better off just going in the language settings and setting en_US, and working from there. Even on non-rooted device, you can always adb install any app you want.
Click to expand...
Click to collapse
morpheus______ said:
There is a long and painful process to make one, and it's not guaranteed to work. I'll explain:
If a given vendor (in our case, Nubia, but this applies to others as well) adheres to Google's specification their /system partition should effectively be identical to that of all other Android devices (of same version). The vendor is supposed to put the BSP or ODM specific files in /system_ext, /vendor, /product and /odm.
The language, in this case, is just a locale setting, and several other "overlay" files (which supersede those in /system) laid out in the vendor/odm/product partitions. The problem here is that all these partitions will A) differ by vendor B) be read/only and DM-verity enabled.
Thus, it would take going over the vendor's overlay files and locale settings, and changing every one. Impractical.
You're better off just going in the language settings and setting en_US, and working from there. Even on non-rooted device, you can always adb install any app you want.
Click to expand...
Click to collapse
Thanks for the details!
Is it impractical in terms of technical perspective , or is it just tedious to do? And do you think it will be released in future?
The reason I want to switch is that there are bugs mostly related to the google assistant. It resetting my settings like on default voice assistant app. It doesn't have ok google detection, sometimes doesn't open at all.
If that can be fixed maybe I can stay on CN rom, but honestly there's a lot of random bugs, it not only resets default apps for assistant but other apps too like fluid navigation gestures (FNG) app.
LeonFresh said:
Thanks for the details!
Is it impractical in terms of technical perspective , or is it just tedious to do? And do you think it will be released in future?
The reason I want to switch is that there are bugs mostly related to the google assistant. It resetting my settings like on default voice assistant app. It doesn't have ok google detection, sometimes doesn't open at all.
If that can be fixed maybe I can stay on CN rom, but honestly there's a lot of random bugs, it not only resets default apps for assistant but other apps too like fluid navigation gestures (FNG) app.
Click to expand...
Click to collapse
Hello. Have you found a solution to the problem? I also do not flash, says the version for the firmware is not suitable.
Morrovoker said:
Hello. Have you found a solution to the problem? I also do not flash, says the version for the firmware is not suitable.
Click to expand...
Click to collapse
Not yet, I guess we just have to wait
LeonFresh said:
Not yet, I guess we just have to wait
Click to expand...
Click to collapse
any news yet i wanna switch from global to cn lol