Related
Tired of having to redownload and reinstall all of your apps when you reflash your phone? SaveMyApp can help.
This script will setup your phone so that after your flash to your favorite rom, all* of your apps will be install on the first boot. These apps will show up in the market too!
Also, the script will allow you to backup your /data/data folder to your sdcard and then restore it after your reflash. The /data/data is where Most of your user data is stored. This is not guaranteed to fully restore everything. This also does not backup your Google, Android, or Motorola settings; this is to improve compatibility with roms.
*The /preinstall folder is limited to 120MB, so if you have more then of apps this script will not fully work.
This should work with all phones, however it has only been tested on the Droid 2/X.
If you want to test this script on a different phone, let me know the /preinstall size and if it worked or not.
v0.1.4.2 - 11/17/2010
-Improved backup and restore of data
-Improved script usability
v0.1.4.1 - 11/17/2010
-Improve safety of removing /preinstall/app
v0.1.4 - 11/16/2010
-Added option to clear the /preinstall/app folder
-Added messages to support clear /preinstall/app
v0.1.3 - 11/12/2010
-Added backup of /data/data
-Added messages to support Data Backup
v0.1.2 - 11/11/2010
-Added Backup /data/app-private
-Show /data/app size, prompt user for continue
-Additional messages added to improve user experience
v0.1.1 - 11/10/2010
-First Release
-Backup and Restore /data/app
Installation:
WARNING: This steps must be completed as listed, failure to do so may result in unexpected errors which I am not responsible for.
1. Enable USB debugging and make sure Sdcard is mounted on phone
1. adb push apps.sh /data
2. adb shell
3. cd /data
4. chmod 775 apps.sh
5. ./apps.sh
a. Follow the onscreen directions
6. Reboot and proceed to wipe and reflash
7. On boot, wait between 5 and 10 minutes depending on how many apps you have before logging into your account. (30 apps takes about 4-5 minutes)
8. Login to your account
9. Droid 2/X Bootstrapper -> Bootstrap Recovery
10. Enable USB debugging and make sure Sdcard is mounted on phone
11. adb shell
12. tar -xzpf /sdcard/savemyapp/backup.tgz
FAQS:
Market isn't showing apps!
settings->applications->Manage Applications->All->Market->Force Stop, Clear data
Why is there a MACOSX file when I extract the archive?
Because I am lazy and I zipped it using Mac's built in archiver.
The script isn't working right away!
Redownload the newest script, just to make sure
Disclaimer:
You may repost this, but you must quote it as is.
I will only be responding to the threads I started on the Xda-Developers forums.
This is a great idea! I'll post back when I try it out.
Interesting! I posted this at Android Forums!
Titanium Backup is a good one also
Sent from my DROIDX using XDA App
thing with titanium it takes like 20 minutes to get all my stuff back lol
rayne58 said:
thing with titanium it takes like 20 minutes to get all my stuff back lol
Click to expand...
Click to collapse
Get the pro version.
Sent from my SCH-I500 using XDA App
Titanium Pro is well worth the money.
Cool way to do it for free though...
After updating my Huawei Mate S to Android Marshmallow EMUI 4.0.1 (CRR-L09C432B361) I am having screen overlay issue. Sorry, I can't give screenshot. Gallery, facebook upload, Gmail etc. are not working properly. I am getting a message like this- "Screen overlay detected- To change this permission setting you first have to turn off the screen overlay from Settings > Apps". When I click on Settings tab, it takes me to a settings section named "Draw over other apps". When I click on the relevant app, I find some of their permissions denied, which I can't turn on. I did some googling and found some other related posts mostly indicating to disable some kind of screen filtering apps or clean master which I don't have. Tried resetting, then wiping cache data, didn't fix. Tried disabling developer options, didn't work. Can anyone help to solve this issue.
As you probably know by now & as I understand it, this is a security measure, which will trigger Marshmallow to pop-up 'Screen overlay detected...' warnings each time you try to change an app's permissions (i.e. for the apps that are affected by this 'drawing over other apps' feature).
There are 2 ways to get around this so you are allowed to freely change apps' permissions (do one or the other - whichever is more convenient for you):
1. Go to Settings > Apps > access 'Advanced' (near the bottom) > under 'Advanced' subsection, access 'Draw over other apps'. Here, individually change the settings of ALL the apps to 'No' (in other words, disable 'Permit drawing over other apps' for every app). Once done, you can freely change apps' permissions in Settings > Apps > [name of app] > 'Permissions' without the annoying 'Screen overlay detected...' warning popping-up every time. Once you have correctly changed the permissions (for every app that's not working properly), you should return to individually change each of the apps' settings to 'Yes' in the 'Draw over other apps' section (in other words, re-enable 'Permit drawing over other apps' for every app).
or (easier for me)
2. Reboot your phone into Safe Mode (click here if you need to know how). Once in Safe Mode, you can freely change apps' permissions in Settings > Apps > [name of app] > Permissions without the annoying 'Screen overlay detected...' warning popping-up every time. Once you have correctly changed the permissions (for every app that's not working properly), restart the phone as normal.
For both of the above & If you prefer, all changeable apps' permissions can also be easily done via Settings > Apps > access 'Advanced' (near the bottom) > access 'App permissions'.
If some apps are still not working as they should, check to see that the affected apps have 'Yes' below their name in the Apps > Advanced > 'Draw over other apps' section, AND they have ALL their permissions enabled under the Settings > Apps > [name of app] > 'Permissions' section.
GaT7 said:
As you probably know by now & as I understand it, this is a security measure, which will trigger Marshmallow to pop-up 'Screen overlay detected...' warnings each time you try to change an app's permissions (i.e. for the apps that are affected by this 'drawing over other apps' feature).
There are 2 ways to get around this so you are allowed to freely change apps' permissions (do one or the other - whichever is more convenient for you):
1. Go to Settings > Apps > access 'Advanced' (near the bottom) > under 'Advanced' subsection, access 'Draw over other apps'. Here, individually change the settings of ALL the apps to 'No' (in other words, disable 'Permit drawing over other apps' for every app). Once done, you can freely change apps' permissions in Settings > Apps > [name of app] > 'Permissions' without the annoying 'Screen overlay detected...' warning popping-up every time. Once you have correctly changed the permissions (for every app that's not working properly), you should return to individually change each of the apps' settings to 'Yes' in the 'Draw over other apps' section (in other words, re-enable 'Permit drawing over other apps' for every app).
or (easier for me)
2. Reboot your phone into Safe Mode (click here if you need to know how). Once in Safe Mode, you can freely change apps' permissions in Settings > Apps > [name of app] > Permissions without the annoying 'Screen overlay detected...' warning popping-up every time. Once you have correctly changed the permissions (for every app that's not working properly), restart the phone as normal.
For both of the above & If you prefer, all changeable apps' permissions can also be easily done via Settings > Apps > access 'Advanced' (near the bottom) > access 'App permissions'.
If some apps are still not working as they should, check to see that the affected apps have 'Yes' below their name in the Apps > Advanced > 'Draw over other apps' section, AND they have ALL their permissions enabled under the Settings > Apps > [name of app] > 'Permissions' section.
Click to expand...
Click to collapse
Thanks mate for ur detailed instructions, it's solved and I am relieved...
plesae help
Feroztex said:
Thanks mate for ur detailed instructions, it's solved and I am relieved...
Click to expand...
Click to collapse
one does not work for me
I have a problem after update to B361, I can't use somes apks with my internet data (only with Wifi) like Youtube, Pokemon Go, Snapchat.
I checked and every app have all the permissions (incluyed internet data permissions) so I don't know what to do.
Any help?
Hi,
Try to flash this by TWRP Recovery, it should fix Screen overlay permissions
http://www.mediafire.com/?ouxua6rkkagi3g9
edzamber said:
Hi,
Try to flash this by TWRP Recovery, it should fix Screen overlay permissions
http://www.mediafire.com/?ouxua6rkkagi3g9
Click to expand...
Click to collapse
Don't you need the phone to be rooted to do that?
I suspect most users would have an unrooted phone.
GaT7 said:
Don't you need the phone to be rooted to do that?
I suspect most users would have an unrooted phone.
Click to expand...
Click to collapse
No, just need twrp Recovery or similar
edzamber said:
Hi,
Try to flash this by TWRP Recovery, it should fix Screen overlay permissions
http://www.mediafire.com/?ouxua6rkkagi3g9
Click to expand...
Click to collapse
Thanks man! it worked...do you have problems with apps using mobile data?? beacause i have somes apps that only works with wifi and every app is with all permissions
edzamber said:
Hi,
Try to flash this by TWRP Recovery, it should fix Screen overlay permissions
http://www.mediafire.com/?ouxua6rkkagi3g9
Click to expand...
Click to collapse
What exactly does this do? Install GooglePackageInstaller?
xdapowerapps said:
What exactly does this do? Install GooglePackageInstaller?
Click to expand...
Click to collapse
no, install from TWRP mode, it works for me, thanks my friend
edzamber said:
Hi,
Try to flash this by TWRP Recovery, it should fix Screen overlay permissions
http://www.mediafire.com/?ouxua6rkkagi3g9
Click to expand...
Click to collapse
Will this also work on Nougat? Running resurrection remix 5.8 on Mi max Hydrogen. Running LMT Pie launcher prevents me from granting any permissions or sideloading any APKs. Is this specifically for the Mate S?
If it's safe to flash on nougat on the Mi Max, I could try it on Mi Max.
Given the situation that I needed to unlock bootloader and install TWRP inorder to be able to do full image backup (i.e. Nandroid), I have been wondering what are the underlying security issues to be faced after unlocking and installing TWRP (without moving onto root) in a specific situation where the device is lost or stolen?
Lets say if I am on stock OOS with encryption enabled + Fingerprint and password/pin set on lock screen + USB debugging disabled + locked bootloader + stock recovery, in the unfortunate event where my device were to get lost or stolen, I can expect my personal data to be safe from prying eyes since the person who has gotten a hold of my phone will have to do a factory reset to get into the phone or unlock bootloader which all meant my personal data will be wipe. So that's a good outcome in an unfortunate one.
But let's say if now I were to (i) unlock my bootloader and (ii) install TWRP (but retaining it as read only without system modification), (iii) restore all app, data and settings, and go on to (iv) perform a nandroid backup. And after that, proceed to (v) disable USB debugging and (vi) re-enable encryption and (vii) set fingerprint and password on lock screen. And I shall stopped there without rooting or flashing dm verity. Can I still expect my personal data to be safe from prying eyes in the event of lost or stolen? Meaning that whoever gets a hold of my device will likewise need to wipe it clean before he/she is able to use it? Is this the case or can the person access my data using some hacks now that the device runs custom recovery?
An interesting guide I had came across contained various means of accessing personal data (read - https://forum.xda-developers.com/showthread.php?t=2620456) by bypassing android password, patterns, etc set on the locked screen, and some methods required USB debugging to be enabled while some required custom recovery installed.
To be sure if I am still able to protect my personal data when device is stolen/lost with an unlocked/TWRP installed device, my curiosity took me on an investigative path using an old Samsung Note 3 to unlock bootloader and install TWRP, then proceed to enable encryption and disable USB debugging and set lockscreen password. And now for the next couple of days where I can find free time, I will try out all 7 methods to see if an unlocked Note3 with TWRP is susceptible to these security compromise. I will come back to this thread later to update my findings.
I really welcome any information or inputs too!
To summarize, the state of my old Note 3 used in this investigation is as follows:
1) Bootloader unlocked
2) TWRP (3.0.2) installed as "read only" without system modification
3) ROM (CM13) encryption enabled
4) Locked screen password set
5) Device not rooted
6) USB debugging disabled
When I boot into TWRP, I realized that even if I set it to read only, any person who has gotten hold of my device can set it to system modification since TWRP is not password or pin protected. Therefore setting to "read only" is sort of irrelevant in this investigation to find out how vulnerable the device is right now.
The second thing I realized, is TWRP will ask me for android password to mount my internal sdcard since my ROM is encryption enabled. This is a good thing, since in this case TWRP internal file manager will not be able to access my device internal sdcard containing some of my personal data.
The 1st method I tried is:
METHOD I
Solution For Everyone With Recovery (Cwm, Twrp, Xrec,Etc...) Installed:
INSTRUCTIONS:
1. Download this zip Pattern Password Disable (Download from attachments) on to your sdcard (using your PC, as you cant get into your phone, right )
2. Insert the sdcard into your phone
3. Reboot into recovery mode
4. Flash the zip
5. Reboot
6. Done!
Note : If You See The Gesture Pattern Grid Or Password After Restarting, Don't Worry. Just Try Any Random Pattern Or Password And it Should Unlock.
The steps I took:
A) Set TWRP to system modification
B) When TWRP asked me for password to mount partition, I choose "cancel" since I am trying to imitate the person who has gotten hold of my device won't be able to guess my password
C) Flashed the pattern password disable zip file
And voila!... my password on locked screen is still intact. Meaning that entering any random password does not gain access into android. Only the original password can.
Good news certainly. Don't know why this hack doesn't work, probably it is outdated or probably due to my system is still encrypted when I flashed the hack zip file.
As to the 2nd method, I didn't try out as I don't know how to use Cygwin...
METHOD 2
Solution For Everyone Without Recovery Installed - ADB :
What You Need:
=>A computer running a Linux distro or Windows+Cygwin
=>USB cable to connect your phone to the PC
=>Adb installed
How to install adb:
1. Open Terminal
2. Type:
Code:
sudo apt-get install android-tools-adb
Hit [Enter]
3. Follow the instructions until everything is installed.
INSTRUCTIONS:
1. Connect you (turned on) Phone to the Computer via USB.
2. Open a terminal window.
3. Type:
Code:
adb devices
adb shell
cd data/system
su
rm *.key
4. Done...Now You Just Have To Reboot.
Note : If You See The Gesture Pattern Grid Or Password After Restarting, Don't Worry. Just Try Any Random Pattern Or Password And it Should Unlock.
Method 3 is irrelevant to this investigation therefore it has been omitted.
METHOD 3
Solution For Everyone Before Lock Accident :
SMS Bypass - Download Link - Install It On Your Device (Download from attachments)
This App Allows You To Remotely Bypass Your Phone's Screen Lock By Sending A SMS.
It Removes Your Gesture Pattern Or Password After Receiving A Preset Keyword Along With A Secret Code Via SMS.
SMS Bypass App Requires Root.
INSTRUCTIONS:
1.First, make sure you give permanent root access to the app.
2.Change the secret code to your preferred choice. The default password is : 1234
3.To reset your screen lock, send the following message from another phone:
Code:
secret_code reset
Example:
Code:
1234 reset
Note 1 : There is a space between your secret code and reset. Also the secret code is case sensitive.
Note 2 : There is an option available to change the preset keyword. Default is : reset - Your phone will restart and your lock screen will be reset.
Note 3 : If You See The Gesture Pattern Grid Or Password After Restarting, Don't Worry. Just Try Any Random Pattern Or Password And it Should Unlock.
Given that method 5 is in fact similar to method 2 therefore it has been omitted as well.
METHOD 5
Solution For Everyone Via Adb - File Removal :
INSTRUCTIONS:
=>Type This Command In Your Terminal (CMD Prompt) :
Code:
adb shell rm /data/system/gesture.key
Note : If You See The Gesture Pattern Grid Or Password After Restarting, Don't Worry. Just Try Any Random Pattern Or Password And it Should Unlock.
Method 6 will not work since that hack required USB debugging to be enabled.
METHOD 6
Solution For Everyone With USB Debugging Enabled :
INSTRUCTIONS:
Primary Step for all method:
Download & Extract to anywhere - Bypass Security Hack (Download from attachments)
Open SQLite Database Browser 2.0.exe in SQLite Database Browser.
Run pull settings.db.cmd inside By-pass security Hacks folder to pull out the setting file out of your phone.
Drag settings.db and drop to SQLite Database Browser 2.0.exe program.
Navigate to Browse data tab, At table there, click to list down the selection & selete secure
Instruction To Remove Pattern Lock:
Now, find lock_pattern_autolock, Delete Record
Close & save database
Run push settings.db.cmd and reboot your phone
Instruction To Remove PIN Lock:
Now, Find Or Create lockscreen.password_type, double-click & change it's value to 65536, Apply changes!
Now, find lock_pattern_autolock, Delete Record, If doesn't exist, Ignore
Close & save database
Run push settings.db.cmd and reboot your phone
Instruction To Remove Password Lock:
Now, find lockscreen.password_salt, Delete Record
Now, find lockscreen.password_type, Delete Record
Close & save database
Run push settings.db.cmd and reboot your phone
Note : If You See The Gesture Pattern Grid Or Password After Restarting, Don't Worry. Just Try Any Random Pattern Or Password And it Should Unlock.
I then tried out method 7 using the Aroma file manager however all these 3 versions (Version 2.00 [BETA1]- KACAPI, aromafm-1.91, and aromafm-1.90) does not open up after flashing the zip with system modification enabled on TWRP. Mostly likely these outdated versions of the Aroma file manager are not supported by the latest version of TWRP (3.0.2) since the developers have ceased all work related to it.
METHOD 7
Solution For Everyone With Recovery Installed :
INSTRUCTIONS:
1.Download and Copy Aroma File manager.zip (Download from attachments or http://forum.xda-developers.com/show....php?t=1646108) to your memory card.
2. Open your recovery (press volume Down + Power button or it can be different according to the phones. Generally the phones who have press able button on the middle they have to press all three buttons. Google for you pattern there are lots)
3. There’ll b an option in recovery called “mount”. Go in that option and then mount all the cache and everything it is there.
4. Then select “update” and select “apply update from SD/external” and select aroma file manger.zip file that you downloaded using above QR code above.
5. After Flashing or updating, the aroma file manger will open. Use volume keys for up/down and power button 2 select like you use to get into recovery.
6. In aroma File manager , Go to menu , which is located in bottom strip and then select Settings.
7. Go to bottom n select “mount all partition in startup ” then exit from aroma file manger.
8. Now after exit , re-update that aroma file again and it will open again.
9. Go to data >> and then System.
Then find ‘gesture.key’ (for pattern lock) and ’password.key’ (for password lock) then long touch on gesture.key or password.key and sum option will be prompted , choose delete and delete that file and restart.
Note : If You See The Gesture Pattern Grid Or Password After Restarting, Don't Worry. Just Try Any Random Pattern Or Password And it Should Unlock.
And now onto the last method which is method 4 using SQL command. After starting adb daemon, adb devices are not found and hence the following steps could not be taken. I think this could be due to the device having USB debugging disabled. Hmmm...
METHOD 4
Solution For Everyone Via Adb - SQL Command :
INSTRUCTIONS:
=>Type This Commands Separated In Your Terminal (CMD Prompt) :
Code:
adb shell
cd /data/data/com.android.providers.settings/databases
sqlite3 settings.db
update system set value=0 where name='lock_pattern_autolock';
update system set value=0 where name='lockscreen.lockedoutpermanently';
.quit
=>Now You Just Have To Reboot.
Note : If You See The Gesture Pattern Grid Or Password After Restarting, Don't Worry. Just Try Any Random Pattern Or Password And it Should Unlock.
After going through all these methods, I am inclined to think that personal data is still protected in an unlocked/TWRP installed device as long as USB debugging is DISABLED and ROM is encrypted and fingerprint/password set on lock screen. What do you think?
As long as your data is encrypted, it is safe and not accessible to any 3rd party.
But with an unlocked bootloader, you are open to a new forms of attacks like:
1. someone could steal your phone, modify your system to leak your data / password and then return it to you. Since dm-verity is OFF, you will not know, that your system is compromised.
2. someone could use a remote exploits (to launch his code and gain root privileges) to modify your system and leak your data / password and since dm-verity is OFF, you will not know, that your system is compromised.
+ with the unlocked bootloader, FRP is not working, so a thief can just reset your phone and sell it.
If your data security is a huge concern to you, DO NOT unlock the bootloader.
If you are a potential target to a hacker attacks, DO NOT use a OnePlus phone. Get a Nexus 6P or a Pixel.
Also make sure, that your apps are not leaking your data. Apps with a storage permission and access to the internet could leak your data.
Michalko5896 said:
As long as your data is encrypted, it is safe and not accessible to any 3rd party.
But with an unlocked bootloader, you are open to a new forms of attacks like:
1. someone could steal your phone, modify your system to leak your data / password and then return it to you. Since dm-verity is OFF, you will not know, that your system is compromised.
Click to expand...
Click to collapse
Many thanks for your response! This is very useful information to me.
Am I right to assume that even if my device is unlocked but with encryption enabled and no root, the person who has gotten hold of my phone will still be able to flash "dm-verity and forced encryption disabler" zip and supersu zip files to root my device in TWRP even when he fails to enter the password prompted by TWRP?
And this force encryption disabler as the name suggest only disable force encryption and it does not decrypt my already encrypted personal data? Which means he still does not have access to my data and after he had done the system modification and returns the phone back to me, the first thing I should do is to wipe clean every partition and restore back my nandroid which would consist of backups to all partitions. So it seems this is an acceptable risk all for the convenience of performing nandroid backup via the unlock/TWRP route.
2. someone could use a remote exploits (to launch his code and gain root privileges) to modify your system and leak your data / password and since dm-verity is OFF, you will not know, that your system is compromised.
+ with the unlocked bootloader, FRP is not working, so a thief can just reset your phone and sell it.
If your data security is a huge concern to you, DO NOT unlock the bootloader.
If you are a potential target to a hacker attacks, DO NOT use a OnePlus phone. Get a Nexus 6P or a Pixel.
Also make sure, that your apps are not leaking your data. Apps with a storage permission and access to the internet could leak your data.
Click to expand...
Click to collapse
Very good point here. May I ask in what ways are Nexus 6P and Pixel more secure than Oneplus? Pixel seemed quite an attractive phone.
I am on OOS 3.5.3, is there anyway to find out what apps have access to internet and restrict that?
The app permission section of settings only allows changing permission to storage (among others) but I couldn't find any internet access permission.
The main security risk is that it allows anyone to flash something harmful without you knowing on to your system. Your data may be encrypted and protected but they can still flash something onto another partition.
You could be happily using your phone unaware there's a rogue app capturing and sending data to someone.
Zegnalabel said:
Many thanks for your response! This is very useful information to me.
Am I right to assume that even if my device is unlocked but with encryption enabled and no root, the person who has gotten hold of my phone will still be able to flash "dm-verity and forced encryption disabler" zip and supersu zip files to root my device in TWRP even when he fails to enter the password prompted by TWRP?
And this force encryption disabler as the name suggest only disable force encryption and it does not decrypt my already encrypted personal data? Which means he still does not have access to my data and after he had done the system modification and returns the phone back to me, the first thing I should do is to wipe clean every partition and restore back my nandroid which would consist of backups to all partitions. So it seems this is an acceptable risk all for the convenience of performing nandroid backup via the unlock/TWRP route.
Very good point here. May I ask in what ways are Nexus 6P and Pixel more secure than Oneplus? Pixel seemed quite an attractive phone.
I am on OOS 3.5.3, is there anyway to find out what apps have access to internet and restrict that?
The app permission section of settings only allows changing permission to storage (among others) but I couldn't find any internet access permission.
Click to expand...
Click to collapse
Your data is safe, it can't be decrypted, even with an unlocked bootloader And yes, if you wipe every partition, lock the bootloader and got no dm-verity error, after your stolen phone was returned to you, you should be safe.
Both Nexus 6P and Pixel are much safer than OnePlus, because they are getting a complete security patches every month. OnePlus is getting an imcomplete security patches and much later after their release.
You can limit access to internet via app settings. Open "about app", data usage and there you can turn off both access to wifi and mobile data.
Upgrade to OOS 4.0, it cointains important security patches and enhancements.
Michalko5896 said:
Your data is safe, it can't be decrypted, even with an unlocked bootloader And yes, if you wipe every partition, lock the bootloader and got no dm-verity error, after your stolen phone was returned to you, you should be safe.
Both Nexus 6P and Pixel are much safer than OnePlus, because they are getting a complete security patches every month. OnePlus is getting an imcomplete security patches and much later after their release.
You can limit access to internet via app settings. Open "about app", data usage and there you can turn off both access to wifi and mobile data.
Upgrade to OOS 4.0, it cointains important security patches and enhancements.
Click to expand...
Click to collapse
Thank you so much! Found the data usage setting and updated to 4.0. :laugh:
Michalko5896 said:
As long as your data is encrypted, it is safe and not accessible to any 3rd party.
But with an unlocked bootloader, you are open to a new forms of attacks like:
1. someone could steal your phone, modify your system to leak your data / password and then return it to you. Since dm-verity is OFF, you will not know, that your system is compromised.
2. someone could use a remote exploits (to launch his code and gain root privileges) to modify your system and leak your data / password and since dm-verity is OFF, you will not know, that your system is compromised.
...
Click to expand...
Click to collapse
Quick question, does the latest systemless SuperSU still leave dm-verity OFF ? It was my understanding that using it you don't need to flash the dm-verity-OFF script, is that true?
xclub_101 said:
Quick question, does the latest systemless SuperSU still leave dm-verity OFF ? It was my understanding that using it you don't need to flash the dm-verity-OFF script, is that true?
Click to expand...
Click to collapse
For root, you need to unlock the bootloader. And with the bootloader unlocked, dm-verity is not working and thus attacker could modify your system.
Michalko5896 said:
For root, you need to unlock the bootloader. And with the bootloader unlocked, dm-verity is not working and thus attacker could modify your system.
Click to expand...
Click to collapse
The bootloader being locked/unlocked should have little to do (directly) with dm-verity, dm-verity is only hash-checking the system partition.
That being said after some checking various detailed threads from Chainfire apparently SuperSU is still removing the dm-verity on the system partition since other than rooting in itself most rooted people also tend to touch the system partition with stuff like busybox and so on, so I guess this is it.
xclub_101 said:
The bootloader being locked/unlocked should have little to do (directly) with dm-verity, dm-verity is only hash-checking the system partition.
That being said after some checking various detailed threads from Chainfire apparently SuperSU is still removing the dm-verity on the system partition since other than rooting in itself most rooted people also tend to touch the system partition with stuff like busybox and so on, so I guess this is it.
Click to expand...
Click to collapse
well, google is stating, that unlocking bootloader will turn off the dm-verity.
This is an interesting discussion- I have a Nexus 5X, but I use a custom configuration:
1) locked bootloader
2) verity turned on for the system partition so that I can check the key fingerprint and verify integrity.
3) customized cm recovery - I installed my adb keys so I can connect to it. I also changed the signing keys, so I have to sign any roms that get flashed.
4) encrypted userdata with pattern protection. I think a password would be stronger, but I'm using a larger, complex pattern. Fingerprint unlock is turned on, which has its own attack surface.
I think the fingerprint sensor is the biggest risk. This is mitigated at reboot since the pattern will be required. If I built the recovery properly, the only way to flash anything would be to have access to my signing keys or adb keys. Of course, this is all still vulnerable to any unpatched exploits.
Dear fellow mixers,
I try to achieve the combination of:
MIUI 9 Android 7.0 either from EpicROM or xiaomi.eu
Installing Magisk systemless root
Installing Xposed for magisk
3 Questions:
Anyone achieved this already? If yes, can you tell us which version/release of MIUI, which variant of Magisk & Exposed did you use?
If someone didn't do it, but knows which combination of MIUI, Magisk and Xposed (especially which versions and mods) should work in theory, can you say so?
To my understanding this should help to *not* trip safetynet and allow us to run Snapchat?
My research so far:
According to this post, Unofficial Xposed 88.1 for MIUI9 SDK24 should work
According to this post, 88.1 works and xmiui also has a magisk zip
Another guide that seems to be written before 88.1 was released with MIUI 9 compatibility. So I'm confused which guide to follow, which combination of systemless xposed/magisk will work?
Edit:
I'll use my experiences and document them here to later create another how-to for systemless magisk/xposed on miui9 and another guide how to properly backup second space apps.
Second space backup:
Using Titanium Backup installed and started in First Space will only backup first space apps. Installing Titanium Backup in Second space also didn't work properly for me for some apps like LINE messenger.
Actually there are two (somethimes three) places that need to be backed up:
1. App APK (the installation files itself)
/data/app/<appname>
for both spaces, because they use the same app installation, as no user data is saved here, so it's in a single location, no matter how many android user accounts or MIUI spaces you have.
2. App's user data (like LINE Messenger database etc. normally not visible to you but important):
First space: /data/user/0/<appname>
Second space: /data/user/10/<appname>
This is unique for every user account (or miui space), here individual data is being saved, like two different LINE messenger accounts, or FB accounts.
3. User's accessible app data (where your app stores things that you produce in your apps and are visible to you when connecting your phone to your PC or checking your sdcard/internal storage):
First Space: /storage/emulated/0/<folder>
Second Space: /storage/emulated/10/<folder>
the folder names can be a mess here, whatsapp names their user data folder simply Whatsapp. Here they store your chat history DB, your downloaded pictures, videos and audio. Other apps can basically name their folder however they want and sometimes it's difficult to find out what folder your app stores files in. The app "Magix Pro Screen Recorder" as a fictional example could store your screen recordings in /storage/emulated/0/Movies/recordings/
To properly backup whatsapp in second space:
copy /storage/emulated/10/whatsapp folder to your PC
in new rom/phone create second space, then copy the backup form your PC to the same location as above in your new rom/phone
install whatsapp from play store, open it and it should recognize the backup and ask you to directly restore it
To properly backup a more complex app that uses all three folder types described above I take Naver LINE Messenger as an example:
backup /data/user/10/jp.naver.line.android/ *
backup /data/app/jp.naver.line.android-1 *
in new rom/phone create second space, then copy the backups to the same locations as above
don't open line app yet
install terminal emulator and delete the previous LINE settings by using the following commands:
su
sqlite3
/data/user/10/jp.naver.line.android/databases/naver_line
delete from setting;
.quit
if you don't have the sqlite3 binary, you can try to find it online for android (arm64 binary), paste it to your /bin folder and try again, or open the file on your computer with an sqlite explorer
if available, delete the following xml:
/data/user/10/jp.naver.line.android/shared_prefs/jp.naver.line.android.settings.xml
open the Line app and it will ask you to enter your user and password
Alternative method:
backup /data/user/10/jp.naver.line.android/
backup /data/app/jp.naver.line.android-1
in new rom/phone create second space, then copy the backups to the same locations as above
don't open line app yet
use an sqlite editor on your phone or on your pc to empty the following database:
/data/user/10/jp.naver.line.android/databases/naver_line
start line
My preferred method:
on old phone, install device id changer pro in second space and open it
note down device ID
backup /data/user/10/jp.naver.line.android/
backup /data/app/jp.naver.line.android-1
in new rom/phone create second space, then copy the backups to the same locations as above
don't open line app yet
install device id changer pro in second space and open it
enter the previously noted down device ID and set it
start line
* creating proper backups of the two LINE folders is a whole procedure again, we need to use tar gz to preserve permissions when copying and pasting:
- enable developer mode and usb debugging
- connect to pc
- install minimal adb & fastboot on your PC
- start cmd, execute:
adb shell
- accept popup on device, then type into cmd:
su
- accept supersu on device
- type:
cd /data/user/10/jp.naver.line.android
tar -cvpzf /storage/emulated/0/user-10-jp.naver.line.android.tar.gz .
cd /data/user/0/jp.naver.line.android
tar -cvpzf /storage/emulated/0/user-0-jp.naver.line.android.tar.gz .
cd /data/app/jp.naver.line.android-1
tar -cvpzf /storage/emulated/0/app-jp.naver.line.android-1.tar.gz .
- copy the 3 backup tar.gz files into your first space internal storage, and type:
cd /storage/emulated/0/
tar xpvzf user-10-jp.naver.line.android.tar.gz /data/user/10/
tar xpvzf user-0-jp.naver.line.android.tar.gz /data/user/0/
tar xpvzf app-jp.naver.line.android-1.tar.gz /data/app/
Reported Psyman version seems work and sometimes... latest build officialy released by Rovo works... then u need made a backup and try to flash a magisk version, lastest will have more chance to work because include all report from git...
And a lot of xposed module need to be updated....
cheers
I wasn't unable to make xposed 88.0 or 88.1 to work with the latest N MIUI 9 Epic rom using magisk. the only version that worked for me was V87 xposed but somehow gravity box didn't seen to work well when enabling setting and applying theme, that is gravity older version not the newest the newest version require xposed 88 and newer which didn't activated on N MIUI 9 Epic newest rom, exMIUI did work though
Ok, some news...
Lastest stable from Xiaomi.eu (9.1 - 7.0 - SDK 24) works with magisk and xposed... only need good version and right apk...
Cheers
Magisk Module Systemless Debloater
Download:
GitHub - zgfg/SystemlessDebloater: Select and systemlessly debloat preinstalled system apps. Supporting up to System As Root (SAR), Dynamic partitions and Android 13. Module must be installed through Magisk app, not TWRP
Select and systemlessly debloat preinstalled system apps. Supporting up to System As Root (SAR), Dynamic partitions and Android 13. Module must be installed through Magisk app, not TWRP - GitHub - ...
github.com
GitHub - Magisk-Modules-Alt-Repo/SystemlessDebloater: Select and systemlessly debloat preinstalled system apps. Supporting up to System As Root (SAR), Dynamic partitions and Android 13. Module must be installed through Magisk app, not TWRP
Select and systemlessly debloat preinstalled system apps. Supporting up to System As Root (SAR), Dynamic partitions and Android 13. Module must be installed through Magisk app, not TWRP - GitHub - ...
github.com
Wiki pages by @ipdev:
ConfigScript
Guide for the Systemless Debloater Module. Contribute to mModule/guide_sDebloater development by creating an account on GitHub.
github.com
with his examples of apps that can be debloated (Android, Google, Oppo, Samsung, Xiaomi, LineageOS):
CommunityList
Guide for the Systemless Debloater Module. Contribute to mModule/guide_sDebloater development by creating an account on GitHub.
github.com
*** Yet another System(less) debloater, how and why?
- Systemless means that all changes made are active only when Magisk is loaded and module is enabled.
For OTA or anything, just disable the module (or boot without Magisk) and your system partitions are no more affected
- For Android up to 9 and/or 10 (depending on devices), system partitions were read-write, hence hard-debloating by use of eg TWRP, Titanium, etc (to delete the pre-installed system apps) was possible
This is no more possible for the phones released with Android 10 and higher.
System (System As Root, Dynamical partitions) becomes read-only on the file-system level and stock apps could be debloated (the same holds for any changes on the system partitions) only by the systemless approach - by use of Magisk to dynamically overlay the required changes at boot time
Hence, this module also uses the Magisk REPLACE mechanism and dynamical mounting through the module's service.sh script
- The module debloates only (stock) apps pre-installed to the system partitions, traditionally named as /system, /system-ext, /product, /vendor and /apex; plus additionally on A12 and A13 devices, variably named system partitions like /india, /my_bigball, etc
Hence sorry, to debloat user apps installed to /data, please use the other methods (first of all, just simply uninstall them or at least uninstall their updates)
- Originally I started development with Xiaomi Mi 9T (MIUI 10-12.5, Android 10-12) and later continued with Xiaomi 11 Lite 5G NE (MIUI 12-13, Android 11-12). However, the module relies on the common Magisk overlay mechanism and the list of apps to be 'debloated' is configurable hence there are many users who successfully use this module on the various other devices (like Pixel, Samsung, One Plus, etc.), with the stock or custom ROMs, and with up to Android 13
- Original, default list coming when the module is installed will be empty - user must define then himself which apps should be debloated, depending on his device, ROM and preferences
To (re)configure the list of apps for debloating, simply edit the (textual) /Download/SystemlessDebloater.cfg config file on Internal memory.
Module automatically installs the config file with instructions inside but with the empty list
(Re)configure your list of system apps you want to debloat, reinstall the module (always through the Magisk Manager, not TWRP) and reboot - to take your changes in effect
You only need to provide the proper names (not package names) for the preinstalled system apps, the module will find their exact System paths
- However, the user bears the risks and responsibility himself (device may no more boot when certain system apps are removed/debloated) but the Troubleshooting section below provides instructions how to recover, even from the bootloop cases
Nevertheless, whenever you want to 'debloat' some service or app you are not familiar with, please google first to find what that app is really about and is it generally safe to be debloated (on your but also on the other phones and even by other methods, it doesn't matter)
Don't be afraid of the module and debloating, but be cautious what are you going to debloat
*** Installation
- Download the latest module from GitHub - scroll down, open Assets and find the latest v1.5.3 zip:
https://github.com/zgfg/SystemlessDebloater/releases/tag/153
- In Magisk app (manage), open Modules tab and take Install from storage, navigate to the downloaded SystemlessDebloater.zip (as is, do not unzip)
Read what Magisk prints while installing and find the module's log in /Download/SystemlessDebloater.log file on Internal memory
To finish the installation (it applies to all Magisk modules), reboot the phone
- First time the module will not debloat anything - it will just create the input/config file /Download/SystemlessDebloater.cfg on Internal memory
Open that config file, read the instructions in the file and fill your own list of app names for debloating - look at the commented examples you will find in that config file
- Save the config file, reinstall the module and reboot.
Inspect the log and consult the Troubleshooting section below if needed
- To find what system apps you have on your phone and what are their exact names, scroll down through the SystemlessDebloater.log to the "System apps, not debloated" section
Find e.g. a line:
/system/app/Email (com.android.email)
Then copy/add just the Email name (supposed that you want to debloat the built-in Email app) into the SystemlessDebloater.cfg config file
Repeat for the other apps you want to debloat. Then reinstall the module (only on the reinstallation, module processes the config file) and reboot
Fine tune your list of apps for debloating but every time reinstall the module and reboot
- Last but not the least: Once debloated, apps can no more be found (until you reconfigure, disable or uninstall the debloater) under the Settings / Apps
Hence, if you want to delete their cache or data, do Clear cache/data before debloating the apps
Moreover, before trying to debloat any app, look first if you could simply Uninstall that app (ie, if it was a user and not the system app) from Settings / Apps
If Uninstall is not available for that app, try to Uninstall updates: updates are also installed to Data while SystemlessDebloater 'debloats' only from the System - hence the app's update on Data may still remain there
*** Troubleshooting
- What if I eg have configured the app EMail to debloat, but the app is still present?
Check if you have missed to perform Uninstall / Uninstall updates from Settings, Apps - perform, reboot and test again
Check if you have miss-spelled the application name - correct in the config file SystemlessDebloater.cfg, save, reinstall the module and reboot
App names are cases sensitive - eg, the correct name might be Email, not EMail
- To help yourself, use eg Package Manager app (from Playstore) where you can search for all the apps/services, find their exact names and installation paths (to see are them System or User apps)
- What if I change my mind and I want to un-debloat and use Email, but to debloat now eg, Chrome browser?
No problem, reconfigure the list in SystemlessDebloater.cfg, save, reinstall the module and reboot
- What if after a week or so, I realize that some functionalities on the phone were affected?
Sorry, you had decided to debloat the 'wrong' apps/services
Google about which app(s) are safe to debloat or not, reconfigure your list in the config file, reinstall the module and reboot
Or disable the module and reboot, to figure out was the problem really due to debloating
- Oops, what if I have a bootloop (phone does no more boot since the 'wrong' apps were debloated)?
If you have TWRP with the read/write access to Data, navigate to /data/adb/modules/SystemlessDebloater and by using Advanced / File explorer from TWRP, create a dummy file named disable (without extension) in that folder
Reboot and Magisk will boot but with the debloater disabled - hence, all the previously debloated apps will be un-debloated now (to see if debloating was really responsible for the bootloop)
Instead of dummy file named disable, put the remove dummy file to trigger Magisk to uninstall that module on the next reboot (all that applies to any module possibly causing your bootloops)
If the proper TWRP is not available for your device and ROM, boot to the Android Safe Mode - google for a key-combo to boot in, for my Xiaomi it takes (re)booting with Vol+ and Vol+ pressed simultaneously
Don't do anything in Android Safe mode but reboot then to 'normal' mode - Magisk will boot now with all the modules disabled (this method does not work for Magisk v20.4 or earlier)
You will have to re-enable MagiskHide/DenyList (don't worry, your list of apps to hide the Magisk from was not lost), re-enable the other modules, correct SystemlessDebloater.cfg, reinstall debloater and reboot
There is also a third method (adb wait-for-device shell magisk --remove-modules), but search yourself and read about from the Wiki Documentation on the Magisk GitHub page
*** Enough for the theory, install now and practice debloating
IMPORTANT
Since the version v1.5.1, SystemlessDebloater module supports a new SystemlessDebloater.cfg config file - thanks to @ipdev
Update will create the new config file and transfer your DebloatList
Please delete then your old SystemlessDebloaterList.sh input file and read and use the new config file instead
---
For more info about the SystemlessDebloater.cfg config file, please see: Wiki pages from @ipdev:
ConfigScript
Guide for the Systemless Debloater Module. Contribute to mModule/guide_sDebloater development by creating an account on GitHub.
github.com
and his examples what apps can be debloated (Android, Google, Oppo, Samsung, Xiaomi, LineageOS):
CommunityList
Guide for the Systemless Debloater Module. Contribute to mModule/guide_sDebloater development by creating an account on GitHub.
github.com
On my Xiaomi Mi 9T, eea Stable QFJEUXM 12.0.2 I safely debloat the following apps:
Code:
DebloatList="
AnalyticsCore
AntHalService
BasicDreams
BookmarkProvider
CatchLog
Chrome
CneApp
EasterEgg
facebook-appmanager
facebook-installer
facebook-services
FileExplorer_old
GlobalFashiongallery
GlobalMinusScreen
Gmail2
GoogleFeedback
GooglePartnerSetup
HybridAccessory
HybridPlatform
IdMipay
InMipay
Joyose
MiBrowserGlobal
MiBrowserGlobalVendor
MiCreditInStub
MiDrop
MiLinkService2
MiPicks
MiPlayClient
MiRcs
MiRecycle
MiService
MiuiBrowserGlobal
MiuiBugReport
MiuiDaemon
MSA-Global
Netflix_activation
Notes
PartnerBookmarksProvider
PaymentService
PhotoTable
Stk
TouchAssistant
Traceur
Turbo
uceShimService
Velvet
VsimCore
wps_lite
YellowPage
Zman"
E.g., I debloat YouTube and install Vanced YT root.
Similarly, I debloat GMail, Wellbeing, Netflix, Facebook, Turbo, etc - inspect and exclude from the list those apps you want to keep
Also, DebloatList I used for Mi 9T but Xiaomi.eu weekly 20.9.17 (MIUI 12, Android 10):
Code:
DebloatList="
AndroidAutoStub
AntHalService
BookmarkProvider
Browser
BTProductionLineTool
Calculator
CatchLog
CneApp
EasterEgg
Email
GoogleFeedback
GooglePartnerSetup
Health
Joyose
Lens
MiMover
MiPlayClient
MiRecycle
MiService
MiuiBugReport
MiuiDaemon
Notes
PaymentService
Stk
TouchAssistant
Traceur
uceShimService
Velvet
VsimCore
WebViewGoogle
wps_lite"
and for Xiaomi.eu Stable 12.0.6:
Code:
DebloatList="
AndroidAutoStub
AntHalService
BookmarkProvider
Browser
BTProductionLineTool
Calculator
CatchLog
CneApp
EasterEgg
Email
GoogleFeedback
GooglePartnerSetup
Health
Joyose
Lens
MiMover
MiPlayClient
MiRecycle
MiService
MiuiBugReport
MiuiDaemon
Notes
PaymentService
Stk
TouchAssistant
Traceur
uceShimService
Velvet
VsimCore
WebViewGoogle
wps-lite"
You may exclude e.g., Calculator,Email, Health or Lens, if you want to use them.
You can expect most of these apps also on the other MIUI firmwares. Installation folders on System may vary, but module will find their paths
EDIT:
SystemDebloaterList.sh and DebloatList were used in the module versions v1.5.0 and earlier, since v1.5.1 the module uses SystemDebloater.cfg
Thanks a lot to @ipdev for discussing and sharing ideas, encouraging and for successful testing on Xiaomi Poco F2 (debloater found most of the same MIUI apps as above) and OnePlus 5T
Also, thanks for your successful test on Pixel 3aXL with Android 11:
ipdev said:
Works on Pixel 3aXL. (Stock Android 11. Magisk canary.)
Attached the SystemlessDebloater.log from 3aXL.
And the SystemlessDebloaterList.sh I use for testing. (remove the .txt)
Click to expand...
Click to collapse
Reserved
Over the weekend when I have time to fix any potential bricking or boot loops, I'm going to try this on my A/B device (One Plus 7Pro, GM1917, OOS 10.3.5) ... unless before then anyone indicates that this is not even likely to work on my phone.
If I end up doing this, I'll report my results.
.
HippoMan said:
Over the weekend when I have time to fix any potential bricking or boot loops, I'm going to try this on my A/B device (One Plus 7Pro, GM1917, OOS 10.3.5) ... unless before then anyone indicates that this is not even likely to work on my phone.
If I end up doing this, I'll report my results.
.
Click to expand...
Click to collapse
It does not matter if it system-as-root or a slot device.
By time modules are run, system paths are set.
The active slot partition is running, and (if needed) switch root has happened.
Root directory is set to / and system directory is set to /system
curious about OxygenOS, do not run it very much so I am not sure what should/could be removed.
Cheers.
PS.
Works on Pixel 3aXL. (Stock Android 11. Magisk canary.)
Attached the SystemlessDebloater.log from 3aXL.
And the SystemlessDebloaterList.sh I use for testing. (remove the .txt)
Quick edit.
Since the back-side move for xda is still going, there are some errors while in transition.
Since attachment is not working at the moment. GoogleDrive - Link
ipdev said:
It does not matter if it system-as-root or a slot device.
By time modules are run, system paths are set.
The active slot partition is running, and (if needed) switch root has happened.
Root directory is set to / and system directory is set to /system
curious about OxygenOS, do not run it very much so I am not sure what should/could be removed.
Cheers.
PS.
Works on Pixel 3aXL. (Stock Android 11. Magisk canary.)
Attached the SystemlessDebloater.log from 3aXL.
And the SystemlessDebloaterList.sh I use for testing. (remove the .txt)
Click to expand...
Click to collapse
OxygenOS isn't as bad, bloat-wise, as some other OS's, such as what comes with Samsung. But there are still things that I don't want, such as the OnePlus camera and a few other items.
I'll report back here after I try this.
.
ipdev said:
It does not matter if it system-as-root or a slot device.
By time modules are run, system paths are set.
The active slot partition is running, and (if needed) switch root has happened.
Root directory is set to / and system directory is set to /system
curious about OxygenOS, do not run it very much so I am not sure what should/could be removed.
Cheers.
PS.
Works on Pixel 3aXL. (Stock Android 11. Magisk canary.)
Attached the SystemlessDebloater.log from 3aXL.
And the SystemlessDebloaterList.sh I use for testing. (remove the .txt)
Click to expand...
Click to collapse
Thank you for testing on A11.
Log cannot be downloaded, 404?
zgfg said:
Thank you for testing on A11.
Log cannot be downloaded, 404?
Click to expand...
Click to collapse
Looks like some more hiccups on xda back-side again.
Will be nice once the transition is complete, xda will be fast and stable again. :fingers-crossed:
Updated my prior post with a gDrive Link.
If you look at the log, you will notice chrome is not debloated.
The stub is debloated, Chrome (Think it is in product/app) is a gzip version of the Chrome apk.
Chrome is automatically installed into /data/app/HashStringOrSomething/com.android.chrome-HashStringOrSomething/Chome.apk
I have not taken time to look into that change.
Cheers.
ipdev said:
Looks like some more hiccups on xda back-side again.
Will be nice once the transition is complete, xda will be fast and stable again. :fingers-crossed:
Updated my prior post with a gDrive Link.
If you look at the log, you will notice chrome is not debloated.
The stub is debloated, Chrome (Think it is in product/app) is a gzip version of the Chrome apk.
Chrome is automatically installed into /data/app/HashStringOrSomething/com.android.chrome-HashStringOrSomething/Chome.apk
I have not taken time to look into that change.
Cheers.
Click to expand...
Click to collapse
Interesting - what happens when you debloat Chrome-Stub from Product and leave Chrome on Data, does it still run?
Btw, I do use Chrome (because of the integrated translator, making me easy to sometimes read worldwide forums if needed) and I didn't want to debloat originally. However, my preinstalled version on Product was not the latest, and Google Play was offering me to update, but updating Chrome was always failing.
I downloaded the apk from ApkMirror but installation had also failed
Then I debloated (at that time, prior to this debloater I used to manually create my system folder given to Magisk to overlay, and with dummy apk instead of with .replace file) and only then I was able to install Chrome apk (ofc to Data) and since then, to regularly update it through Playstore
One more thing. I've found some people claiming that Chrome breaks to run if Playstore shows Device is not certified.
But back in the spring when Google started to play with enforcing CTS Profile Hardware attest, and prior than @Displax invented ro.product.model spoofing (to force Basic attest and to pass CTS/SafetyNet, to get Device certified), my CTS was failing and Device was not Certified but I had no problems using Chrome on daily basis
---
Also, you have PrebuiltGmail and Music2, I had Gmail2 and FileExplorer_old (I had to use Package Manager to find that Gmail was installed as Gmail2/Gmail2.apk and similarly the Android FileExplore as FileExplorer_old.apk)
Btw all Mi* and Miui* stuff apply only for debloating Xiaomi
In your input list you have lite and wps (both are not found in the log), mine was wps_lite (WPS preinstalled to Vendor) - please check
zgfg said:
Interesting - what happens when you debloat Chrome-Stub from Product and leave Chrome on Data, does it still run?
Btw, I do use Chrome (because of the integrated translator, making me easy to sometimes read worldwide forums if needed) and I didn't want to debloat originally. However, my preinstalled version on Product was not the latest, and Google Play was offering me to update, but updating Chrome was always failing.
I downloaded the apk from ApkMirror but installation had also failed
Then I debloated (at that time, prior to this debloater I used to manually create my system folder given to Magisk to overlay, and with dummy apk instead of with .replace file) and only then I was able to install Chrome apk (ofc to Data) and since then, to regularly update it through Playstore
One more thing. I've found some people claiming that Chrome breaks to run if Playstore shows Device is not certified.
But back in the spring when Google started to play with enforcing CTS Profile Hardware attest, and prior than @Displax invented ro.product.model spoofing (to force Basic attest and to pass CTS/SafetyNet, to get Device certified), my CTS was failing and Device was not Certified but I had no problems using Chrome on daily basis.
Click to expand...
Click to collapse
PlayStore issues are weird at best.
Hit or miss, depends on the device and/or setup.
Certificataion does not seem to play a big part over all.
If it does then Google's has more issues than fixing SafetyNet to worry about.
Sometimes it is just a Google being Google.
I will look into Chrome tomorrow.
I normally use Chrome Dev PlayStore - Link.
More so now, Brave Browser PlayStore - Link.
zgfg said:
Also, you have PrebuiltGmail and Music2, I had Gmail2 and FileExplorer_old (I had to use Package Manager to find that Gmail was installed as Gmail2/Gmail2.apk and similarly the Android FileExplore as FileExplorer_old.apk)
Btw all Mi* and Miui* stuff apply only for debloating Xiaomi
In your input list you have lite and wps (both are not found in the log), mine was wps_lite (WPS preinstalled to Vendor) - please check
Click to expand...
Click to collapse
No harm checking for apps that do not exist on the device.
It may cause extra lines in the log file and one or two seconds of install time.
My bad.
Must have split wps_lite when I was adjusting the list. Then when sorting, it just put lite and wps in the correct order.
---
I re-flashed and/or reverted a few phones tonight and added them to the gDrive Link.
The files listed as _pfile.list (preinstalle files) are a list of files located in app and/or priv-app of system, product and vendor.
I use a shell scripts for this kind of stuff, [ because I am lazy ] primarily with adb shell.
I adjusted the one I use to make the pfile list.
list_pfiles.sh - Still needs to be run as root.
list_pfiles.sh needs to be located in a writable directory. (sdcard/Download | data/local/tmp | ...)
It still uses a static NAME= variable that you will want to change.
I added a few things to make it run from a root file manager like fx or mix.
With the addition (work from a file manager app/or called from a diferent directory), if you rename the script file, you will also have to adjust the SCRIPT= variable to match.
Cheers.
Edit:
2021.Aug.21
I updated the list_pfiles script.
To Use:
Copy this script to the device.
Recommended to use the /sdcard/Download/ directory.
Run from adb shell (or a terminal app) using the sh command.
sh list_pfiles.sh
Run from a file manager that is able to execute a script file.
Note: May or may not work depending on file manager..
ipdev said:
PlayStore issues are weird at best.
Hit or miss, depends on the device and/or setup.
Certificataion does not seem to play a big part over all.
If it does then Google's has more issues than fixing SafetyNet to worry about.
Sometimes it is just a Google being Google.
I will look into Chrome tomorrow.
I normally use Chrome Dev PlayStore - Link.
More so now, Brave Browser PlayStore - Link.
No harm checking for apps that do not exist on the device.
It may cause extra lines in the log file and one or two seconds of install time.
My bad.
Must have split wps_lite when I was adjusting the list. Then when sorting, it just put lite and wps in the correct order.
---
I re-flashed and/or reverted a few phones tonight and added them to the gDrive Link.
The files listed as _pfile.list (preinstalle files) are a list of files located in app and/or priv-app of system, product and vendor.
I use a shell scripts for this kind of stuff, [ because I am lazy ] primarily with adb shell.
I adjusted the one I use to make the pfile list.
list_pfiles.sh - Still needs to be run as root.
list_pfiles.sh needs to be located in a writable directory. (sdcard/Download | data/local/tmp | ...)
It still uses a static NAME= variable that you will want to change.
I added a few things to make it run from a root file manager like fx or mix.
With the addition (work from a file manager app/or called from a diferent directory), if you rename the script file, you will also have to adjust the SCRIPT= variable to match.
Cheers.
Click to expand...
Click to collapse
Pixel comes with only G stuff but interestingly, without Wellbeing
Velvet.apk, what is the package name (you should still be able to find the name on /data/data)?
When you have Velvet (Poco F1, F2 and One+ 5T), do they also have Google.apk = com.google.android.googlequicksearchbox?
Btw, if you use MiXPlorer and choose Tools, App Remnants, you can see /data/data folders for debloated apps (and you can remove them)
HippoMan said:
Over the weekend when I have time to fix any potential bricking or boot loops, I'm going to try this on my A/B device (One Plus 7Pro, GM1917, OOS 10.3.5) ... unless before then anyone indicates that this is not even likely to work on my phone.
If I end up doing this, I'll report my results.
Click to expand...
Click to collapse
I did it just now, and it worked wth no problems on my device! For my initial test, I used SystemlessDebloater to remove GooglePartnerSetup, and it was indeed removed. No bootloops, no problems.
Good work on this module!
zgfg said:
...
Btw, if you use MiXPlorer and choose Tools, App Remnants, you can see /data/data folders for debloated apps (and you can remove them)
Click to expand...
Click to collapse
Well, in my case, GooglePartnerSetup doesn't appear anywhere among MiXPlorer's "App Remnants", even though other /data/data items are indeed being displayed there. But this is not causing any kind of issue on my device, so I am not concerned.
.
zgfg said:
Pixel comes with only G stuff but interestingly, without Wellbeing
Click to expand...
Click to collapse
Don't worry, Google would not forget to bundle it.
Digital wellbeing is named WellbeingPrebuilt.
package: name='com.google.android.apps.wellbeing'
I just did not add it to the debloat list.
zgfg said:
Velvet.apk, what is the package name (you should still be able to find the name on /data/data)?
When you have Velvet (Poco F1, F2 and One+ 5T), do they also have Google.apk = com.google.android.googlequicksearchbox?
Click to expand...
Click to collapse
Velvet is Google.
package: name='com.google.android.googlequicksearchbox'
As far as I know, Velvet is the bundled and/or GApps name used.
Cheers.
HippoMan said:
I did it just now, and it worked wth no problems on my device! For my initial test, I used SystemlessDebloater to remove GooglePartnerSetup, and it was indeed removed. No bootloops, no problems..
Click to expand...
Click to collapse
Just a short question - you have A11 on your OnePlus 7Pro?
zgfg said:
Just a short question - you have A11 on your OnePlus 7Pro?
Click to expand...
Click to collapse
One Plus 7Pro, GM1917, OOS 10.3.5 ... as I mentioned above OOS 10.x is A10.
.
zgfg said:
Interesting - what happens when you debloat Chrome-Stub from Product and leave Chrome on Data, does it still run?
Btw, I do use Chrome (because of the integrated translator, making me easy to sometimes read worldwide forums if needed) and I didn't want to debloat originally. However, my preinstalled version on Product was not the latest, and Google Play was offering me to update, but updating Chrome was always failing.
I downloaded the apk from ApkMirror but installation had also failed
Then I debloated (at that time, prior to this debloater I used to manually create my system folder given to Magisk to overlay, and with dummy apk instead of with .replace file) and only then I was able to install Chrome apk (ofc to Data) and since then, to regularly update it through Playstore
Click to expand...
Click to collapse
Still have to test some more.
So far only on my Pixel aOS 11.
This is a little tricky to explain my testing/findings.
- Long post, truncated it for now. -
Not logged into Google. (PlayStore)
With Chrome stub active, Chrome is treated as a system app.
Even though the full version is in data it can not be uninstalled only disabled.
PlayStore shows an available update for Chrome.
If stub is removed (debloated), Chrome is treated as a user app.
You have the option to uninstall.
PlayStore does NOT show an update for Chrome.
Did not matter if I cleared cache and/or data on PlayStore or re-scan with with PlayProtect.
This is odd, since Google should still want to update even if it is just a user app.
I'll have to dig though the user agreement again.
Might be automatic update only when Google apps are included (system app) when not logged in.
--
As soon as I logged in, Google immediately updated some back-end.
Chrome is now available for an update and it updated fine.
This is also where some oddities came in.
--
<TRUNCATE>
--
Still have to double check everything.
Seems to be an issue distinguishing between system and user apps.
Should have time this weekend to redo and verify every step I used for testing.
As of now, I would suggest the same as you did it.
Debloat Chrome (stub)
Uninstall Chrome (should be considered a user app after the debloate.)
Install from another source (if need be then update from PlayStore.) or just install from PlayStore.
Cheers.
Btw, released v1.3.5 through the OP post #1 - just to log to the logfile the Android version, is it SAR and is it A/B - would be nice if you can test does it log correctly when you have time and A/B device.
Unfortunately, still unable to resolve a miss-communication with the bot to successfully submit to Repo
Can somebody dhare his debloat app list? Or the best, .sh file? İt would be great