Database Info

HTC Android Stay Safe Project

Table of Contents:
Status
Purpose
Audience
Instructions
Download
ROM list to use with the app
STATUS:
UPDATE:
I'm abandoning this project for the time being. I would like to have this integrated into the installer as a separate option and not rely on an app to handle this. If anyone wants to pick it up or extend things further, I'm definitely open to it. I just don't see a need for this at this time.
However, the source is still on GC and should help aspiring app makers get an idea for a basic UI and some interesting features.
Beta is out. It's working and ready to install on Cupcake and Donut.
If you are using it to create Hero, make sure you're running it. If you want Donut.. make sure you're running that, etc. It uses the currently running ROM for apps so it must match the new one or you might have issues with it. Requires root access. No way around that.
---------------------------------------------------------------------------------------
Purpose:
Due to issues regarding distribution of closed sources for ports of Android, this will handle backing up your licensed proprietary sources, an update you want to try and will put the sources into a final image and eventually partition if desired. You then rename NEW_system.ext2 to system.ext2 on your SD card's root folder and reboot.
---------------------------------------------------------------------------------------
Instructions
There will be a single app released soon!
1.) Install the APK
2.) Create a folder "update" on the SD card
3.) Place the update.sh file in /sdcard/update/
4.) Place a system.sqsh in the same folder.
5.) Run the app on the phone, click "Begin!" and let it do its thing.
6.) Take the "NEW_system.ext2" file on the SD card, rename it to "system.ext2" and remove or rename any existing system files.
7.) Reboot and enjoy
---------------------------------------------------------------------------------------
Download it here:
Google Code Page
Installable APK v1.0 BETA
Currently requires update.sh
---------------------------------------------------------------------------------------
This is an open project to be developed with others to bring a simple, shared interface that is compatible for any device running Android but of course with our phones in mind.
---------------------------------------------------------------------------------------

I wish I knew anything about development then I'd help, this is a good idea though. I'll try and support it in some way.

TheKartus said:
I wish I knew anything about development then I'd help, this is a good idea though. I'll try and support it in some way.
Click to expand...
Click to collapse
if you can't develop, I'd love feedback, bugs, ideas. I will eventually spin this into an open Market and later a Maps app. There's been talk about replacing these apps but nothing actually done. I was up all night with the Internet in one hand and Eclipse in the other and got this far for never having made anything like this.

This is a fantastic. I will support it fully. I am currently using a 1.5 build but I don't call which one it is because I've gone through so many versions and different roots, images and edits to my default.txt. It's a MUTT, I guess.
I am a Kaiser/Tilt user and was going to leave ATT until I decided to look into Android builds you and others offer.
Thanks a ton.

im getting fc/waits with the beta... by the way how long should the process take to backup. thanks nate

Running Cupcake or Donut? Is that once it starts running? It does not like to have a command run this long so it might just be that. Hasn't happened once for me running my Dark Donut though.
The backup is about 5 minutes or so mostly for dd'ing an ext2 image and then copying the apps. Once I hard code the script in I can make it show the progress. Also, each step will be a separate command so it shouldn't FC/wait on you. You can watch the progress by running:
Code:
tail -f /sdcard/update/update.log
which is what the app will do when I can get the update.sh verified by others that it's working correctly
And it is working for you right?

enatefox said:
Running Cupcake or Donut? Is that once it starts running? It does not like to have a command run this long so it might just be that. Hasn't happened once for me running my Dark Donut though.
The backup is about 5 minutes or so mostly for dd'ing an ext2 image and then copying the apps. Once I hard code the script in I can make it show the progress. Also, each step will be a separate command so it shouldn't FC/wait on you. You can watch the progress by running:
Code:
tail -f /sdcard/update/update.log
which is what the app will do when I can get the update.sh verified by others that it's working correctly
And it is working for you right?
Click to expand...
Click to collapse
it worked, i kept hitting wait and it didnt tell me when it was finished(the ui just froze idk). it gets the job done thanks man!
update.log
Code:
Backing up apps...
Mounting sqsh image...
Creating new system image
Transfering update sqsh to ext2...
edit i was running jeterblur but i was using the ion09/09/09.sqsh

It should say it finished. The log looks like it didn't finish. I'll try testing the script in the app itself and that should alleviate the strain on the system. It taps like 30-40% of CPU while it's running so if you have a bunch of processes it could be interfering. At least you're saying it's working too

I must be doing something wrong.
1. I put the dark donut clean build in my /storage card/updae folder along with the update.sh;
2. Ran android with an old Ion build (brand new data.img file)
3. Installed and ran stay safe
I had to press wait 5 times, and after 5 minutes it finished.​4. Before I reset the phone I moved the NEWsystem file into a new folder off the sdcard root
5. Then restarted the phone
6. In W.M. moved the ion data and system files to another folder
7. Renamed the NEWsystem (200mb) file to system
8. Put on root and ran harnet.
It booted, created a data file and is running great.​
The issue is, no added apps. It is exactly the same as the clean version.
Any ideas?

If you're making a Donut image, you should be running Donut on the phone to keep the versions correct. I'm going to make an update probably tomorrow that will have better error handling. It does do a cleanup at the end. If you edit update.sh (which is all the app runs) to remove these lines it will keep the apps it backs up:
rm -r "$app_base"
rm -r "$app_mountbase"
rm -r "$app_updatefolder/cmd"
rm -r "$app_ext2mount"
rm -r "$app_sqshmount"
Click to expand...
Click to collapse
It finds the apps through a grep pattern. On the full ROM, run this in ADB/terminal and see if it matches the apps:
ls /system/app/ | egrep -i 'vending|office|maps|street|gmail|market|youtube|setupwizard
Click to expand...
Click to collapse

enatefox said:
If you're making a Donut image, you should be running Donut on the phone to keep the versions correct. I'm going to make an update probably tomorrow that will have better error handling. It does do a cleanup at the end. If you edit update.sh (which is all the app runs) to remove these lines it will keep the apps it backs up:
It finds the apps through a grep pattern. On the full ROM, run this in ADB/terminal and see if it matches the apps:
Click to expand...
Click to collapse
I just tried it with the tmo donut build and your clean dark donut build; same result. So I removed the lines from the update.sh file and now the phone freezes. I let it sit for 30 mins, the rebooted the phone. It did grab the obdx? and apk files, but when I tried to manually install them, (after allowing non market apps) I get a "Program Name couold not be installed on this phone"
slight edit; I re-edited the file, now i does not freeze, but it still does not load the apps and the pulled apps will not install

I'm abandoning this project at this point. I'd like to have this integrated into the rootfs.img as an option at install time. If someone wants to pick it up or wants to take this further, I'm open to that. The source should help people out who would like to make an app though.

[SCRIPT - ROOT] Moto X Root Script (Locked Bootloader)

Script removed/Effort "canceled" (see release notes)!​
Dear fellow XDA'ers, i have written a quick and simple script to tie in all of the great work done by jcase and beaups that helps you root your Moto X. This script simply follows the instructions written by jcase and beaups and automates those scripts with a simple menu.
This script should technically work for "any" Moto X on "any" carrier, provided the methods contained within have the same success rate across all carriers. I do not have the capacity, nor experience, to trap for all situations.
This script ASSUMES that you already have the Motorola drivers installed and your device has successfully connected to your computer via USB Debugging Mode. If you need the drivers, they can be found here.
Instructions:
Download and extract this script on to your Windows Desktop.
Download ALL of the following to the same folder as the GO!.CMD ("640k's Moto X Root Script" Folder). These files should NOT be unzipped:
your specific 4.2.2 factory image.and/or 4.4 factory images (if you are on 4.4, you will need BOTH images).
jcase's RockMyMoto (4.2.2) and SlapMyMoto (4.4).
beaups' MotoWpNoMo.
Saurik's Cydia Impactor
Execute Go!.CMD and follow the on-screen prompts.
Links:
Moto X Firmware Page
jcase's RockMyMoto Thread
jcase's SlapMyMoto Thread
beaups' MotoWpNoMo Thread
Saurik's Cydia Impactor Page
Disclaimers:
I make no warranties of any kind regarding the accuracy or efficiency of this script or the processes contained within. This script was tested on a single device and was written based off of the instructions provided within these forums. You can perform these steps yourself!
jcase will NOT support the use of this script. Should you run in to issues with any of the functionality/procedures written specifically by jcase, you will not be supported by jcase unless you are following his methods.
beaups will NOT support the use of this script. Should you run in to issues with any of the functionality/procedures written specifically by beaups, you will not be supported by beaups unless you are following his methods.
Because I have compiled other's hard work into a command-line script, i have decided to distribute my script uncompiled. That way, in the event of major changes, significant errors, etc., that I don't have time to address, the user community can lend a hand. If you find my work useful, please Thank Me.
WARNING
Make sure your device is fully charged before beginning!
Some people have reported an inability to flash their device, have received "unknown errors", weird partition errors and general chaos during the flashing/imaging process. If this happens to you, try a different USB port. I have read threads/seen reports where sometimes USB 3.0 ports cause failures during this process. Change to a USB 2.0 port and try again.
[*]In general, it is difficult to completely brick your device using this method. As long as you can get to the fastboot menu, your device is recoverable. If your phone will not power on, you did not follow one of the two warnings above.
TIPS:
If "Waiting for device" seems to be taking a really long time (your device is ready, but the script hasn't picked it up yet), try either turning off USB Debugging and then back on, or try removing the USB cable and re-inserting it.
If you are on 4.4, looking for root, your device will be re-imaged two times with 4.2.2. Don't input your details until the 2nd time, to avoid having to repeat your effort.
Connect to your WiFi before enabling USB Debugging Mode to avoid IP Address errors. The batch script tends to get funny on some of the retries. I've tried working out most of the bugs.
I'm confident I haven't worked out 100% of the bugs in this script, although I've tried very hard. I've only tested it with one device, the XT1060. If you have issues, please do not PM me, post them here in the thread.
If for some reason the script abnormally ends or you close out of it, without running the cleanup process at the end, ADB will remain present and cause an error in the script, which will cause the script to fail. Browse to the folder with the CMD prompt and type "ADB kill-server" (kill-server is case-sensitive). This will get the script running again.
Thanks jcase, beaups, saurik and anyone else who has contributed to this effort!
Changelog:
1/9/2014: Initial Release. Only tested on one device. Better bug management within each step, more options at advanced menu, including ADB Debug Window. Removed auto-upgrade to 4.4. I suspect this is where my woes were.
1/9/2014: Removed ADMINISTRATOR requirement. I don't think this will do any harm, but it was creating conflicts with Windows 8.
1/9/2014: Changed TELNET conditions to trap for user interaction.
1/14/2014: Adjusted initial TELNET session.
1/14/2014: Corrected a type on line 366 (would have given an error).
1/15/2014: Re-worked TELNET routine again.
1/16/2014: Simplified menu options, included automated checking for write protection. This check will skip steps once WP has already been turned off.
1/16/2014: Included additional instruction, including more messaging and better message waiting.
1/16/2014: Added additional messaging for troubleshooting purposes.
1/16/2014: Corrected a bug related to BATCH language that was ending the TELNET steps.
1/17/2014: Made another adjustment to TELNET handling.
1/17/2014: Added additional error checking.
1/17/2014: Added some wait time on the second TELNET phase.
2/28/2014: Canceled script effort (ran out of time). With 4.4.2 released, none of the current root methods are valid or work.
BEFORE YOU START WITH ANY METHOD THAT REQUIRES YOU TO WIPE YOUR DEVICE, MAKE SURE YOUR DEVICE IS 100% FULLY CHARGED!! IF YOUR DEVICE SHUTS DOWN WHILE THE SYSTEM IS FLASHING YOU WILL BRICK YOUR DEVICE!!!​

heck yes!!!!!!!!!!!!!!!!!!!

Hold the phone. The script at the very last step isn't working. Can't fix right now. My personal device doesn't have root, so it failed. Will need to troubleshoot.

Appreciate the effort put into this for the community
Sent from my XT1060 using xda app-developers app

ok so the script seems to be doing what it's designed to do, which is good. but i've borked my device testing it, which is bad. but i was able to trap for more conditions and provide a better menu system, which is good.
as soon as i can figure out if i can un-bork my device, i'll post the script back up.

My device has root. Script is back online.

I really appreciate your hard work. I've had trouble getting this to work by myself. I'd love to give this a shot later today. I had a few questions though.
You said to "install the script" after it is downloaded but what exactly needs to be installed? Also you said to put all the files in the install folder, but I'm not seeing an install folder in the extracted .rar.
I want to make sure the script runs smoothly so it would be best if I could see exactly how your files are set up. Would you perhaps be able to upload a screenshot?
Thanks!

flipfreak said:
I really appreciate your hard work. I've had trouble getting this to work by myself. I'd love to give this a shot later today. I had a few questions though.
You said to "install the script" after it is downloaded but what exactly needs to be installed? Also you said to put all the files in the install folder, but I'm not seeing an install folder in the extracted .rar.
I want to make sure the script runs smoothly so it would be best if I could see exactly how your files are set up. Would you perhaps be able to upload a screenshot?
Thanks!
Click to expand...
Click to collapse
so my original intention was to distribute this as a self-extracting EXE but because i wanted to share my work and XDA's attachment policy, i changed it to a rar.
just unzip it (anywhere). you'll get a "640k's Moto X Root Script" folder. make sure your .zips from the links above are in the same folder as the Go!.CMD and you'll be good to go.

640k said:
so my original intention was to distribute this as a self-extracting EXE but because i wanted to share my work and XDA's attachment policy, i changed it to a rar.
just unzip it (anywhere). you're get a "640k's Moto X Root Script" folder. make sure your .zips from the links above are in the same folder as the Go!.CMD and you'll be good to go.
Click to expand...
Click to collapse
Thank you! That clears things up. I'll give this a try later and let you know how it went

flipfreak said:
Thank you! That clears things up. I'll give this a try later and let you know how it went
Click to expand...
Click to collapse
based on my testing, unless something goes completely wrong, it should be pretty hard to completely bork your phone. if you get into a bootloop, the advanced menu can help you restore your system files as long as you can get in to the bootloader (usually you can).

640k said:
based on my testing, unless something goes completely wrong, it should be pretty hard to completely bork your phone. if you get into a bootloop, the advanced menu can help you restore your system files as long as you can get in to the bootloader (usually you can).
Click to expand...
Click to collapse
Hmm, well I tried it but it keeps telling me that 7za.exe is not in the folder, even though it is sitting right above Go!.CMD. Any idea why it would say this? I ran it as an administrator

flipfreak said:
Hmm, well I tried it but it keeps telling me that 7za.exe is not in the folder, even though it is sitting right above Go!.CMD. Any idea why it would say this? I ran it as an administrator
Click to expand...
Click to collapse
can you screen shot the window and your folder where the files are?
thanks.

640k said:
can you screen shot the window and your folder where the files are?
thanks.
Click to expand...
Click to collapse
Sure

flipfreak said:
Sure
Click to expand...
Click to collapse
did you extract the contents to your desktop? i'm guessing it's failing because you're technically not running the cmd file in the same folder. for example, windows will allow you to run files directly from a .zip, but it caches that file in to a temp folder somewhere. if you haven't unzipped the files, the script won't see any of the files.
i'm here to help, i want this to be successful.

640k said:
did you extract the contents to your desktop? i'm guessing it's failing because you're technically not running the cmd file in the same folder. for example, windows will allow you to run files directly from a .zip, but it caches that file in to a temp folder somewhere. if you haven't unzipped the files, the script won't see any of the files.
i'm here to help, i want this to be successful.
Click to expand...
Click to collapse
Yeah, the files are all extracted to my desktop. If I run it as an administrator, it gives me the error telling me that that 7za.exe is not in the folder. If I don't run it as an administrator, it tells me that it will abort and to press any key to continue. When I press any key, it brings me to the menu where it asks me what I want to do.
I'm not sure what I could be doing wrong. Maybe we should just wait and see if anyone else has this problem. It could be on my end.

flipfreak said:
Yeah, the files are all extracted to my desktop. If I run it as an administrator, it gives me the error telling me that that 7za.exe is not in the folder. If I don't run it as an administrator, it tells me that it will abort and to press any key to continue. When I press any key, it brings me to the menu where it asks me what I want to do.
I'm not sure what I could be doing wrong. Maybe we should just wait and see if anyone else has this problem. It could be on my end.
Click to expand...
Click to collapse
ok i'm seeing the same issue. it's isolated to Windows 8. troubleshooting now.
Windows 8 is running the CMD prompt from /WINDOWS/SYSTEM32... which is the exact problem i detailed earlier. i'm going to remove the admin requirement. i don't think it's necessary.

flipfreak said:
Yeah, the files are all extracted to my desktop. If I run it as an administrator, it gives me the error telling me that that 7za.exe is not in the folder. If I don't run it as an administrator, it tells me that it will abort and to press any key to continue. When I press any key, it brings me to the menu where it asks me what I want to do.
I'm not sure what I could be doing wrong. Maybe we should just wait and see if anyone else has this problem. It could be on my end.
Click to expand...
Click to collapse
download the new file and try it again.

640k said:
download the new file and try it again.
Click to expand...
Click to collapse
That got it working. I'm now stuck at attempting a telnet session. Should I restart? Here's a screenshot

flipfreak said:
That got it working. I'm now stuck at attempting a telnet session. Should I restart? Here's a screenshot
Click to expand...
Click to collapse
i was afraid of that. open the TELNET.ERR file with notepad and show me the contents. jcase stuck some user interaction in there that only occurs one time, so i was never able to trap it again.
thanks for your help.

640k said:
i was afraid of that. open the TELNET.ERR file with notepad and show me the contents. jcase stuck some user interaction in there that only occurs one time, so i was never able to trap it again.
thanks for your help.
Click to expand...
Click to collapse
No problem.
ÿý
ÿýÿû
ÿû
~ $ dalvikvm -cp /sdcard/RockMyMoto.jar RockMyMoto
RockMyMoto 1.0
by Justin Case
PayPal Donations maybe sent to: [email protected]
Special thanks to saurik, you rock!
System is write protected...
Executing step 1...
To use RockMyMoto you most solve a
simple equation. This helps ensure
you are paying attention, and also
amuses JesusFreke and myself.
Solve for a:
a/24=70
Please type a whole number as your answer:
Click to expand...
Click to collapse

Temporary root shell for developers on locked bootloaders.

Hello All! I am me2151.
I am here to tell you some kind of good news.
We have achieved a temporary root shell using a modified recowvery script. Originally Recowvery installed a custom "recovery" but I have modified it to instead create a temporary root shell using the System_Server SELinux context and disable the flashing portion of the script. Yes we are still limited until we can get Kernel or Init context but I am working on that as well.
This exploit will be useful down the line because of one major thing. WE CAN INSERT KERNEL MODULES!!! But they need to be signed. So I am releasing this out here so we can take the next step into our full root! We also have rw to the /data partition and changes save over a reboot.
If we can get someone to sign a kernel module that the system accepts we can set SELinux to permissive.
This exploit SHOULD work for all variants.
NOTE: This should only be used by devs who know what they are doing.
Instructions(this should work on MacOS and Linux only!):
Download linked file below.
Extract to either adb directory OR a directory you have adb access in.
Give execute permissions to temp.sh.
Run temp.sh.
When you are all done with your exploring and stuff type "Reboot" to reboot normally.
https://drive.google.com/open?id=0B8CP3g3AqMuHcmNJUUJWLUJUelE
Credit:
 @jcadduono - For recowvery, and pointing me in the right direction on IRC.
 @brenns10 - Wrote the lsh used in the exploit to spawn the shell.
The group over here for ideas and solutions.

Very cool work! Glad to see people putting my shell (such as it is) to good use. Wish I had a V20 to try it out

I don't think you'll ever be able to sign a kernel module (SHA512 hash). You'd probably have better luck signing your own boot image.
Here's a theory to toy with:
I think the way to do it would be to gain read access to /init binary allowing you to dirtycow /init with the same init binary but change a very specific (but not vital to system integrity) set of instructions to point back to the setenforce code with a value of 0 without disturbing the rest of the binary/instructions. This way, init should continue running without crashing and taking down the whole system, and you can do something that might trigger that specific instruction set - which would then result in selinux becoming permissive.
This is beyond me, unfortunately. This method would also be very device specific until someone also finds an intelligent way to read init, modify instructions, then dirtycow it back.
I think system server context might be able to read init?
Once you get your permissive selinux, you'll also have to deal with Unix capabilities limitations (find a way around them).

jcadduono said:
I don't think you'll ever be able to sign a kernel module (SHA512 hash). You'd probably have better luck signing your own boot image.
Here's a theory to toy with:
I think the way to do it would be to gain read access to /init binary allowing you to dirtycow /init with the same init binary but change a very specific (but not vital to system integrity) set of instructions to point back to the setenforce code with a value of 0 without disturbing the rest of the binary/instructions. This way, init should continue running without crashing and taking down the whole system, and you can do something that might trigger that specific instruction set - which would then result in selinux becoming permissive.
This is beyond me, unfortunately. This method would also be very device specific until someone also finds an intelligent way to read init, modify instructions, then dirtycow it back.
I think system server context might be able to read init?
Once you get your permissive selinux, you'll also have to deal with Unix capabilities limitations (find a way around them).
Click to expand...
Click to collapse
if system_server can read init then thats a serious flaw.... Question for you. you said it would be very device specific. does that mean its unique for each individual phone or each model?
EDIT:Unfortunately we only have access to the init.rc not the binary it self.

@jcadduono I appreciate your input and direction in this matter another idea we have been toying with is
We have the aboot boot recovery and system dump. From the tmob variant would it be possible to make a tot from that for our devices changing the props to match our device, build, and carrier info? We can also pull apks from /system/apps and /privapps to our ext sdcard

@me2151, @jcadduono, @brenns10: Great work guys, keep it up. Good to see some people are trying for root. What model/s are being tested, or should this theoretically work on all models? Whilst you probably aren't doing it for the cash, there is a bounty I hope someone can claim soon, for a functonal root alone (not boot unlock) posted on this board.
RoOSTA

roosta said:
@me2151, @jcadduono, @brenns10: Great work guys, keep it up. Good to see some people are trying for root. What model/s are being tested, or should this theoretically work on all models? Whilst you probably aren't doing it for the cash, there is a bounty I hope someone can claim soon, for a functonal root alone (not boot unlock) posted on this board.
RoOSTA
Click to expand...
Click to collapse
It should work on all models. I personally use a sprint model(LS997). I think it MAY have been tested on VZW as well.

I can confirm that work on H990DS
Sent from my MI PAD using XDA-Developers mobile app

We know from earlier LG phone releases that the laf partition when bypassed in some way (corrupted, etc) aboot will boot to fastboot when going into download mode. It was my thought that the bootloader could be unlocked from there. However corrupting laf eliminates device recovery. Catch-22.
I think the best way to proceed is to get a working .TOT first which is just a waiting game. That would ensure device recovery and replacing the bootloader in the .TOT and signing it with something unlockable.
This is a great way to explore the locked phones in the meantime, thanks.

ATT Pretty Please

me2151 said:
Hello All! I am me2151.
I am here to tell you some kind of good news.
We have achieved a temporary root shell using a modified recowvery script. Originally Recowvery installed a custom "recovery" but I have modified it to instead create a temporary root shell using the System_Server SELinux context and disable the flashing portion of the script. Yes we are still limited until we can get Kernel or Init context but I am working on that as well.
This exploit will be useful down the line because of one major thing. WE CAN INSERT KERNEL MODULES!!! But they need to be signed. So I am releasing this out here so we can take the next step into our full root! We also have rw to the /data partition and changes save over a reboot.
If we can get someone to sign a kernel module that the system accepts we can set SELinux to permissive.
This exploit SHOULD work for all variants.
NOTE: This should only be used by devs who know what they are doing.
Instructions(this should work on MacOS and Linux only!):
Download linked file below.
Extract to either adb directory OR a directory you have adb access in.
Give execute permissions to temp.sh.
Run temp.sh.
When you are all done with your exploring and stuff type "Reboot" to reboot normally.
https://drive.google.com/open?id=0B8CP3g3AqMuHcmNJUUJWLUJUelE
Credit:
@jcadduono - For recowvery, and pointing me in the right direction on IRC.
@brenns10 - Wrote the lsh used in the exploit to spawn the shell.
The group over here for ideas and solutions.
Click to expand...
Click to collapse
At the moment all I am using root for is to add a line within my build.prop to disable Tethering checks, so I can tether at full 4G speed and not get throttled. Would this be possible using the method above, or would build.prop immediately get replaced at the reboot?
Thanks, and keep up the good work!

NRadonich said:
At the moment all I am using root for is to add a line within my build.prop to disable Tethering checks, so I can tether at full 4G speed and not get throttled. Would this be possible using the method above, or would build.prop immediately get replaced at the reboot?
Thanks, and keep up the good work!
Click to expand...
Click to collapse
no. it is a tcp root shell that can only do a few things such as kernel modules.. only section we were able to write to and have it stick was the /data partition which wont help you in this scenario

elliwigy said:
no. it is a tcp root shell that can only do a few things such as kernel modules.. only section we were able to write to and have it stick was the /data partition which wont help you in this scenario
Click to expand...
Click to collapse
So if we can write to data partition then in theory can we adb push to it using this? I ask because I'd like to install some tbo apps that normally would require flashing. But if we could push them we would be solid

markbencze said:
So if we can write to data partition then in theory can we adb push to it using this? I ask because I'd like to install some tbo apps that normally would require flashing. But if we could push them we would be solid
Click to expand...
Click to collapse
Unfortunately its a tcp shell. not a pure adb shell. so we cannot push or pull to those directories

Wow great progress keep up the good work. You guys are helping those assholes from LG sell more phones. Obviously some people have not made the switch because the lack of root. Root users are very influential leaders to get others to try out a new device.
Sent from my LG-LS997 using XDA-Developers mobile app

Works on the LG G5 also...

Hey guys, with the expectation of many that 'root is coming' to the other v20 models...are we likely to see the same type of root format that applied to the LG G4, where you have to (either) download or rip your own image to a PC. Use commands to insert root, then reflash to the device?
Any root is better than nothing, I know...but I ask because with the amount of software updates for the G4 (v10c software through to v10k before MM came out), meant the sheer amount of times you'd have to go through this process to keep your phone up to date whilst maintaining root was extremely frustrating - as it also meant xposed and related settings/apps needed to be reinstalled each time you performed an OTA update and re-flashed root.
Is this going to be a side effect of dealing with a locked bootloader? PS: If I sound dumb, it's probably because I am.
RoOSTA

roosta said:
Hey guys, with the expectation of many that 'root is coming' to the other v20 models...are we likely to see the same type of root format that applied to the LG G4, where you have to (either) download or rip your own image to a PC. Use commands to insert root, then reflash to the device?
Any root is better than nothing, I know...but I ask because with the amount of software updates for the G4 (v10c software through to v10k before MM came out), meant the sheer amount of times you'd have to go through this process to keep your phone up to date whilst maintaining root was extremely frustrating - as it also meant xposed and related settings/apps needed to be reinstalled each time you performed an OTA update and re-flashed root.
Is this going to be a side effect of dealing with a locked bootloader? PS: If I sound dumb, it's probably because I am.
RoOSTA
Click to expand...
Click to collapse
it shouldnt be an expectation as weve made it clear we do not have root and are hitting hurdles.. we have been advised we need to atack selinux and or the bl but at this point were wanting to try to use debug firmware which hoprfully would allow a bl unlock..
unfortunately nobody can creat a .tot with the debug firmware at al and theres no way at all to flash the images..
we need to somehow leverage an exploit to gain a temp adb root shell before we could even attempt anything and this has not been done in a way thats useful to us..
unfortunately we need more experienced devs at this point.

LG Australia (and as such, Taiwan) have effectively confirmed their H990DS v20 mobile phone's bootloader is confirmed as being unlockable. However (and for no apparent reason) they will not confirm why one region have released a variant of the phone with the bootloader unlock and why they are refusing this to others phones/regions. Because of course, they have zero training and information about anything related to their company expect for goods released in a specific region. That comes from a 'product expert'

Titanium Backup
Howdy,
Just reading through the thread, I understand that it's not quite a "full" root, but would it be enough to run Titanium Backup? I'm hoping to move away from root access with my V20 but it would be really helpful if I could do it temporarily, restore some application and data backups, reboot and uninstall Titanium.
Tim

[SOLVED] Android Trojan.Gorilla.AM or Guerrilla.AM on my device OEM launcher...

(NOTE: this post is a duplicate of a similar thread I started on the Android Central user forum)
Hello everyone,
In the continuing saga of the Leagoo T5C i bought before the holidays from GearBest, I've seen the good (the price and overall build quality, along with a reasonably good user experience), the bad (some notifications that I just can't get rid of, among other things), and I now present you the ugly: after watching a review video on YouTube about my device, I learned that it came loaded with a Trojan called "Gorilla.AM"...
***EDIT: apparently, the Trojan's name could actually be "Guerrilla.AM", I'm not sure.***
Needless to say, I did as the tester had, and installed Malwarebytes, which, sure enough, found the exact same Trojan on my device.
You can watch the video here: https://www.youtube.com/watch?v=R5l3z7BvBtk
It so happens that it's embedded in Leagoo's own application launcher, called Sujet (in French; maybe it's called "Subject" in English, I don't know). I can force quit the application, since I use another launcher called Apex (good pick, by the way), but Malwarebytes can't seem to shake the Trojan off my device nonetheless.
A quick search on Google gives very little in the way of information about this malware, but I'd like to be on the safe side, so I came here.
Any contribution would be welcome at this stage.

Hi. I've seen your post on a french-speaking forum but for my own reasons I don't want to help there, too many morons.
Leagoo is well-known for smartphones with built-in spyware/adware. I've had both a Z5 and a M5 and both had such crap in the stock firmware.
This one is new to me but you'll probably have to follow the same steps to get rid of it.
Try
Code:
adb shell pm disable <internal name of that launcher>
first (from a PC connected to the device with ADB - zillions of tutorials available for this)
The internal name can be found by guessing or by using one of the many apps that will show you the information. One is https://play.google.com/store/apps/details?id=com.csdroid.pkg
If that fails, try adding "-k -user 0" to the command line.
If it fails again (denied) then you have no choice but to root your device first, then use this pm command from a root shell or directly delete the folder for "Sujet/Subject" from /system/app or /system/priv-app where you'll find it.

Lannig said:
Hi. I've seen your post on a french-speaking forum but for my own reasons I don't want to help there, too many morons.
Leagoo is well-known for smartphones with built-in spyware/adware. I've had both a Z5 and a M5 and both had such crap in the stock firmware.
This one is new to me but you'll probably have to follow the same steps to get rid of it.
Try
Code:
adb shell pm disable <internal name of that launcher>
first (from a PC connected to the device with ADB - zillions of tutorials available for this)
The internal name can be found by guessing or by using one of the many apps that will show you the information. One is https://play.google.com/store/apps/details?id=com.csdroid.pkg
If that fails, try adding "-k -user 0" to the command line.
If it fails again (denied) then you have no choice but to root your device first, then use this pm command from a root shell or directly delete the folder for "Sujet/Subject" from /system/app or /system/priv-app where you'll find it.
Click to expand...
Click to collapse
Hi,
OK, first off, thanks for the reply. Secondly, as I've stated before, I'm new to Android, and though I know my way around the command line in both Windows, Linux et OS X (not so much macOS: my MacBook Pro is 12-years old...), I suppose there are some things to set up first, before you can actually do what you suggest.
I understand that ADB stands for Android Debug Bridge, so is it an existing functionality in, say, Windows, that you can trigger from the command line, or a third-party software you have to install first?
On the Android side, what action should I take? Any Developer command to enable/disable to let ADB interact with my device the way it's supposed to?

Yes, you need to enable debug mode on your phone too. I could refer you to one of the zillion tutorials available on the net, but here's a summary.
Go to settings > about... (à propos)
Make at least 7 rapid touches on the line that says "build number" or its french translation.
This will make a new settings menu available from the main settings page: developer options
In this new menu, enable USB debugging.
Then you need to install ADB on your Mac and I'm at loss to help you there because I'm totally foreign to Macs. Never used one.
This seems like a good start: https://www.xda-developers.com/install-adb-windows-macos-linux/
Note: you may also try issuing the commands mentioned above from a terminal emulator running directly on your Android device, although I'm told that it's not exactly the same thing protection-wise.
Install this: https://play.google.com/store/apps/details?id=jackpal.androidterm and try typing the commands from the emulator window. If it works, no need for ADB (although having ADB will probably prove useful sooner or later and I encourage you to take the step).
EDIT: forget the guys from Phonandroid, they're brain-damaged beyond help

Lannig said:
Yes, you need to enable debug mode on your phone too. I could refer you to one of the zillion tutorials available on the net, but here's a summary.
Go to settings > about... (à propos)
Make at least 7 rapid touches on the line that says "build number" or its french translation.
This will make a new settings menu available from the main settings page: developer options
In this new menu, enable USB debugging.
Then you need to install ADB on your Mac and I'm at loss to help you there because I'm totally foreign to Macs. Never used one.
This seems like a good start: https://www.xda-developers.com/install-adb-windows-macos-linux/
Note: you may also try issuing the commands mentioned above from a terminal emulator running directly on your Android device, although I'm told that it's not exactly the same thing protection-wise.
Install this: https://play.google.com/store/apps/details?id=jackpal.androidterm and try typing the commands from the emulator window. If it works, no need for ADB (although having ADB will probably prove useful sooner or later and I encourage you to take the step).
EDIT: forget the guys from Phonandroid, they're brain-damaged beyond help
Click to expand...
Click to collapse
OK, thanks for the heads-up; I've already installed a Terminal emulator on the phone, so I'm gonna give it a go in a moment. I concur about Phoneandroid, alas: I've just received flak from one of the moderators because I'd double-posted on the same subject, whereas I'd just posted one thread, in the wrong part of the forum, according to him. Go figure...

OK, please feed back on your attempts, both from terminal emulator and through ADB.
Alas, I suspect that root will be required. It was for me on my Z5 and M5 to get rid of Leagoo's crapware.
Phonandroid is a bunch of losers with bloated egos posing as experts when 2/3 of the replies given are total BS.

"Er, Houston, we've had a problem..."
On Windows: "ADB is not a recognized name for a command applet..."
On OS X: "adb: command not found"
Stumped, I am...

"Er, Houston, we've had a problem..."
On Windows: "ADB is not a recognized name for a command applet..."
On OS X: "adb: command not found"
Stumped, I am...

(Additional question, not quite related: Aida64 indicates that my device runs a 4.4.49 version of the Android kernel, when the current version for Android 7.x is supposed to be 4.4.1; how does that compute--no pun intended--with my issue?)

Missing adb command is because the adb.exe (Windows) or adb (Mac) file is not in the command path. Either make the folder that contains the adb[.exe] file the current folder using the cd command or use whatever context menu for opening a command line window within the currently selected folder works, or even add that folder to the PATH variable. Google "add directory to path" for Windows and MacOS.
No idea about the kernel version. Minor kernel versions may vary within an Android release. Not surprising and most definitely unrelated to your problem. The crapware certainly isn't part of the kernel. It's most likely a system app i.e. a folder within either /system/app or /system/priv-app folders. You can't delete it without root, but you might be able to disable (freeze) it with the commands I gave you.

OK, thanks. I did "cd" to the folder where I had unzipped ADB on Windows (on the Mac, when I tried to open the ADB executable, I got a "cpu not supported" error message in the Terminal, as I feared, since my MBP is 32-bit-only, and most Mac applications nowadays only support 64-bit CPUs), and still got the "adb unrecognized command" error in PowerShell.
The phone was plugged in, and the right USB mode, so I'm still a bit baffled here. Gonna try it again with a different approach. Will keep you posted.
Over and out...

OK, here's what I got: "Error: java.lang.SecurityException: Shell cannot change component state for com.leagoo.launcher3/null to 2"
Basically, from my poor understanding of how Android works, it's root or die, right?

UglyStuff said:
OK, here's what I got: "Error: java.lang.SecurityException: Shell cannot change component state for com.leagoo.launcher3/null to 2"
Basically, from my poor understanding of how Android works, it's root or die, right?
Click to expand...
Click to collapse
I see that this phone has 7.x android. So, a Magisk Systemless flash might work. After rooting your device, get a good launcher integrate it to /system. Then delete your stock launcher all together.
Tell me if this works.
---------- Post added at 01:23 PM ---------- Previous post was at 01:20 PM ----------
rhn19 said:
I see that this phone has 7.x android. So, a Magisk Systemless flash might work. After rooting your device, get a good launcher integrate it to /system. Then delete your stock launcher all together.
Tell me if this works.
Click to expand...
Click to collapse
If you are new to this, use an app from play store for uninstalling and integrating apps.

Hi,
Yes, like I said, I'm a newbie when it comes to Android, so I'll abstain from rooting my device for now, but I'll keep your suggestions under advisement, because I suppose there'll be no other option in the long run. I'm gathering info on how to safely root a device.
I've done countless jailbreaks on iPhones, and it was always absolutely painless, but then, I had better understanding of how iOS works than I have Android, so until I know more about the OS, I'll keep my phone as it is.
Thanks again!

UglyStuff said:
Hi,
Yes, like I said, I'm a newbie when it comes to Android, so I'll abstain from rooting my device for now, but I'll keep your suggestions under advisement, because I suppose there'll be no other option in the long run. I'm gathering info on how to safely root a device.
I've done countless jailbreaks on iPhones, and it was always absolutely painless, but then, I had better understanding of how iOS works than I have Android, so until I know more about the OS, I'll keep my phone as it is.
Thanks again!
Click to expand...
Click to collapse
Jailbreaking vs Rooting is like 5-1 on difficulty level. Because Android is Open source while IOS is not. I would highly suggest you Root it if your phone does not have warranty. After all something that is on /system partition like your launcher will need superuser access to modify it. I cannot think of a way that wont void your warranty.
You can flash TWRP and then boot into aroma-fm but that will void your warranty. Rooting is the preferred option here.

Yeah, well, the phone is brand-new, and still under warranty, but that's not what's holding me back: I'd rather not brick it, most of all, because I need it, if not as my main phone, at least for connectivity.
I've read tutorials on this very website about using TWRP to flash a new baseband, but I'm curious about what firmware to choose, where to download it from to be sure it's not laden with bad stuff, and how sure I'll be to have an operable phone afterwards.

UglyStuff said:
Yeah, well, the phone is brand-new, and still under warranty, but that's not what's holding me back: I'd rather not brick it, most of all, because I need it, if not as my main phone, at least for connectivity.
I've read tutorials on this very website about using TWRP to flash a new baseband, but I'm curious about what firmware to choose, where to download it from to be sure it's not laden with bad stuff, and how sure I'll be to have an operable phone afterwards.
Click to expand...
Click to collapse
Why do you want a new firmware? I don't get you man, do you want to clear out the malware or try a new ROM? Because i think you would have to build a new ROM, there is not one available i guess.

That's the thing: the malware on my phone is part of the application launcher installed by the OEM. In other words, it's embedded inside the ROM. If I root my phone and somehow manage to get rid of this launcher, what's to tell me that Leagoo won't push it silently back onto my device under the disguise of an update?
I don't know what to do here. I understand that based on stock Android, each OEM applies a certain number of modifications to accommodate the hardware it used to build the phone, and since the SoC is brand-new, I gather there aren't many drivers available, unless I leave the current baseline in place.
I'm kinda caught between a rock and a hard place here...

UglyStuff said:
That's the thing: the malware on my phone is part of the application launcher installed by the OEM. In other words, it's embedded inside the ROM. If I root my phone and somehow manage to get rid of this launcher, what's to tell me that Leagoo won't push it silently back onto my device under the disguise of an update?
I don't know what to do here. I understand that based on stock Android, each OEM applies a certain number of modifications to accommodate the hardware it used to build the phone, and since the SoC is brand-new, I gather there aren't many drivers available, unless I leave the current baseline in place.
I'm kinda caught between a rock and a hard place here...
Click to expand...
Click to collapse
If you use malwarebytes after root that thing wont happen. And almost all of the OEMs have a trigger which voids when rooting or flashing firmware. After that the OEM wont give you updates unless you use the A/B partitioning system.

OK, I understand how rooting my phone would void the warranty: after all, it's a substantial change in the phone software, and the OEM can't be made responsible for any mishap that occurs after I've rooted the phone.
What's the A/B partitioning system (I suppose it helps partition your storage space)? I don't have a microSD card installed (I use the slot for my second SIM), but I do have 32 Gb of storage space, minus what's already used up.
Do you know KingRoot? Is it as good and (reasonably) safe a rooting tool as they say it is?

[GUIDE] Google Pay working SIMPLY with unlock/root on Pixel 4/XL [GUIDE]

Hey guys... I've seen various methods to get Google Pay working and simply put, none of them worked for me. All that I could find left was advanced stuff involving SQLite editors and that's just not for everyone. So I started trying other known working methods from different devices, and this is what I did to get it going without issue.
1. Open Magisk, Magisk Hide, and tick the check box next to Google Pay. Proceed normally through the following steps after doing so.
2. Force stop Google Pay, clear app data/storage.
3. Open a root file manager
4. Using root file manager, find /data/data/com.google.android.gms/databases directory
5. Select a file called db.dg and chmod the permissions to 440, save and make sure it in fact saves
6. Reboot and set up Google Pay.
This should get you set up in no time without a need for modules or advanced user techniques. Hope it helps!
Edit: People seem to really dislike this method for some reason, so just throwing out there it seems everyone else recommends the SQL editing. This method worked for me, but YMMV and everyone else hates it

wrongway213 said:
Hey guys... I've seen various methods to get Google Pay working and simply put, none of them worked for me. All that I could find left was advanced stuff involving SQLite editors and that's just not for everyone. So I started trying other known working methods from different devices, and this is what I did to get it going without issue.
Unlocked users start at Step 1 below. Rooted users - First open Magisk, Magisk Hide, and tick the check box next to Google Pay. Proceed normally through the following steps after doing so.
1. Force stop Google Pay, clear app data/storage.
2. Open a root file manager OR reboot to TWRP if you don't have one
3. Using root file manager OR TWRP file manager, find /data/data/com.google.android.gms/databases directory
4. Select a file called db.dg and chmod the permissions to 440, confirm if in TWRP, save and make sure it in fact saves if using a file manager.
5. Whether in TWRP or using a root file manager. reboot and set up Google Pay.
This should get you set up in no time without a need for modules or advanced user techniques. Hope it helps!
Click to expand...
Click to collapse
That will only work if the attestation values in the dg.db file haven't been changed to flag root/unlocked bootloader already.
If your values have already been changed, you will need to manually edit the dg.db file or use the Magisk modules from this post: https://forum.xda-developers.com/apps/magisk/magisk-google-pay-gms-17-1-22-pie-t3929950/post79643248

ilal2ielli said:
That will only work if the attestation values in the dg.db file haven't been changed to flag root/unlocked bootloader already.
If your values have already been changed, you will need to manually edit the dg.db file or use the Magisk modules from this post: https://forum.xda-developers.com/apps/magisk/magisk-google-pay-gms-17-1-22-pie-t3929950/post79643248
Click to expand...
Click to collapse
Yeah... I'm not sold on making those kinds of edits or loading modules that do so without a working TWRP for this device anywhere in sight. That's precisely why I posted this thread - a working solution that doesn't involve editing things at that level - even if it doesn't work for everyone, I think it'll be more comfortale for those apprehensive to make certain changes without recovery :good:

wrongway213 said:
Yeah... I'm not sold on making those kinds of edits or loading modules that do so without a working TWRP for this device anywhere in sight. That's precisely why I posted this thread - a working solution that doesn't involve editing things at that level - even if it doesn't work for everyone, I think it'll be more comfortale for those apprehensive to make certain changes without recovery :good:
Click to expand...
Click to collapse
Having TWRP or not changes nothing for anyone that makes a mistake with those edits or Magisk. Editing the dg.db and messing that up doesn't require TWRP to fix it and there's already a boot image with Magisk core only mode posted by Tulsdiver that will save you in case a Magisk module screws things up (the Google Pay fix module is working perfectly, BTW).
People probably shouldn't be messing with any of this until they understand everything that entails getting Google Pay working on a modified device. I'd argue that changing permissions of the dg.db file is just as difficult for anyone who doesn't understand what they're doing as it is going all the way and modifying the actual values in the dg.db file. It's all a slippery slope for the overzealous people anyway.

wrongway213 said:
Yeah... I'm not sold on making those kinds of edits or loading modules that do so without a working TWRP for this device anywhere in sight. That's precisely why I posted this thread - a working solution that doesn't involve editing things at that level - even if it doesn't work for everyone, I think it'll be more comfortale for those apprehensive to make certain changes without recovery :good:
Click to expand...
Click to collapse
Grab the modified kernel in the themes area that forces modules to be deactivated. That way you can just temp boot it to fix your issues if it goes south on you. I've used it several times so far when needing around with different combos of mods, etc...
https://forum.xda-developers.com/pixel-4-xl/themes/magisk-modules-disabler-booting-magisk-t3990557

While I appreciate your efforts this is a halfbaked hack and like the previous poster said it's will do nothing if those values have been tripped. I have always been a believer of figuring out things and going the long route that way you know why and how it was done it's very convenient for somebody else to do it and you just flash it but if you do it yourself you'll find out the intricacies of how Android and how rooting and modding works....

CyberpodS2 said:
Grab the modified kernel in the themes area that forces modules to be deactivated. That way you can just temp boot it to fix your issues if it goes south on you. I've used it several times so far when needing around with different combos of mods, etc...
https://forum.xda-developers.com/pixel-4-xl/themes/magisk-modules-disabler-booting-magisk-t3990557
Click to expand...
Click to collapse
That's kind of my reason for not wanting to use mods on this device yet - being tied to Fastboot at any given time isn't practical for me. Being unable to buy gas because my phone isn't set up isn't practical for me. My goal is to use my device just like I did when I had working TWRP on other devices without losing functionality OR having to rush to a PC for fastboot. Neither are practical solutions for me - making simple modifications that are easily overwritten gives me much less anxiety than messing with things at a deeper level.

wrongway213 said:
Yeah... I'm not sold on making those kinds of edits or loading modules that do so without a working TWRP for this device anywhere in sight. That's precisely why I posted this thread - a working solution that doesn't involve editing things at that level - even if it doesn't work for everyone, I think it'll be more comfortale for those apprehensive to make certain changes without recovery :good:
Click to expand...
Click to collapse
No disrespect, it looks like you're active here and helpful, but I don't think editing some values some values in a SQL editor that is tested and proven in a thread that has 55+ pages is going to hurt anything.

vanydotk said:
No disrespect, it looks like you're active here and helpful, but I don't think editing some values some values in a SQL editor that is tested and proven in a thread that has 55+ pages is going to hurt anything.
Click to expand...
Click to collapse
I'm apprehensive because of what SQL changes under the hood typically mean. I know most people haven't built ROMs, built kernels, maintained for a ROM Team, done platform development, etc. etc . - I have done all those things. One thing I learned is that there are TWO scenarios that will ALWAYS necessitate a clean flash no matter what - SQL changes and Android version changes. Given we don't know as much as we typically do about the state of Coral without TWRP due to Android 10 changes makes me unwilling to assume things proven to work on other devices will work when we get an OTA on this one. Chmod perms will be overwritten but SQLite changes can cause things to go south in my experience - none of which relating to this module. It's about SQL vs chmod for me. I'm doing what I trust and understand until recovery exists to fix things without needing a PC. If no one else finds use for it, I'm OK with that. For my use case - it makes perfect sense. :good:

Fair enough, I figured you knew what you were talking about, everyone needs to make their own decisions. Nonetheless, thanks for contributing!

Here's a simple way to get gpay to work on stock with root after you hide gms and gpay with magisk.
1. Install Termux app and open the app
2. Type pkg install sqlite hit enter and let it install.
3. Type su hit enter
4. Copy and paste this then hit enter
am force-stop /data/data/com.google.android.apps.walletnfcrel && chmod 777 /data/data/com.google.android.gms/databases/dg.db && /data/data/com.termux/files/usr/bin/sqlite3 /data/data/com.google.android.gms/databases/dg.db "update main set c='0' where a like '%attest%';" && chmod 444 /data/data/com.google.android.gms/databases/dg.db
5. Reboot

The Magisk modules are honestly easier.
Busybox module, SQLite module, reboot, the fix module, and reboot once more.

LLStarks said:
The Magisk modules are honestly easier.
Busybox module, SQLite module, reboot, the fix module, and reboot once more.
Click to expand...
Click to collapse
How hard is it to enter a few lines in terminal? Lol
People should learn how to fix things without always relying on a module or a zip they can flash.

The manual fix isn't persistent.

LLStarks said:
The manual fix isn't persistent.
Click to expand...
Click to collapse
What I posted is.

It's weird that google pay to registry my credit cards is so unstable after flashing Gpay Sqlite fixer 1.7. When flashing Gpay sqlite fixer 1.7 at first time, I could registry my 1st credit card but it failed in next credit card. It showed up an error message and said that my phone has been rooted and .... ", So I returned commend mode to key-in few words to make me registry rest 3-credit-card successfully.

You could just delete the GMS folder while rooted and it also works
This is something myself and another user found on the p3 when Google started tripping the values on unlock
Rolling back to a previous version also works but we found that deleting that folder from /data/data along with gsf folder fixed it
Of course after clearing gpay cache.
This is working on my p4xl too

wrongway213 said:
I'm apprehensive because of what SQL changes under the hood typically mean. I know most people haven't built ROMs, built kernels, maintained for a ROM Team, done platform development, etc. etc . - I have done all those things. One thing I learned is that there are TWO scenarios that will ALWAYS necessitate a clean flash no matter what - SQL changes and Android version changes. Given we don't know as much as we typically do about the state of Coral without TWRP due to Android 10 changes makes me unwilling to assume things proven to work on other devices will work when we get an OTA on this one. Chmod perms will be overwritten but SQLite changes can cause things to go south in my experience - none of which relating to this module. It's about SQL vs chmod for me. I'm doing what I trust and understand until recovery exists to fix things without needing a PC. If no one else finds use for it, I'm OK with that. For my use case - it makes perfect sense. :good:
Click to expand...
Click to collapse
It might work for you but like it's been said multiple times, if the values are already tripped then your method is useless. Then it would REQUIRE SQL editing.
Posting an incomplete or half baked method can cause issues with newer people on these forums no matter how "simple" it may be.
spaceman860 said:
How hard is it to enter a few lines in terminal? Lol
People should learn how to fix things without always relying on a module or a zip they can flash.
Click to expand...
Click to collapse
This 100%
Sent from my Pixel 4 XL using Tapatalk

Hi there. Just a question. With this mod google pay works flawlessly all the time? No need to redo the procedure all few days when there are updates to play service? Because i need a real stable google pay when i am out only with my mobile to pay.

Just delete the folder...GMS will recreate the folder withthe right values because magisk is already setup to hide GMS