Dm verity zip - Xiaomi Mi 8 Questions & Answers

Hi guys
I ask for something that I didn't understand so well, but now every time I change roms do I have to flash the DM verity zip? Because the last time I tried the lineage 17 the system was not able to boot I think because of this dm-verity zip that I didn't flash and the internal archive encryption.
However, my internal archive is not encrypted because the first time I installed xiaomi.eu I made Format data and typed Yes and then I also made all the wipes and installed the ROM in this way I removed the encryption from the archive interior right?
But do I still need to flash the DM verity zip every time I switch Rom?
For example, now I want to try havoc 3.0.
I have a xiaomi mi 8 with the latest wikley from xiaomi.eu 9.10.24

Up!
Inviato dal mio MI 8 utilizzando Tapatalk

Since your Filesystem is not encrypted, you have to do that.

The War Profiteer said:
Since your Filesystem is not encrypted, you have to do that.
Click to expand...
Click to collapse
But do I have to flash the DM verity zip every time I update my Rom? (when I update my rom I don't do a clean install I only do Wipe Cache and Devilk)
Or should I flash it only when I change ROM then after a clean installation?
(When I change ROM I make wipe data and system)

andrea0807 said:
But do I have to flash the DM verity zip every time I update my Rom? (when I update my rom I don't do a clean install I only do Wipe Cache and Devilk)
Or should I flash it only when I change ROM then after a clean installation?
(When I change ROM I make wipe data and system)
Click to expand...
Click to collapse
Probably yes.

I'm just going to say this again, DM-Verity stands for "D"-Device "M"-Mapper verity (verification). This protection looks at hashes for the mounted partitions and kernel to make sure they have not been modified. If the hashes don't match, the boot chain fails to load. Once again, this really doesn't have to do with Encryption. Encryption was sometimes included in the DM-Verity ZIP files also called FEC remover (Forced Encryption Remover). Even though the are a lot of times included in the 'DM-Verity" remover zip files, they are separate things! If you modify the stock MIUI partitions at all, it needs to have the DM-Verity removed -but doesn't have to have the FEC (encryption) removed. These forums are full of everyone saying flash the DM-Verity to remove encryption, which is only correct in a sense because most of the ZIP files floating around does in-fact remove the FEC (forced encryption) at the same time. If i am running modified stock, i want to keep encryption and just remove the verity bit that fails.
Info on DM-Verity:
https://source.android.com/security/verifiedboot/dm-verity
./

Agimax said:
I'm just going to say this again, DM-Verity stands for "D"-Device "M"-Mapper verity (verification). This protection looks at hashes for the mounted partitions and kernel to make sure they have not been modified. If the hashes don't match, the boot chain fails to load. Once again, this really doesn't have to do with Encryption. Encryption was sometimes included in the DM-Verity ZIP files also called FEC remover (Forced Encryption Remover). Even though the are a lot of times included in the 'DM-Verity" remover zip files, they are separate things! If you modify the stock MIUI partitions at all, it needs to have the DM-Verity removed -but doesn't have to have the FEC (encryption) removed. These forums are full of everyone saying flash the DM-Verity to remove encryption, which is only correct in a sense because most of the ZIP files floating around does in-fact remove the FEC (forced encryption) at the same time. If i am running modified stock, i want to keep encryption and just remove the verity bit that fails.
Info on DM-Verity:
https://source.android.com/security/verifiedboot/dm-verity
./
Click to expand...
Click to collapse
Thanks for clearing that up, there is a lot of conflicting information out there and it's difficult finding information that is currently valid and applicable to our phones.
Edit :
I should add that I never flash dm-verity and that I do not have issues. However, I also do not change the boot, except for Magisk.

Related

Magisk Installing OTA on Pixel XL 1

Hi,
I own a Pixel XL 128GB, running 8.0.0 October FW. I have installed Magisk 14.3 beta 1437. Almost everything works, except for:
1. When installing Magisk using Magisk's internal installer it always downloads MAgisk 14.0 and tries to install this old, outdated version. Is this a bug?
2. I can't install OTAs, tried following john's installing instructions...
https://github.com/topjohnwu/Magisk/blob/master/docs/tips.md#ota-installation-tips
My steps were:
* Install stock boot loader - Magisk almost immediately confirms that it has installed the stock boot image. That's a bit surprising, I don't see any flashing dialog like when installing Magisk. Bug?
* trying to update using the internal OTA fails. It takes very long and suddenly stops.
Any idea what went wrong?
niko26 said:
Hi,
I own a Pixel XL 128GB, running 8.0.0 October FW. I have installed Magisk 14.3 beta 1437. Almost everything works, except for:
1. When installing Magisk using Magisk's internal installer it always downloads MAgisk 14.0 and tries to install this old, outdated version. Is this a bug?
2. I can't install OTAs, tried following john's installing instructions...
https://github.com/topjohnwu/Magisk/blob/master/docs/tips.md#ota-installation-tips
My steps were:
* Install stock boot loader - Magisk almost immediately confirms that it has installed the stock boot image. That's a bit surprising, I don't see any flashing dialog like when installing Magisk. Bug?
* trying to update using the internal OTA fails. It takes very long and suddenly stops.
Any idea what went wrong?
Click to expand...
Click to collapse
1. If you wan't the current beta to install, you need to change to the beta update channel in the Manager settings.
2. You've probably done something that messes with important partitions (/system, /vendor, etc). It's enough to just mount the partition rw to destroy the ability to update through OTA.
Restoring the stock boot image through the Manager is instantaneous...
Hi @Didgeridoohan,
thank you very much for the quick answers!
Didgeridoohan said:
1. If you wan't the current beta to install, you need to change to the beta update channel in the Manager settings.
Click to expand...
Click to collapse
Thanks - I didn't know that.
2. You've probably done something that messes with important partitions (/system, /vendor, etc). It's enough to just mount the partition rw to destroy the ability to update through OTA.
Click to expand...
Click to collapse
Hm, how do I find out what has been messed on /system, and/or /vendor?
Does installing and using AdAway tamper with /system or /vendor?
So reflashing the stock boot image is not sufficent, correct?
And most important.. how do I fix this?
niko26 said:
Hi @Didgeridoohan,
thank you very much for the quick answers!
Thanks - I didn't know that.
Hm, how do I find out what has been messed on /system, and/or /vendor?
Does installing and using AdAway tamper with /system or /vendor?
So reflashing the stock boot image is not sufficent, correct?
And most important.. how do I fix this?
Click to expand...
Click to collapse
If you let AdAway directly write to /system/etc/hosts, then yes, you have a compromised system partition. If you're using Magisk Systemless Hosts you should be fine though. Do you have TWRP installed? That'd be an issue as well...
If you want to make sure that you can update through OTA in the future, clean flash a factory image (you can leave data intact) and then make sure not to touch /system or /vendor at all.
* DELETED *
Didgeridoohan said:
If you let AdAway directly write to /system/etc/hosts, then yes, you have a compromised system partition. If you're using Magisk Systemless Hosts you should be fine though.
Click to expand...
Click to collapse
Yeah, I've been using Magisk's systemless hosts-file.
. Do you have TWRP installed? That'd be an issue as well...
Click to expand...
Click to collapse
TWRP has not been installed permanently.
If you want to make sure that you can update through OTA in the future, clean flash a factory image (you can leave data intact) and then make sure not to touch /system or /vendor at all.
Click to expand...
Click to collapse
There aren't a lot of apps I am granting root. One of them is Titanium Backup. It may have tampered the fs.
Is there any kind of diff against the original folders which I can run to find out what has been tampered to possibly identify which app is causing the issues?
One of the main reasons for installing Magisk was because I was tired of flashing the entire system when updates have been released.
I never couldn't get Flashfire working properly when it comes to install updates / OTAs.
niko26 said:
Yeah, I've been using Magisk's systemless hosts-file.
TWRP has not been installed permanently.
There aren't a lot of apps I am granting root. One of them is Titanium Backup. It may have tampered the fs.
Is there any kind of diff against the original folders which I can run to find out what has been tampered to possibly identify which app is causing the issues?
One of the main reasons for installing Magisk was because I was tired of flashing the entire system when updates have been released.
I never couldn't get Flashfire working properly when it comes to install updates / OTAs.
Click to expand...
Click to collapse
Since the OTA can check for a tampered system, I'm sure there's a way to check. Question is if it's worth the effort.
Any app that has root access can be the culprit... Could also be that you let TWRP mount system rw or something similar. Really hard to say...
Didgeridoohan said:
Since the OTA can check for a tampered system, I'm sure there's a way to check. Question is if it's worth the effort.
Any app that has root access can be the culprit... Could also be that you let TWRP mount system rw or something similar. Really hard to say...
Click to expand...
Click to collapse
Does TWRP mount system as rw by default? Because all I really do is.. boot to TWRP, flash the Magisk's zip. That's it. Nothing else.
Is there any other way I can install OTAs without using a computer with USB (and keeping root of course )?
As said... I never could FlashFire to work correctly. The documentation leaves a lot of questions open - BTW.. props to the Magisk's docs - much better.
niko26 said:
Does TWRP mount system as rw by default? Because all I really do is.. boot to TWRP, flash the Magisk's zip. That's it. Nothing else.
Is there any other way I can install OTAs without using a computer with USB (and keeping root of course )?
As said... I never could FlashFire to work correctly. The documentation leaves a lot of questions open - BTW.. props to the Magisk's docs - much better.
Click to expand...
Click to collapse
TWRP doesn't mount system as rw unless you let it.
I've never used Flashfire and haven't updated through OTA since, 2014-ish. :laugh: I'm mainly going on theoretical knowledge here... On my Nexus I used fastboot to flash the factory image (until I switched to ROM flashing in TWRP) and now I just flash the full update package that OnePlus provides in TWRP.
For a while there I also flashed the system.img and boot.img files in TWRP. If that months security update only had anything to do with those files it was just a matter of downloading the factory image and unpack those two files and flash them directly in TWRP. No computer needed (unless there was an update to the bootloader and/or radio). No idea if this is viable on a Pixel...
My main use for Magisk is that all my system modifications are still there after I update my phone. Drastically cuts down on the time it takes to set my phone up after an update.
Didgeridoohan said:
I've never used Flashfire and haven't updated through OTA since, 2014-ish. :laugh: I'm mainly going on theoretical knowledge here... On my Nexus I used fastboot to flash the factory image (until I switched to ROM flashing in TWRP) and now I just flash the full update package that OnePlus provides in TWRP.
Click to expand...
Click to collapse
I've tried installing TWRP permanently, but the moment I have installed an official patch, it got wiped - and I haven't found any docs how to prevent that.
My main use for Magisk is that all my system modifications are still there after I update my phone. Drastically cuts down on the time it takes to set my phone up after an update.
Click to expand...
Click to collapse
What settings are you referring to?
niko26 said:
I've tried installing TWRP permanently, but the moment I have installed an official patch, it got wiped - and I haven't found any docs how to prevent that.
Click to expand...
Click to collapse
After updating, you probably need to boot straight to TWRP and reflash root. If you boot directly to the OS, it'll automatically replace TWRP with the stock recovery.
What settings are you referring to?
Click to expand...
Click to collapse
I like to change screen density, debloat system apps, install Viper4Android, install boot scripts (LiveBoot, etc) and a bunch of other things. With Magisk, as long as I don't wipe /data, all of that will still be intact after a system update. And even if I wipe data I can restore a backup of the Magisk image or just flash the module zips in TWRP. Takes seconds rather than half an hour like it could prior to Magisk.
Didgeridoohan said:
After updating, you probably need to boot straight to TWRP and reflash root. If you boot directly to the OS, it'll automatically replace TWRP with the stock recovery.
Click to expand...
Click to collapse
Well, TWRP is gone after an update - I can't boot into it.
[/quote]I like to change screen density, debloat system apps, install Viper4Android, install boot scripts (LiveBoot, etc) and a bunch of other things. With Magisk, as long as I don't wipe /data, all of that will still be intact after a system update. And even if I wipe data I can restore a backup of the Magisk image or just flash the module zips in TWRP. Takes seconds rather than half an hour like it could prior to Magisk.[/QUOTE]
Hm, I am not sure if I get you right. If it is about apps, I use Titanium Backup to recover my old apps+settings.
system files
Most of the setting you mentioned are messing with the system files. "debloating" or removing and system applications with titanium backup will fail a system check with OTA update. You can freeze the apps i believe.
I changing the screen density and boot scripts. These are all system files locations.
I have had an ota work be re-installing the system apps from titanium backup and reverting all the other changes when it was failing before. Think this was back on android 6.0 though.
Didgeridoohan said:
After updating, you probably need to boot straight to TWRP and reflash root. If you boot directly to the OS, it'll automatically replace TWRP with the stock recovery.
I like to change screen density, debloat system apps, install Viper4Android, install boot scripts (LiveBoot, etc) and a bunch of other things. With Magisk, as long as I don't wipe /data, all of that will still be intact after a system update. And even if I wipe data I can restore a backup of the Magisk image or just flash the module zips in TWRP. Takes seconds rather than half an hour like it could prior to Magisk.
Click to expand...
Click to collapse
automattic said:
Most of the setting you mentioned are messing with the system files. "debloating" or removing and system applications with titanium backup will fail a system check with OTA update. You can freeze the apps i believe.
I changing the screen density and boot scripts. These are all system files locations.
I have had an ota work be re-installing the system apps from titanium backup and reverting all the other changes when it was failing before. Think this was back on android 6.0 though.
Click to expand...
Click to collapse
Since all of the things I mentioned are done with Magisk, none of them will cause an OTA to fail...
Reinstalling system apps will not work, since nowadays an OTA will fail just by mounting /system as rw.
Hi guys, trying to install latest OTA patch for Pixel 2. I am assuming process would be the same. I tried to follow the guide but hit the bump immediately. I can't see "Restore Stock Boot" when pressing uninstall. But there is restore images option. Hitting it does nothing, I receive the message that there are no backups. Where does the backup go so I can put the original file for it to be reinstalled?

Are there 2 copies of /system on the phone?

My phone (3T) has an unlocked bootloader, is encrypted, not rooted, and running stock OOS 5.0.
I flashed TWRP and discovered that stock OOS restores the stock recovery in boot.
I saw the Oreo dm-verity thread by xenet, had a look at the zip file, noticed that it just modified fstab to prevent force encrypt, so I flashed it to see what happens.
And nothing happens. After the system had booted, fstab is unchanged from the original stock copy.
So I'm wondering whether this file is also restored when booting up on stock.
I get aggressive and go back to TWRP and delete /system/etc and /system/bin and modify build.prop.
Surely now the phone won't boot!
Wrong! It boots up and everything is back to normal in /system.
I go back to TWRP and have a look at /system and it shows me one without the etc and bin folders and has the modified build.prop.
What's going on? How can I see one version of /system in TWRP but a different version (ie, stock) when the phone has booted?
By the way I've been an Android user for many years and have rooted and flashed custom ROMs on a variety of phones and I've never seen anything like what's happening on my 3T. I'm sure that dm-verity is somehow involved in this.
Happened to me on my earlier OOS 5.0 attempts...
But i suspected Magisk is involved in my case.
I downloaded Magisk Module "System Terminal Debloater,"
remove some apps like Duo, Chrome, and Google Play Movies.
Some restarts, they magically re-appear again on Apps Drawer...
Haven't touch them yet again after....
nicknacknuke said:
Happened to me on my earlier OOS 5.0 attempts...
But i suspected Magisk is involved in my case.
I downloaded Magisk Module "System Terminal Debloater,"
remove some apps like Duo, Chrome, and Google Play Movies.
Some restarts, they magically re-appear again on Apps Drawer...
Haven't touch them yet again after....
Click to expand...
Click to collapse
Thanks.
I should have mentioned that I'm also not rooted. So stock OOS 5.0.
Sent from my OnePlus 3T using XDA Labs
When you boot TWRP for the first time, it should ask you if you want to put the /system in read/write mode or if you want to leave it unchanged, did you choose the right option?
Jackhass said:
When you boot TWRP for the first time, it should ask you if you want to put the /system in read/write mode or if you want to leave it unchanged, did you choose the right option?
Click to expand...
Click to collapse
No, I don't get that message because my phone is encrypted with a password. So the first thing I see in TWRP is the request for the password and then I'm presented with the menus.
However, in the Mounted menu, system isn't mounted and I have the option of mounting it in read-only mode.
Sent from my OnePlus 3T using XDA Labs
BillGoss said:
No, I don't get that message because my phone is encrypted with a password. So the first thing I see in TWRP is the request for the password and then I'm presented with the menus.
However, in the Mounted menu, system isn't mounted and I have the option of mounting it in read-only mode.
Click to expand...
Click to collapse
After first time flashing TWRP a folder gets created on your internal storage, with a hidden file called .twrps, go delete it and reboot recovery to trigger the message "allowing system modifications" on TWRP's first boot...
It's not about encryption, it's just that TWRP remember the decision you made due to the file I pointed out...
Sent from my OnePlus 3T using XDA Labs
Sam Nakamura said:
After first time flashing TWRP a folder gets created on your internal storage, with a hidden file called .twrps, go delete it and reboot recovery to trigger the message "allowing system modifications" on TWRP's first boot...
It's not about encryption, it's just that TWRP remember the decision you made due to the file I pointed out...
Click to expand...
Click to collapse
Somehow the attachment strikes on previous post
Edit: still not working, check your TWRP Folder on storage to find the file
Sent from my OnePlus 3T using XDA Labs
Sam Nakamura said:
Somehow the attachment strikes on previous post
Edit: still not working, check your TWRP Folder on storage to find the file
Click to expand...
Click to collapse
Thanks, you are correct. I'd forgotten that that TWRP remembers. Deleting .twrps does bring up the RO prompt after decrypting storage.
Jackhass said:
When you boot TWRP for the first time, it should ask you if you want to put the /system in read/write mode or if you want to leave it unchanged, did you choose the right option?
Click to expand...
Click to collapse
I had allowed changes to the system otherwise I couldn't have made changes to it, which includes the ability to restore the system partition.
But I'm still unclear why if I make changes to the system partition and boot with the stock kernel, then after the boot none of the changes are present in the system partition, but if I boot back into TWRP then the changes are all there.
I recall someone in another OOS 5 thread saying that the stock kernal replaces TWRP with stock recovery if you don't flash root (magisk/superSU). Is it possible that the kernel re-flashes system on boot? Another possibility is that TWRP thinks it's making changes to system but it's not actually? Not quite sure, I've never heard of anything like this before either, just throwing other ideas out there.
I've never read anything about the OP3T or any oneplus phones for that matter having A/B system partitions like the pixels. *shrug*
@nhshah7, something's like what you suggest must be going on to account for what I'm seeing. I'm hoping that someone can confirm my observations and provide a definite answer.
@BillGoss
My thread has been updated relating to all your queries...
Thank you...
https://forum.xda-developers.com/oneplus-3t/how-to/disable-dm-verity-force-encryption-op3t-t3688748
Xennet said:
@BillGoss
My thread has been updated relating to all your queries...
Thank you...
https://forum.xda-developers.com/oneplus-3t/how-to/disable-dm-verity-force-encryption-op3t-t3688748
Click to expand...
Click to collapse
Actually it doesn't explain how TWRP can make changes to system yet the phone boots up on an unmodified system if using the stock kernel. And then, when you boot back into TWRP and look at system, the changes are still there.
Where does the unmodified system come from?
Where does the modified system live?
Why doesn't modifying system result in a failed boot due to dm-verity, while restoring a backup of system does result in a failed boot?
So many questions with no answers.
BillGoss said:
....So many questions with no answers.
Click to expand...
Click to collapse
Not sure if this is applicable in your case but the following possibilities may be worth considering for you:
1. Are you sure that the system image is actually getting modified? If the system partition is not mounted before flashing the zip and the zip being flashed does not mount the system partition in read / write, then no changes to system partitions will actually be written.
2. If dm-verity is enabled, then restoring system could result in an error as this is different from restoring a system-image (nandroid copy of the whole partition and not just the files in the system partition). DM-verity can be triggered if the files are all the same but the dm-verity signature computed by hashing the system partition has changed.
3. For boot partitions, strange behaviour can occur if remnants of the previous boot.img are still in the partition (...e.g. if the previous boot.img was of larger size and a new boot.img of a smaller is flashed, then there will be some bytes after the new boot.img that are from the previous boot.img). To verify this, format the boot partition from fastboot and see if you notice anything different with the new boot.img.
4. In Oreo / 8.0, dm-verity flags are stored in dtb (device tree blobs) inside the kernel and not in the fstab file. Only data encryption can be changed from the fstab file and dm-verity needs to be changed from changing the dtb (...Magisk beta v1456 and SuperSu 2.82 SR4 do this, I think).
rk2612 said:
Not sure if this is applicable in your case but the following possibilities may be worth considering for you:
1. Are you sure that the system image is actually getting modified? If the system partition is not mounted before flashing the zip and the zip being flashed does not mount the system partition in read / write, then no changes to system partitions will actually be written.
2. If dm-verity is enabled, then restoring system could result in an error as this is different from restoring a system-image (nandroid copy of the whole partition and not just the files in the system partition). DM-verity can be triggered if the files are all the same but the dm-verity signature computed by hashing the system partition has changed.
3. For boot partitions, strange behaviour can occur if remnants of the previous boot.img are still in the partition (...e.g. if the previous boot.img was of larger size and a new boot.img of a smaller is flashed, then there will be some bytes after the new boot.img that are from the previous boot.img). To verify this, format the boot partition from fastboot and see if you notice anything different with the new boot.img.
4. In Oreo / 8.0, dm-verity flags are stored in dtb (device tree blobs) inside the kernel and not in the fstab file. Only data encryption can be changed from the fstab file and dm-verity needs to be changed from changing the dtb (...Magisk beta v1456 and SuperSu 2.82 SR4 do this, I think).
Click to expand...
Click to collapse
I'll come back to 1.
2. That makes sense and accounts for why a restore of the system partition with the stock boot image causes me to get dumped back in fastboot mode. If I flash the stock system zip file then the system boots properly.
3. I've not had any issues with strange boot behaviour. I'm always starting with stock or flashing kernels that modify the stock boot image, like Blu Spark.
4. I gathered this from my reading of various threads. If I want to make changes to the system partition and get them to stick and not fail dm-verity then I have to flash a custom kernel. I've proven this in my testing. (A rooting solution would also work, but I've not done this).
Back to 1:
Here's what I've done:
Starting with pure stock image (flash OOS 5.0).
Boot into fastboot and flash TWRP.
Boot into recovery.
Mount system as rw. (In ro mode the next step fails)
Delete the bin, etc, and lib folders in system using the TWRP file manager. (Screenshot a)
Reboot system.
... First interesting fact ...
System boots ok, deleted folders are present in file manager. (Screenshot b)
Boot into fastboot and flash TWRP. (Booting with stock restores stock recovery)
Mount system.
... Second interesting fact ...
TWRP file manager shows that deleted folders are missing. (Screenshot c)
Flash custom kernel or patched boot image
Reboot system
... Third interesting fact ...
System fails to boot. Hangs on splash screen.
So TWRP made the changes (otherwise how could they be visible between reboots, including a replacement of recovery) and I only did them once.
Yet they don't actually take effect until I replace the stock boot image.
So, where are the changes hiding? What did TWRP actually change?
Screenshots (note that TWRP has the wrong timezone set so the time shown is wrong):
BillGoss said:
....
Back to 1:
Here's what I've done:
Starting with pure stock image (flash OOS 5.0).
Boot into fastboot and flash TWRP.
Boot into recovery.
Mount system as rw. (In ro mode the next step fails)
Delete the bin, etc, and lib folders in system using the TWRP file manager. (Screenshot a)
Reboot system.
... First interesting fact ...
System boots ok, deleted folders are present in file manager. (Screenshot b)
Boot into fastboot and flash TWRP. (Booting with stock restores stock recovery)
Mount system.
... Second interesting fact ...
TWRP file manager shows that deleted folders are missing. (Screenshot c)
Flash custom kernel or patched boot image
Reboot system
... Third interesting fact ...
System fails to boot. Hangs on splash screen.
So TWRP made the changes (otherwise how could they be visible between reboots, including a replacement of recovery) and I only did them once.
Yet they don't actually take effect until I replace the stock boot image.
So, where are the changes hiding? What did TWRP actually change?
Screenshots (note that TWRP has the wrong timezone set so the time shown is wrong):
Click to expand...
Click to collapse
Some more thoughts for you to consider:
1. Have you tried this with the official TWRP recovery version 3.2.0-0?
2. Is there anything inside the folders that you see using the file manager after a regular boot? Folders of same name may exist in the boot ramdisk and these are merged with system folders after boot.
3. Try wiping cache between reboots and see if that changes any of your observations.
rk2612 said:
Some more thoughts for you to consider:
1. Have you tried this with the official TWRP recovery version 3.2.0-0?
2. Is there anything inside the folders that you see using the file manager after a regular boot? Folders of same name may exist in the boot ramdisk and these are merged with system folders after boot.
3. Try wiping cache between reboots and see if that changes any of your observations.
Click to expand...
Click to collapse
Good questions. They got me thinking more about how this could possibly work.
I had a look at the cache and there's definitely no copy of the system hiding there.
I also unpacked the ramdisk in the boot image and it had nothing in system. Furthermore, the boot position is only 64 MB, no where near enough to hold the system.
Then I installed Magisk so that I could browse around the phone's partitions and take copies.
I learnt two things from this:
1. If there's a second copy of the system there are only three partitions large enough to hold it (/proc/partitions shows the sizes in 1 kB blocks). The system is about 1 GB. There is space in the system partition (sde20) for 3 GB. There's also space in the data partition (sca15). And there's space in the major partition holding the modems (sdf).
I could eliminate the data partition by formatting it but restoring the internal storage (sdcard) is such a a pain.
So I'll just accept that there is space for a copy, but I'm unlikely to find out exactly where.
2. When I had Magisk installed installed and the system boot, I added a folder and file to /system/priv-app using a file manager (so not using TWRP). I then booted into recovery, flashed the stock boot image, and rebooted. I was expecting it to fail dm-verity (modified system) but it didn't. After booting up there's no evidence of the folder I added to priv-app.
And if I restore the Magisk boot image then the additions show up again.
I'm actually very impressed with how the stock system (kernel, recovery, system) protects itself from modification. Very cool!

[RECOVERY] [TREBLE] [RETIRED] TWRP with Tissot Manager (Treble & Dual boot support)

RETIRED! No longer supported or being developed. @Giovix92 is now the lead dev, please use his TWRP for full compatibility with modern kernels/ROM's - https://forum.xda-developers.com/mi-a1/development/recovery-twrp-3-3-1-0-tissot-manager-t3976117
Old thread below:
-----------------------------------
About
This is a TWRP Installer ZIP and bootable IMG with extra capability such as Treble-izing, Dual boot repartitioning and other power-user tools with integrated Aroma Installer-powered GUI screens that I call Tissot Manager.
HIGHLY recommended reading and guide for everyone new to Treble - [TREBLE][GUIDE] From Stock to Treble - everything you need to know!. It also has some general protips hidden within there, for example the seamless/slot system interactions and nuances, so it's worth reading for anyone who wants to be a master of the Android flashing domain
Features:
TWRP fully Treble-ready with dual-boot ROM patcher;
Maintained with latest TWRP version;
Fully compatible with non-Treble devices - can be used as normal without Treble partitioning;
USB-OTG fixed
Has 'TWRP survival' function for automatically re-installing TWRP recovery when installing ROMs and kernels;
Option to install a payload ROM in the current slot, rather than the inactive one;
Option to ignore Payload<>Recovery certificate failures (fix for newer LOS-based ROMs);
Adds a "Tissot Manager" Aroma GUI to TWRP Advanced Menu (bottom-right button), which is the tool used to repartition the device for Treble and Dual boot, as well as some other nifty stuff:
Has the option to shrink System OR Userdata to create Vendor partitions. All relevant partitions will be resized and formatted in one go.
If you shrink System, you will keep max size Userdata - however it will be incompatible with non-Treble ROM's (they will crash on installing with Error 28 due to System being too small). It will Erase system, requiring you to reinstall a ROM or restore a ROM backup.
If you shrink Userdata, it will ERASE DATA AND INTERNAL STORAGE COMPLETELY - but your device will stay compatible with all existing non-Treble ROM's
Dual boot requires Userdata shrink and works by splitting into userdata_a and userdata_b. The partition split size is customizable during the repartition process.
Adds a "Patches" section with the following current options:
Patch the current Vendor for dual-boot capability (only required if automatic patching wasn't possible). See the 'About Dual-boot' section below for more information.
Enable an insecure ADBD on boot for the current slot (i.e. enable debugging and remove authentication requirement). Useful for ROM hackers/porters.
Patch the current slot to enable/disable forced userdata encryption
All of this info is detailed inside the Tissot Manager GUI.
See screenshots in post 2.
Instructions
Optionally boot the boot-recovery.img to get a temporary TWRP if you don't have it installed, unzipped from TWRP-boot.img-3.2.1-with-Tissot-Manager-x.x.zip:
Code:
fastboot boot boot-recovery.img
Warning - do not EVER flash this img - hotboot it only.
Flash the TWRP Installer. Any slot, any ROM, any existing Recovery - it doesn't matter - it will be installed to both slot kernels.
Reboot Recovery
Optional - Use the "Advanced > Tissot Manager" option for repartition options and other advanced ROM patches (Aroma Installer powered GUI - a fully guided and interactive process).
If you opted to repartition for Treble, you are ready to flash a Treble ROM/Vendor pack. Reminder - check out my full guide for learning and instructions on all things Treble.
About TWRP survival
TWRP survival is a simple hook that detects if a boot.img will be installed and restores TWRP after it's flashed. This only works if you have booted TWRP with Tissot Manager 2.0 from a real recovery boot - NOT from a recovery 'hot boot' (fastboot boot method).
You will see in the install log if a TWRP survival attempt is successful in the flash text output.
Automatic TWRP survival works when:
Flashing a ROM ZIP (or AIO) with TWRP
Flashing a boot.img in TWRP "Install Image" mode
Automatic TWRP survival does NOT work when:
Flashing a boot.img via fastboot
Restoring boot in a TWRP backup
Any other way of flashing a boot.img
In these cases, be sure the use the TWRP Installer immediately after flashing or restoring a backup - otherwise you may get the device into a confused state (especially if you restore a non-TWRP boot then try to install an AIO ROM without installing a new TWRP first).
About Dual-boot
Dual-boot on this device is relatively simple. As you know we have Slots - boot_a and _b, system_a and _b and vendor_a and _b (for Treble). This repartition splits userdata into userdata_a and _b too. You can simply change your Slot in TWRP reboot menu to change which ROM to boot.
This is designed for developers and testers - NOT for daily use. There are some significant issues with dual boot systems:
Any kind of security lock (PIN, fingerprint, etc.) set on one ROM will cause the other ROM to believe it has security too, but constantly fail with unlocking. This is reportedly because security info is stored on persist, which is shared between each slot (and not compatible with differing ROM's).
Because Userdata is split, so is Internal Storage. In TWRP, when changing slots, the MTP will remain mounted to the old slot - it must be manually disabled and renabled (Mounts menu) to update to the new slot.
I will not fix these issues - dual-boot is not designed to be for general/daily use and there may be more minor issues that I don't know about. It's intended for developers only.
In order for a ROM to be dual-boot compatible, the fstab file (information given to Android about partitions to mount) needs a small modification. This TWRP can try to do this patching automatically when you install a ROM, or it can be done manually in Tissot Manager's Patches menu (as well as single-boot patch to e.g. revert a ROM backup from a dual-boot state).
You will see in the install log if a dual-boot patch attempt is successful in the flash text output.
Automatic dual-boot patch occurs only if necessary when:
Flashing an AIO Treble ROM ZIP with TWRP
Flashing a vendor.img in TWRP "Install Image" mode
Automatic dual-boot patch does NOT work when:
Flashing a vendor.img via fastboot
Restoring vendor in a TWRP backup
Any other way of flashing a vendor
In any of these cases, you can manually patch Vendor for Dual Boot in Tissot Manager's Patches menu. You can also remove dualboot support the same way. It will detect the dualboot state of the current Vendor slot and present the available option. If you find that it doesn't actually change after patching, the Vendor is incompatible (please report it to me). RR AIO Vendor is tested OK.
Download
All downloads (and source code) always at:
https://github.com/CosmicDan-Android/android_device_xiaomi_tissot/releases
...or via DevBB Downloads section.
Additional sources not able to be listed in DevBB:
Modified update_engine: https://github.com/CosmicDan-Android/android_system_update_engine_tissotmanager-mod
What's next?
See [TREBLE][GUIDE] From Stock to Treble - everything you need to know! for detailed instructions and learning on how to Treble like a pro.
FAQ
Q) After I flash TWRP, I get kicked into a Recovery loop when trying to boot the ROM!
A) This is probably because you have a kernel that does not disable dm-verity. To fix this, flash Magisk. The void kernel included in RR AIO does not have this problem and can therefore be safely used without Magisk (for e.g. GSI compatibility).
Q) After I flash TWRP, I get kicked into fastboot when trying to boot the ROM!
A) Your kernel is not Treble-compatible.
Q) How do I update TWRP?
A) Just flash the ZIP installer again, then Reboot Recovery. Note that this will erase Magisk on BOTH slots if you have it installed to either, requiring you to reflash it to one/both slots. See my Treble guide FAQ section for more info on Magisk interaction.
Q) My PC can't see the MTP (storage) device from TWRP!
A) For dualboot compatibility, MTP is automatically disabled at various points. Just enable it manually in the Mounts menu to get access.
Q) If I shrink Userdata for Treble, will stock and OTA work?
A) I have heard varying results on this. It does for some, not for others. Please assume that this will NOT work. It will definitely not work if you have shrunk system.
Q) Can I restore a non-Treble TWRP backup after I repartition for Treble? And the other way around?
A) Yes! In fact, this is the easiest way for...
...using stock ROM on Treble repartition (requires Userdata shrink ONLY). May also require a custom kernel with dm-verity disabled (see Questions above regarding fastboot kick and recovery loop).
...using a non-treble ROM if you shrunk System instead of Userdata since you cannot install non-Treble ROM ZIPs with a shrunk System (see next Q)
Q) I get some Error 28 when trying to install a ROM when repartitioned
A) You have shrunk System and are trying to install a non-Treble ROM. This is not possible AT ALL because the ROM ZIP expects a stock-size System. Use Userdata shrink mode instead if you want to be able to use non-Treble ROM's easily.
Q) I see "Failed to mount '/system' (Device or resource busy)" red error in TWRP after flashing a ROM
A) You can safely ignore it. You just need to reboot recovery before you can flash anything else (like Gapps) to this ROM.
Credits and Thanks
- @mohancm for the original TWRP port, I used some flags from his DT
- @ghpranav and @mountaserhalak for the RR device tree that this is built with (and random help)
XDA:DevDB Information
TWRP with Tissot Manager (Treble & Dual boot support), Tool/Utility for the Xiaomi Mi A1
Contributors
CosmicDan
Source Code: https://github.com/CosmicDan-Android/android_device_xiaomi_tissot
Version Information
Status: Stable
Created 2018-05-29
Last Updated 2019-11-24
Reserved
Screenshots (click for slightly larger non-cropped version)
Screenshot of new TWRP button:
_______________
Main menu (stock partition map detected):
_______________
Repartition choice type when coming from stock:
_______________
Repartition wipe warning/disclaimer if chosing to shrink Userdata for Treble:
_______________
Main menu (Shrunk Userdata type Treble partition map detected):
_______________
Repartition wipe warning/disclaimer if chosing to restore Stock from Shrunk Userdata Treble mode:
_______________
Example of Repartition processing screen:
Good job! :good:
Nice work!
Did you tested treble roms with this? Aex now have treble support
Omg, you are the best man. @mohancm also huge thanks to u man, great devs in our XDA.
I have never seen this kind of detailed, kind guide in XDA. You guys are awesome! Thanks for all this work!
One question : If I choose to shrink /userdata instead of /system,
1. Will I be able to flash stock rom by using MiFlash?
2. If I can, will I be able to get OTA and install them w/o issues?
3. Can I restore a TWRP backup that was made before repartitioning?(because of data on /data)
I think lots of people will be wondering about #3. If you think so too, then please add it in OP!
Thanks to all of you devs again!
Chikoow1 said:
Nice work!
Did you tested treble roms with this? Aex now have treble support
Click to expand...
Click to collapse
This is just the repartition part, one step of Treble. You still need a Vendor pack. But yes, this enables Treble ROMs and the ROMs require repartition.
ddaggebi said:
I have never seen this kind of detailed, kind guide in XDA. You guys are awesome! Thanks for all this work!
One question : If I choose to shrink /userdata instead of /system,
1. Will I be able to flash stock rom by using MiFlash?
2. If I can, will I be able to get OTA and install them w/o issues?
3. Can I restore a TWRP backup that was made before repartitioning?(because of data on /data)
I think lots of people will be wondering about #3. If you think so too, then please add it in OP!
Thanks to all of you devs again!
Click to expand...
Click to collapse
1. If you do, it will wipe partition map back to stock. So you will need to repartition with Treble Manager TWRP again. But you can make a backup of stock ROM in TWRP and just restore it after the repartition. It should work.
2. Don't know. Needs testing.
3. Yes! I forgot to add this to the FAQ.
Has this tpwr f2fs support and working?
Since Los support It i would like ti have
@CosmicDan
Thank you so much for your effort. I'm currently on stock and want to retain stock compatibility, so I'm going to wait until this becomes more polished before trying. I understand that Treble is not meant to be compatible with stock, so I realize my question might be out of place. Still, my question is:
Will you also release the .img file for Treble TWRP for those of us who don't want a permanent custom recovery?
Filip013;76586434 [user=1844875 said:
@CosmicDan[/user]
Thank you so much for your effort. I'm currently on stock and want to retain stock compatibility, so I'm going to wait until this becomes more polished before trying. I understand that Treble is not meant to be compatible with stock, so I realize my question might be out of place. Still, my question is:
Will you also release the .img file for Treble TWRP for those of us who don't want a permanent custom recovery?
Click to expand...
Click to collapse
It's indeed not intended to be compatible with stock ROM, but your mileage may vary, and as @CosmicDan said, it might work good enough or it won't. You can only try to see the results yourself.
This whole Treble thing is meant mainly for custom ROMS, since stock will never be Treble compatible (still, anything could happen)
I've just updated the TWRP with Treble Manager to 1.1 which fixed a semi-important bug.
Also, I've released a guide for those who find the Treble conversion/install process confusing - check it out. If you can, keep TWRP and Treble Manager specific questions in this thread, but ask your general questions and help over there - I will update the guide as I get feedback
CosmicDan said:
FAQ
Q) If I shrink Userdata for Treble, will stock and OTA work?
A) Untested. Please report your results. But Treble is really not about Stock, you will likely encounter more problems down the line or it may turn out to be completely incompatible.
Q) Can I restore a non-Treble TWRP backup after I repartition for Treble? And the other way around?
A) Yes! In fact, this is the easiest/only way for...
...using stock ROM on Treble repartition (requires Userdata shrink ONLY). May also require a custom kernel with dm-verity disabled (untested - if you get bootloop when using stock, it means you do) or Magisk (also untested, may still get bootloop).
...using a non-treble ROM if you shrunk System instead of Userdata since you cannot install non-Treble ZIP's on ROM's with a shrunk Userdata (see next Q)
Q) I get some Error 28 when trying to install a ROM when repartitioned
A) You have shrunk System and are trying to install a non-Treble ROM. This is not possible AT ALL because the ROM ZIP expects a stock-size System. Use Userdata shrink mode instead if you want to be able to use non-Treble ROM's easily.
Q) I see "Unable to mount '/vendor' (Invalid argument)" red error in this TWRP
A) You can safely ignore it. It just means you have not repartitioned your device for Treble yet, so it can't mount the /vendor image.
Click to expand...
Click to collapse
Ay!
Have just finished testing about OTA on stock after Treblizing!
Result?!?
OTA works perfectly on stock after shrinking data to Treblize! Hurrah! ???
Process I followed:
1) Treblize by shrinking data
2) This is important: flash stock ROM in fastboot using MiFlash! When flashing for the first time, select "clean all and lock"! No other standard options working! I couldn't even boot stock using other options!
I've tested by fastboot flashing April build and then updating it to May OTA!
*** On a note: clean all will erase everything on your phone including your personal data!
If you use "save user data" then stock can't even boot! This may caused by the encryption!
BTW, after everything I just restored my non-Treble RR backup and everything works perfect! Just Treble Check app can't check that it's Treblized!
But don't worry! Treble partition table still remains! Fastboot flash can't touch that and can't recognize that it actually exists! Which to me is a good thing!
@CosmicDan, give me a thanks buddy! I deserve this!
SomratMJX said:
-snip-
Click to expand...
Click to collapse
Don't quote the whole OP and please use a smaller font size.
Change slot doesn't work... Others are okay as far as i have seen
dback31 said:
Don't quote the whole OP and please use a smaller font size.
Click to expand...
Click to collapse
Just thought it's too important to highlight! Nothing else!
Rakibboss said:
Change slot doesn't work... Others are okay as far as i have seen
Click to expand...
Click to collapse
Reboot to fastboot and change the slots with
fastboot set_active b
Rakibboss said:
Change slot doesn't work... Others are okay as far as i have seen
Click to expand...
Click to collapse
Use the latest TWRP 1.1! Works fine for me!
SomratMJX said:
Just thought it's too important to highlight! Nothing else!
Click to expand...
Click to collapse
Then please atleast remove the OP quote. It's a pain for mobile users to scroll through this
dback31 said:
Then please atleast remove the OP quote. It's a pain for mobile users to scroll through this
Click to expand...
Click to collapse
Ha ha ha! It's related to OP buddy!
Anyways, I am too lazy to quote a certain part of the OP!

Question Bootloop after Magisk uninstall - dirty flash and data rescue

Hello everyone,
I seek this forum for help to rescue/recover photos from my S21 (G991B)
I unlocked OEM, flashed patched AP + Magisk root.
Happily lived for couple of months until I updated Magisk to the newest version which dropped MagiskHide support.
And here comes my past idiotic version of me who uninstalled Magisk without backing up data first.
I quickly ended up in bootloop, with "unathorized device" in adb. I wiped cache and Dalvik cache.
So I decided to flash twrp-3.6.0_11-4_afaneh92-o1s.tar recovery with vbmeta_disabled_R.tar and then run multidisabler twice.
I was happy that adb worked, only to find out few minutes later that the sdcard is encrypted. I could not access my data, but at least I managed to do low level backup of userdata partition:
adb pull dev/block/sda34 userdata.backup
So I decided to flash stock ROM. I used Frija to download SM-G991B_2_20220309104450_uns6t6aual_fac.zip and flashed BL, AP, CP and HOME_CSC. With "Re-Partition" unchecked
This got me from G991BXXU3AUF6 to G991BXXU3BUK8
However bootloop persist. The stock recovery says "E: failed to mount /sdcard (no such file or directory)".
Now I'm getting a little bit desperate to rescue my precious data.
Do you know any other tricks, guys?
If I do full data wipe and/or clean flash of stock image with "re-partition" enabled and then flash twrp recovery and try adb push dev/block/sda34 from my userdata backup or simply writing userdata as raw image to an external microSD card and attaching it to the phone, do I get my data back in unencrypted form?
Any help appreciated.
What do you mean by "uninstalled Magisk"? Did you uninstall the app or did you flash the stock AP? If it is the latter, you could flash the patched Magisk AP on Odin and it should boot again
Decrypting the /data partition from an encrypted state is something that is not easy and I'm not sure if it is possible at all. The easiest way would be to get the device running again in the currently encrypted state
EDIT: So I think you've removed any encryption key by using the multidisabler I assume?
Macusercom said:
What do you mean by "uninstalled Magisk"? Did you uninstall the app or did you flash the stock AP? If it is the latter, you could flash the patched Magisk AP on Odin and it should boot again
...
EDIT: So I think you've removed any encryption key by using the multidisabler I assume?
Click to expand...
Click to collapse
Within the Magisk app I clicked on “Uninstall Magisk“ --> “Complete Uninstall”. Then it ended up in bootloop.
Reg. multidisabler - not sure if that's the case. I thought hardware wrapped keys are used for full disk encryption.
picapicopica said:
Within the Magisk app I clicked on “Uninstall Magisk“ --> “Complete Uninstall”. Then it ended up in bootloop.
Reg. multidisabler - not sure if that's the case. I thought hardware wrapped keys are used for full disk encryption.
Click to expand...
Click to collapse
Not sure to be honest. I would try to flash the whole firmware via Odin, use the Magisk patched AP and use Home_CSC to see if it still boots
EDIT: I think all Magisk does is to flash the stock boot.img upon uninstallation. But the device doesn't boot if you unroot. I assume that flashing the modified boot.img (which is inside the Magisk patched AP) could fix it
Macusercom said:
Not sure to be honest. I would try to flash the whole firmware via Odin, use the Magisk patched AP and use Home_CSC to see if it still boots
EDIT: I think all Magisk does is to flash the stock boot.img upon uninstallation. But the device doesn't boot if you unroot. I assume that flashing the modified boot.img (which is inside the Magisk patched AP) could fix it
Click to expand...
Click to collapse
Okay, I'll try to patch the AP on another phone (Honor 8). I hope it doesn't matter. I will Install Magisk app, copy AP to sdcard and patch the AP with magisk, pull the file and flash it on S21 like you said. I'll let you know.
picapicopica said:
Okay, I'll try to patch the AP on another phone (Honor 8). I hope it doesn't matter. I will Install Magisk app, copy AP to sdcard and patch the AP with magisk, pull the file and flash it on S21 like you said. I'll let you know.
Click to expand...
Click to collapse
It works as long as both devices share the same architecture (e. g. arm64-v8a). Otherwise patching in the Magisk app will probably fail. Other than that patching on another device will work
That worked like a charm. Thank you so much for saving my data (mostly family photos and dickpics)
For anyone attempting to dirty flash, make sure you use HOME_CSC from the same firmware you have on the phone and if not, then download same U3 or U4 version (G991BXXU3....) using Frija's manual option. If you use U4 over U3, then you risk having user data wipe anyways.

Question Root stock Android 13

I patched the boot.img file from the new Android 13 stock with Magisk 25.2. How do I relace the boot.img in the original AP tar file with the modified one? When I try to add it to AP I get an error saying there additional data at the end of the archive, which I assume is the md5 data.
edit: I installed TWRP and booted into it with no problem. But when I then booted system, powered off and boot back to recovery, it was gone.
lewmur said:
I patched the boot.img file from the new Android 13 stock with Magisk 25.2. How do I relace the boot.img in the original AP tar file with the modified one? When I try to add it to AP I get an error saying there additional data at the end of the archive, which I assume is the md5 data.
Click to expand...
Click to collapse
Is TWRP available for your device? If yes, use TWRP to flash the boot image to /boot.
Even better, just leave the boot image alone and flash Magisk in TWRP.
If TWRP is not available, try this as it should allow you to use fastboot command line to directly flash the boot image.
V0latyle said:
Is TWRP available for your device? If yes, use TWRP to flash the boot image to /boot.
Even better, just leave the boot image alone and flash Magisk in TWRP.
If TWRP is not available, try this as it should allow you to use fastboot command line to directly flash the boot image.
Click to expand...
Click to collapse
I edited my original post to say I flashed TWRP and booted into it but the patched file was in internal encrypted storage and TWRP couldn't access it. So I booted back to system and moved the patch to SD. But when I booted back to recovery, TWRP was gone. In desperation, I flashed TWRP again and then used it to flash the patched boot. IT WORKED!!! I now have root and it retained TWRP. Don't know why it was overwritten the first time as I made sure to boot to it before booting system.
lewmur said:
I edited my original post to say I flashed TWRP and booted into it but the patched file was in internal encrypted storage and TWRP couldn't access it. So I booted back to system and moved the patch to SD. But when I booted back to recovery, TWRP was gone. In desperation, I flashed TWRP again and then used it to flash the patched boot. IT WORKED!!! I now have root and it retained TWRP. Don't know why it was overwritten the first time as I made sure to boot to it before booting system.
Click to expand...
Click to collapse
Yeah, Vaultkeeper was the problem. Magisk dynamically disables this during boot; otherwise, after flashing TWRP, you should generally flash the Multidisabler and wipe data before continuing. Among other things, Vaultkeeper will automatically replace unsigned images with the stock images, even if the bootloader is unlocked.
Glad to know you got rooted, though!
If you're interested in running AOSP without any of the Samsung bloat, check out my guide here. I have a T290 (Tab A 8.0) and it's become painfully obvious that these midrange devices (Tab A series) don't have enough power to handle a lot of overhead.
V0latyle said:
Yeah, Vaultkeeper was the problem. Magisk dynamically disables this during boot; otherwise, after flashing TWRP, you should generally flash the Multidisabler and wipe data before continuing. Among other things, Vaultkeeper will automatically replace unsigned images with the stock images, even if the bootloader is unlocked.
Glad to know you got rooted, though!
If you're interested in running AOSP without any of the Samsung bloat, check out my guide here. I have a T290 (Tab A 8.0) and it's become painfully obvious that these midrange devices (Tab A series) don't have enough power to handle a lot of overhead.
Click to expand...
Click to collapse
What is +GSM?? Is that google services management?
lewmur said:
What is +GSM?? Is that google services management?
Click to expand...
Click to collapse
GMS. Google Mobile Services Basic Google apps (Chrome, Play Store, YouTube, GMail, etc) as well as the underlying framework and APIs required for Google Play Services dependent apps
V0latyle said:
GMS. Google Mobile Services Basic Google apps (Chrome, Play Store, YouTube, GMail, etc) as well as the underlying framework and APIs required for Google Play Services dependent apps
Click to expand...
Click to collapse
I'll give it a try a little later. Right now I'm bushed!! Thanks
lewmur said:
I'll give it a try a little later. Right now I'm bushed!! Thanks
Click to expand...
Click to collapse
Didn't work. Formatted data and flashed multi. But gsi gave error invalid file.
lewmur said:
Didn't work. Formatted data and flashed multi. But gsi gave error invalid file.
Click to expand...
Click to collapse
What file did you try to flash?
In most cases, you need to extract the system.img from the zip package. You can't flash the archive itself.

Categories

Resources