Related
I'm a big linux enthusiast and have done a lot of neato stuff with my phone, including installing JF 1.31! This forum is great! I have a question though ... in /init.rc, would it be a bad idea to comment out "mount rootfs rootfs / ro remount" to make / writable on boot? I don't see a reason why not besides the obvious you'll-fark-something-up deal, but I would presume that as long as you're not piddying in root all the time, no problem (just like on a "desktop" linux system). Or ... is Android really not designed at all to have / rw, so there's exterior security vulnerabilities, chances the native UI could render data loss, etc.?
synthead said:
I'm a big linux enthusiast and have done a lot of neato stuff with my phone, including installing JF 1.31! This forum is great! I have a question though ... in /init.rc, would it be a bad idea to comment out "mount rootfs rootfs / ro remount" to make / writable on boot? I don't see a reason why not besides the obvious you'll-fark-something-up deal, but I would presume that as long as you're not piddying in root all the time, no problem (just like on a "desktop" linux system). Or ... is Android really not designed at all to have / rw, so there's exterior security vulnerabilities, chances the native UI could render data loss, etc.?
Click to expand...
Click to collapse
You can make / all you like. You can even change all the files in / all you like. But once you reboot, all changes will be lost.
The / filesystem is stored as a .cpio.gz file in boot.img. When android boots, it loads this root filesystem into memory. Any changes afterwards are in memory only.
If you want to change any of the files in /, you have to extract the boot partition, extract the .cpio.gz image, unpack, modify, re .cpio.gz, repackage into a boot.img, then flash it to your phone.
See this thread for details.
edit: something like what he said
beartard said:
I wouldn't do it for the simple reason that you don't know what 3rd party apps are programmed to do if they find a writeable root. Yes, there is a whitelist, but you can't be too careful. It's not too much trouble to remount it when you want to mess around.
Click to expand...
Click to collapse
Heck, let applications change / all they won't. Someone should write a file system monitor that tracks any changes in /, just to be able to laugh at the applications that are trying to change it.
JesusFreke said:
You can make / all you like. You can even change all the files in / all you like. But once you reboot, all changes will be lost.
The / filesystem is stored as a .cpio.gz file in boot.img. When android boots, it loads this root filesystem into memory. Any changes afterwards are in memory only.
If you want to change any of the files in /, you have to extract the boot partition, extract the .cpio.gz image, unpack, modify, re .cpio.gz, repackage into a boot.img, then flash it to your phone.
See this thread for details.
Click to expand...
Click to collapse
Really! Bizarre! Wow ... I would have never guessed that. That really saves ass on data loss/corruption for dumb things I suppose, but ... WEIRD! It doesn't sound all that hard to modify things even still, but damn. Well, you answered my question. Thanks!
PREFACE & CRY FOR HELP:
I’m pretty sure this guide works. This is how I got permaroot and write access to my DHD system files and directories. But I might have made mistakes. I hope some experienced people will read this guide and point them out. I hope newbs will wait for a few people to say if this guide is correct or not before trying this.
I mainly used Evostance's guide. Thank you Evostance (and all the others whose work I've ripped off here!) and I hope you understand me for posting this rather longer, newbified guide;
The guide:
This is a guide to rooting and gaining write permission to your Desire HD, written for the Android newb.
You ain’t dumb, you just don’t know Android. Even though I’m learning to program for this OS, I don’t know Android either. Not enough to root and gain write without the help of expert reverse engineers and other guide writers who have much more experience than I do with this OS.
However, all the knowledge is very fragmented right now, due to everyone being VERY EXCITED about root now being available on a NAND locked DHD. The info is there, but it takes some looking around, some warnings, some things I didn’t find in one place, but scattered through many posts on many threads.
That’s why I wrote this: for the Android newb who wants a rooted phone and doesn’t have the time to spend hours tracking down the information and all the caveats.
WARNING: THIS IS DANGEROUS AND CAN BRICK YOUR PHONE. IF YOU TRY THIS, IT IS YOUR OWN RESPONSIBILITY, NOT THE APP WRITTERS, NOT THE GUIDE WRITERS, JUST YOURSELF.
1.
First things first: you might have a lot of programs running which use temproot.
Remove them. ALL.
Check SuperUser which apps have been granted root, and uninstall them, removing all data. For previous (temproot only) versions of Visionary, it might be safer to stop it temprooting at startup, and restart your phone (longpress power, select restart or power off), then remove visionary, just in case.
Finally, remove SuperUser itself.
All the above might not be necessary, but there have been reports of trouble from having these programs running whilst trying to achieve permroot. So be safer rather than sorrier.
2.
Now your phone is essentially running a stock version; no programs running root are active, no surprises at startup. Titanium Backup etc etc are not going to interfere.
Get the following files and programs:
From the Marketplace:
-Gscript (Lite is fine)
-Terminal Emulator
-a root file explorer. The only program I’ve found which does what I need is Root Eplorer. It will cost you money, but Android Mate or Astro haven’t been able to do the job for me.
(DO NOT INSTALL YET -SuperUser; we’ll get this later on; if you install it now you might run into trouble whilst trying to get root, as it might interfere with certain program’s checks to see if you have root already. I mention this program here so you know you’ll need it later, so either have access to the Marketplace or have the .apk ready to install later on.)
Install these on your ‘clean’ phone.
From the internet:
-the files listed in the first post of :
http://forum.xda-developers.com/showthread.php?t=805327 (adwinp’s guide)
or
http://forum.xda-developers.com/showthread.php?t=834427 (Evostance’s guide)
I used the second link (and the guide Evostance wrote which is included). Use this time to read through what Adwinp and Evostance say. Follow the link to their threads and understand what you’re doing.
-get Visionary+ from the awesome Paul O’Brian.
DO NOT INSTALL THIS YET!
http://android.modaco.com/content/t...350/10-nov-r12-test-visionary-one-click-root/
Use a version higher than v11 (v12, v 13, v14 … I don’t know what version he’s on; you might have to look for v13 in that thread, page 6, 7 or 8, if he hasn’t released a newer version).
3.
Now, get all these files and apk’s on your phone. Sync ‘em, download them direct, use wifi, whatever. Just don’t install them (yet). You want the raw files.
Specifically:
-the visionary apk
And from any of those packages you downloaded from the guides listed above:
-the wpx.sh and hboot.sh files (found in the gscript folder of Evostance’s guide’s package): these should be put on your SDCARD, in a directory named gscript (you might be able to put them anywhere, I put them here and the process worked for me).
-the correct wpx.ko and hboot-XXXXXX.nbo files. The XXXXXX refers to a specific hboot file, corresponding to if you updated your phone over the air with the HTC fixes or not. These files are found in rar/zip packages found in the previous mentioned guides (and probably many other mirrors). Pick the files which are located in the folder whose name corresponds to your kernel version (found on your phone using menu -> settings -> About phone -> Software Information -> kernel version).
These .ko files should be put in your SDCARD’s root directory
4. RECAP:
Now you should have
-Gscript and Terminal Emulator installed
-the Visionary .apk on your sd card somewhere
-wpx.sh and hboot.sh in the SDCARD\gscript directory
-wpx.ko and hboot-XXXXXX.nbo on your SDCARD’s root.
5.
Now we’re almost at the point of no return.
Run Gscript.
Hit the menu, “add script” and hit “load from file”. Select the wxp.sh file. Have “run as superuser” selected.
Do the same for hboot.sh.
Exit gscript.
6.
Install Visionary.
Don’t do anything except get temproot. ONLY hit the temproot button; don’t change anything else.
Wait.
You should have temproot now. To be sure, go and select ‘run at boot’ (the ‘re-get temproot’ checkbox) in Visionary and reboot your phone (long powerkey press, restart or shutdown, then restart your phone).
You should have temproot again. You can check this after the next step:
7.
Install SuperUser (preffereably from the Market, so you have the latest version).
If you start the Terminal Emulator, you should now be able to type
su
and hit enter, and the prompt will change from a $ to a #. If so, you have root. You might have to allow SuperUser access to the Terminal Emulator. Do so.
7.
After you have temproot, you should now start Gscript. In the next bits, you might get “Gscript is trying to use SuperUser status” (or somesuch) popup message. Allow this.
Run the wxp script. It should report an error. This is OK.
Run the hboot script. If all is well, you should get a three (actually four) line report saying that something worked.
If you get a message saying that this operation couldn’t run, you’ve done something wrong, somewhere. I can’t help you: try from the beginning or something. Sorry I can’t be more helpful than that.
8.
Point of no-return:
You have temproot, you have installed SuperUser and you have run the two Gscript commands.
In this next bit, SuperUser might prompt that Visionary is seeking root permission. DENY THIS. It’s my belief that Visionary expects NOT to get that permission and only then runs. Giving permission leads to not much happening after you press the root button. I suspect a few problems happen due to this. Anyway:
Startup Visionary again. (maybe select ‘mount system as r/w’ … for me it didn’t, which is part of why I’m writing this guide).
Now, in Visionary, hit the ‘get permroot’ button. This process might take a while. If it’s working, the menu you pushed the button on should whisk away to the side: that way, you know Visionary is getting you permroot. Your phone should reset and you should have permroot.
8.
Making it stick.
Use Root Explorer for this next part. I tried using other programs, but they wouldn’t work. Mainly because granting write access hadn’t worked properly.
Now copy
su to /system/bin/
and
Superuser.apk to /system/app/
You can find su in system/xbin/ and SuperUser.apk in /data/app/. You might have to mount the system directories as r/w (from r/o) using Root Explorer. I had to do this, as I didn’t have write access to system files, even though I asked Visionary to do this. No biggy, but it did mean I had to buy Root Explorer. Not a bad price to pay for permroot, write access and a pretty good file explorer
Now, finally, open Terminal Emulator and type:
su <enter>
chmod 4755 /system/bin/su <enter>
After typing ‘su’, the prompt should change. If it doesn’t, as mentioned before, you don’t have any kind of root (or Term.Emu doesn’t have it, maybe resetting SuperUser’s settings will help) and I can’t help you.
Now you should have total control over your system files. You now finally own your phone.
9.
Thanks to everyone involved, from the hackers to the helpers to the guide writers to those who just chimed in. I didn’t do anything except steal all this info from them, use their files and programs and write this down.
Thank you; we NAND locked phone users are in your debt.
Hi MacDegger,
Good effort, a couple of things that when reading appear a little off, unnecessary or confusing
"You should have temproot now. To be sure, go and select ‘run at boot’ (the ‘re-get temproot’ checkbox) in Visionary and reboot your phone (long powerkey press, restart or shutdown, then restart your phone).
You should have temproot again. You can check this after the next step:
7.
Install SuperUser (preffereably from the Market, so you have the latest version).
If you start the Terminal Emulator, you should now be able to type"
- There is no need to reboot. Also, checking "run on bootup" is something I would refrain from. Simply temp-root is enough
- Why "install superuser" from market?! temprooting via visionary (r12 is what I used) already pushes Superuser.apk to /data/app, so there is no need to re-install from market
- So instead, I would simply temp root with visionary. No reboot, not market download
In this next bit, SuperUser might prompt that Visionary is seeking root permission. DENY THIS. It’s my belief that Visionary expects NOT to get that permission and only then runs. Giving permission leads to not much happening after you press the root button. I suspect a few problems happen due to this. Anyway:
Startup Visionary again. (maybe select ‘mount system as r/w’ … for me it didn’t, which is part of why I’m writing this guide).
Now, in Visionary, hit the ‘get permroot’ button. This process might take a while. If it’s working, the menu you pushed the button on should whisk away to the side: that way, you know Visionary is getting you permroot. Your phone should reset and you should have permroot.
Also not necessary. Visionary R12+ (actually use the R13 version as this one skips the "root already installed routine" some people have issues with) will permroot your device straight after temprooting it just fine. It will open the wpx.ko, will write busybox and su to system/xbin, will repush superuser.apk to /data, will then copy wpthis-lovinglymadebymodaco.ko to /data/local and then reboot.
After this reboot, you are already perm rooted. uninstall visionary, and reboot to test it.
Run the wxp script. It should report an error. This is OK.
NOTE: running visionarx to PERMROOT will copy the required wpthis.ko file (with the right kernel version to /data/local), and will call it "wpthis-lovinglymadeforyoubymodaco.ko."
So as a matter of fact you now have 2 (two) modules in /data/local, the wpx.ko and modaco (pauls) version of it. Whilst no biggy, I would simply adapt the wpx script to insmod pauls version, not wpx anymore. Just to be safe the right kernel is used when execuing and opening the exploit to remove the RW protection to /system, and I believe visionary+ actually checks the kernel and then pushed the correct wpthis*.ko to /data/local.
The next steps,
8.
Making it stick.
Use Root Explorer for this next part. I tried using other programs, but they wouldn’t work. Mainly because granting write access hadn’t worked properly.
Now copy
su to /system/bin/
and
Superuser.apk to /system/app/
You can find su in system/xbin/ and SuperUser.apk in /data/app/. You might have to mount the system directories as r/w (from r/o) using Root Explorer. I had to do this, as I didn’t have write access to system files, even though I asked Visionary to do this. No biggy, but it did mean I had to buy Root Explorer. Not a bad price to pay for permroot, write access and a pretty good file explorer
Couple of things - visionary will only mount to /RW when flagged and executing TEMPROOT. SO by default, upon reboot the system is always in R/O mode, not R/W mode, whether you use visionary or install root manually. Thats fine and as you said, you can remout RW with RootExplore or via ADB.
Pushing SU and superuser.apk from /data/app and /system/xbin to /system/app and /system/bin is, whilst "safe" not really required. Superuser.apk is quite happy being on /data/app, and IF you must move it to /system/app, you should do a couple of things.
a) MOVE it, not copy it. This way, the user data (which permissions are allowing access to root) will not uninstall, and the permissions will also be set correctly (664 permissions for apps, or RWRWR). Copying it is not ideal, as it could simply kill/forget or cause other issues to it when you do it wrong. And if the permissions are missing as you didn't copy right, you basically blocked yourself our of your root-method permanently.
b) Copying su to system/bin is nice, but again, I would rather create a symlink to is in system/bin to execute/link to system/xbin. Again permissions are necessary and vital
They work just fine in /data/app and system/xbin. THe only reason to move su to system/bin is that some apps simply look for SU in /system/bin, and not in system/xbin. Most well programmed apps that require root will find it anyway, regardless of whether su is in /system/bin or system/xbin.
SO, I would, if I had to advice "noobs", simply leave them where they are. I would temproot, permroot and then install the s-off recovery. Nothing more after step 7.
PS the point of no return, the really dangerous bit, is actually THIS
Run the hboot script. If all is well, you should get a three (actually four) line report saying that something worked.
Thats where your system is flashing the bootloader, this is the risky part, where things can go terribly wrong. So "something worked" is maybe not very noob-friendly SO when writing for newbies, make sure they understand ONE thing.
ALL they do in your guide is reversible with flashing the RUU again if something got messed up.
But this
"Run the hboot script. If all is well, you should get a three (actually four) line report saying that something worked. "
This is where you CAN turn your device into a 600 USD paperweight!
I think this guide has too much info for the average user to understand.
It's better for the average user to just permroot only and leave hboot alone until they know what can go wrong.
My guide takes alot less steps to achieve S-OFF, because I use the kernel module Visionairy+ leaves behind after permrooting. In other words if you fail to permroot, you won't be able flash HBOOT until you read the other topics on how to modify the module. Which leaves the average Jo far away from a possible brick without some knowhow.
Just my two cents.
Thanks for your awesome comment, Thyrus! I think that an android newb (like me ) now has enough information, after reading this with your post, to do this safely.
I'm going to incorporate your comments into the post, but there's one thing I'm hazy on. Thing is, what I described above was the exact sequence I used to get root and write. You seem to suggest that the whole gscript thing is unnecessary and visionary13+ permroot does all of that anyway, except for flashing the hboot?
So basically I flashed my hboot twice, and because I ran the two gscript scripts, I basically rooted my phone twice?
Just to be sure, you suggest getting rid of the whole gscript section and replacing it with "run visionary permroot now, and if you really want to (and at your own risk) flash the hboot using the gscript hboot.sh"?
I'll wait for your response before changing, just to be sure. Anyway, thanks for your great post!
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
My thread and project are inactive now. Please accept my apologies for this inconvenience.
ast.ls
Blackout
ast.np
Blackout
ast.pm
Blackout
ast.ops
Blackout
ast.settings
Blackout
ast.storage
Blackout
2nd Feedback
Thanks for the dedicated thread. If I may, some more nitpicking about rudimentary things.
ast.install has hard coded file names of ast scripts, that's not very portable:
l_Scripts=( "ast.ls" "ast.np" "ast.pm" "ast.ops" "ast.settings" "ast.storage" "astcore" )
I have packages ( "ast.ls" "ast.net" "ast.pm" "ast.ops" "ast.set" "ast.sto" "astcore" )
so more generic pattern for handling like ast* may be considered. In case of renaming, ast.install could have a file renaming template (ast.rename) with say key value rows for generic renaming procedure before starting the actual transfer/installation. Another thing it could try to perform chmod 755 after installation.
EDIT: Looks like you have it but it doesn't work as system is read-only for say /system/xbin installation directory. So installation can be performed either by hand from a file manager with root access or TWRP recovery (install script for easy TWRP install may be a solution).
Do you have any comparative performance observations regarding background network access?
2a. The interesting are the influence of size of the blacklist on system/apps behaviour (fluency, speed, memory usage or possibly noticed negative consequences re some specific apps). By default whitelist contains less than a dozen of items, blacklist is empty. What packages would you consider safe to remove from the whitelist, like LG weather widget? Will 300 blacklisted items be completely practical to have?
2b. Battery consumption changes and practical benefits measured re having hundreds of packages blacklisted vs normally empty blacklist.
2c. I remember you mentioned a FW app you installing on the end of device restoration process, what functionality separate FW app provides for your use case, or is that just an app like AdAway?
hotcell said:
Thanks for the dedicated thread. If I may, some more nitpicking about rudimentary things.
ast.install has hard coded file names of ast scripts, that's not very portable:
l_Scripts=( "ast.ls" "ast.np" "ast.pm" "ast.ops" "ast.settings" "ast.storage" "astcore" )
I have packages ( "ast.ls" "ast.net" "ast.pm" "ast.ops" "ast.set" "ast.sto" "astcore" )
so more generic pattern for handling like ast* may be considered. In case of renaming, ast.install could have a file renaming template (ast.rename) with say key value rows for generic renaming procedure before starting the actual transfer/installation. Another thing it could try to perform chmod 755 after installation.
EDIT: Looks like you have it but it doesn't work as system is read-only for say /system/xbin installation directory. So installation can be performed either by hand from a file manager with root access or TWRP recovery (install script for easy TWRP install may be a solution).
Do you have any comparative performance observations regarding background network access?
2a. The interesting are the influence of size of the blacklist on system/apps behaviour (fluency, speed, memory usage or possibly noticed negative consequences re some specific apps). By default whitelist contains less than a dozen of items, blacklist is empty. What packages would you consider safe to remove from the whitelist, like LG weather widget? Will 300 blacklisted items be completely practical to have?
2b. Battery consumption changes and practical benefits measured re having hundreds of packages blacklisted vs normally empty blacklist.
2c. I remember you mentioned a FW app you installing on the end of device restoration process, what functionality separate FW app provides for your use case, or is that just an app like AdAway?
Click to expand...
Click to collapse
I "liked" your post because your nitpicking is only indication of your care and liking AST scripts, I respect that.
Now, onto addressing your 2nd phase of nitpicking, mildly jocking. As I mentioned previously, perhaps in Info Bank thread, once I get a question, in order not to repeat myself I would cover it, thoroughly, in its relevant post/tool. Please read post #3 for everything I could share on Netpolicy.
Naming issues: Please rename/copy ast.install to ast.setup or anything you wish then update the array list to your liking. This is a quick solution for anyone with the same issue. The beauty of AST is you can modify its scripts in any way you wish in a text editor, on any platforms. Please kindky, don't ask me and provide me with the solution when is not practical. I'm referring to your copying idea instead of hardcoded list of scripts. I know what I'm doing in this instance.
ast.install automatically mounts /system to 'rw' if it was 'ro'. If it was 'rw' already it never set it back to 'ro' to avoid causing problems to the process which set it to 'rw' before ast.install was executed. There are times, /system cannot be mounted as 'rw'. I can guess why, but don't wish go into details for now. A reboot often solves the problem. ast.install will show an error message if it fails but you didn't mention that in your post. So I have no idea what you have complained about at the end.
You have mentioned TWRP before as well. In order to avoid confusion to other users, AST has nothing to offer in TWRP and I don't know why you think it does. I have installed AST to /system/xbin on two LG V20 phones with the same script with no issues. If it is easier to do this manually please do by all means. When you mention installing AST from TWRP, you would give the wrong impression to users, as if AST is an overly complicated thing.
I don't have the time nor the patience to measure battery consumption. Battery consumption is very subjective, as you know. However, I would appreciate it if you like to share your future findings with the community in here.
I'm sorry, I don't recall what was exchanged in reference to 2.c.
Since I know you like AST, how about sharing something with the community about how it made things easier for you? That is a feedback too. No one would take my word for it because they think I'm on my way to become a millionaire.
3rd Feedback
xdav20 said:
I "liked" your post because your nitpicking is only indication of your care and liking AST scripts, I respect that..
Click to expand...
Click to collapse
I never do posts asking or hoping for likes. That would be rather strange assumption. Regarding your obviously negative connotation here, it would be more appropriate if you simply remove the "like" you made.
Now, onto addressing your 2nd phase of nitpicking, mildly jocking. As I mentioned previously, perhaps in Info Bank thread, once I get a question, in order not to repeat myself I would cover it, thoroughly, in its relevant post/tool. Please read post #3 for everything I could share on Netpolicy.
Click to expand...
Click to collapse
Thank you for more detailed explanation. I have to note that you added the explanations in your post #3 after I asked the relevant net policy questions. Either way, IMHO your statement "I think the performance loss or gain is debatable, totally dependant on how Android internally implemented it, and, frankly, this is something I don't wish to get heavily involved with. Please kindly, keep me out of future debates." is not very encouraging. To me it seems that you aren't interested in the discussion of benefits in performance or possible battery savings here, thus logically negating the major possible purpose of using your tool from users perspective. That's strange indeed, but I do respect your wish, so that's it.
Naming issues: Please rename/copy ast.install to ast.setup or anything you wish then update the array list to your liking. This is a quick solution for anyone with the same issue. The beauty of AST is you can modify its scripts in any way you wish in a text editor, on any platforms. Please kindky, don't ask me and provide me with the solution when is not practical. I'm referring to your copying idea instead of hardcoded list of scripts. I know what I'm doing in this instance.
Click to expand...
Click to collapse
Here you are contradicting yourself. As you previously mentioned, you made a deliberate effort to ensure any script can be renamed and still maintain its integrity thus boosting flexibility of usage even more. But here you are basically insisting such move would not be practical. In previous post I suggested you to maintain this flexibility by introducing renaming templates file, so updating the tool will be a simple seemless step/command, without manual intervention required, regardless of a chosen naming scheme. Well, again, it's your call. Perhaps you'd reconsider, just like you did with the inner AST folder in the distribution archive (Thanks BTW for that!).
ast.install automatically mounts /system to 'rw' if it was 'ro'. If it was 'rw' already it never set it back to 'ro' to avoid causing problems to the process which set it to 'rw' before ast.install was executed. There are times, /system cannot be mounted as 'rw'. I can guess why, but don't wish go into details for now. A reboot often solves the problem. ast.install will show an error message if it fails but you didn't mention that in your post. So I have no idea what you have complained about at the end.
Click to expand...
Click to collapse
Indeed I mentioned this due to failure to obtain the expected result on execution of ast.install. Note this script can't be run from ext SD card due to the obvious permission / media format issue. But, normally the /system is in RO state, so even if jackterm has required root permission, the ast.install still would fail when run from internal storage:
elsa:/storage/emulated/0/Download/ast #sh ast.install /system/xbin
cp: /system/xbin/ast.ls: Read-only file system
chmod: chmod '/system/xbin/ast.ls' to 100755: Read-only file system
cp: /system/xbin/ast.net: Read-only file system
chmod: chmod '/system/xbin/ast.net' to 100755: Read-only file system
cp: /system/xbin/ast.pm: Read-only file system
chmod: chmod '/system/xbin/ast.pm' to 100755: Read-only file system
cp: /system/xbin/ast.ops: Read-only file system
chmod: chmod '/system/xbin/ast.ops' to 100755: Read-only file system
cp: /system/xbin/ast.set: Read-only file system
chmod: chmod '/system/xbin/ast.set' to 100755: Read-only file system
cp: /system/xbin/ast.sto: Read-only file system
chmod: chmod '/system/xbin/ast.sto' to 100755: Read-only file system
cp: /system/xbin/astcore: Read-only file system
chmod: chmod '/system/xbin/astcore' to 100755: Read-only file system
I) ast.install: Installation completed.
elsa:/storage/emulated/0/Download/ast #
Why and how reboot supposed to resolve that?
EDIT: Looks like it works fine when performed right after reboot! It would be nice if install script would try to perform a mount, cp, chmod and report about the failure. Instead of showing the (fake) message "Installation completed." the hint to reboot and retry would be much more useful.
You have mentioned TWRP before as well. In order to avoid confusion to other users, AST has nothing to offer in TWRP and I don't know why you think it does. I have installed AST to /system/xbin on two LG V20 phones with the same script with no issues. If it is easier to do this manually please do by all means. When you mention installing AST from TWRP, you would give the wrong impression to users, as if AST is an overly complicated thing.
Click to expand...
Click to collapse
It has nothing to do with wrong impressions. All I tried to suggest was an attempt to provide a path to easy and working solution to install/update AST and have a workaround for system RO state issue as described above. One still will have to ensure the system partition is mounted in TWRP before doing AST install/update. Sure if ast.install or its exec environment can be fixed, there would be no need to reboot to recovery or perform manual steps with a file manager.
I don't have the time nor the patience to measure battery consumption. Battery consumption is very subjective, as you know. However, I would appreciate it if you like to share your future findings with the community in here.
Click to expand...
Click to collapse
If and when I'll proceed with net policy customisation and start to have some comarative data on battery consumption, I'll try to post here without involving you to the subject as per your wish to keep you out of future debates.
@hotcell
I have attached a modified version of ast.install that would double check if 'mount' command remounted /system rw or not. If the script still fails to copy your scripts, without displaying an error message, then, and previously, the problem has nothing to do with my script. I haven't developed 'mount' binary nor know why on your particular system things doesn't work normally. There is no 'fake' message, because of what happens the script assumes everything went well. If the scripts were previously copied to the target location, there is no easy way to know if the copy was successful or not. For such non-critical job, doing more is waste of time.
"ast.storage -lb online" displays the mounted partitions. The very last data is the current read/write status of the partition. After a reboot, could you run the above command to see what it prints about /system partition before and after running ast.install please.
I'm a tool maker, I'm not going to tell anyone where you can use my tool. I can provide guidance how the tool should be used, for productivity purposes only. What thing you have forgotten was, ast.np is a helper tool for Android Netpolicy tool. Without ast.np it is, literally, impossible to use it due to the input format it takes. Knowing how over analytical you can be, I made it clear I wish to stay away from any future debates myself. I have not stated, no one else can debate about it on my thread. I'm sorry, if you took my statement personally and I encourage you to use my thread to discuss anything related to AST. I would response, if I had to.
I thought for a while, how can I prove to @hotcell I wasn't being sarcastic when I "liked" his post? My proof is at the very end of that post when stated: "Since I know you like AST, how about sharing something with the community about how it made things easier for you?" If I didn't mean it, I wouldn't have stated a factual thing, I would had said; "If you like AST then why don't you...". Since I meant what I said without a menacing connotation, I stand by my previous decision. However, I do share your sentiment about the "like" system in place.
I have a serious issue with you or anyone else who think I have to accommodate to their specific needs in the same release that is meant for the public and no matter how accommodating I have been to you, you still have an approach that I don't feel comfortable with it. I will response equally to anyone who would want to dedicate terms to me. Once you renamed the scripts, I do not have to change the installer with your suggestion method, period. Have you thought, in the same directory users might have scripts or files starting with the "ast" prefix? That was the reason I hard-coded the script names to avoid potential disasters.
Edit: Noticed your edited comment about everything started working after a reboot. I do not like to discuss about something, specially in a public forum, when I do not have factual information. I'm normally good at observing patterns. I'm purely guessing, the reason behind the failure of mount command is to do with how certain file managers that support root handle mounting /system partition. Of course, there is always more than one reasons to such conditions.
Here is what you can do to see if that is the caase or not. Do everything as you would do after a reboot. Use the file managers you use and access the /system partition and copy something over to force the file manager to make the /system partition rw. Exit the file manager and then try the installer script again. Repeat the same thing, this time don't use the same file managers and after the system has been up and running for awhile, try the installer script again. What did you observe?
4th Feedback
Yes, you were right. After writing to the /system with MiXplorer file manager, the ast.install script fails. See screenshots: first made befre using MiX on /system, after that script worked; the second pic shows the ast.install.sh failure after using MiX, please note the (fake because of actual failure to mount and errors reported before) success report on the last line; the trird pic was made after the failed install. Also, with Root explorer, it asks to remount the system partition as R-W for operation, after that the ast.install(.sh) fails exactly as shown on the middle pic.
xdav20 said:
There is no 'fake' message, because of what happens the script assumes everything went well. If the scripts were previously copied to the target location, there is no easy way to know if the copy was successful or not.
Click to expand...
Click to collapse
The easiest way to know is probably to try to write an empty file into installation dir and check for its existance. Another way would be checking file timestamp.
I have a serious issue with you or anyone else who think I have to accommodate to their specific needs in the same release that is meant for the public and no matter how accommodating I have been to you, you still have an approach that I don't feel comfortable with it. I will response equally to anyone who would want to dedicate terms to me. Once you renamed the scripts, I do not have to change the installer with your suggestion method, period. Have you thought, in the same directory users might have scripts or files starting with the "ast" prefix? That was the reason I hard-coded the script names to avoid potential disasters.
Click to expand...
Click to collapse
Of course you don't have to accomodate or appease anyone. If maintaining renaming flexibility and extending that to install script is not you goal AST tool may benefit in terms of flexibility, just forget about this. And yes, I thought about ast prefix oversimplicity. That is the exact reason why I suggested ast.rename file template where one can explicitly define source-destination name pairs. So having a single fixed named file name for such template is all needed to avoid any possible clash.
hotcell said:
Yes, you were right. After writing to the /system with MiXplorer file manager, the ast.install script fails. See screenshots: first made befre using MiX on /system, after that script worked; the second pic shows the ast.install.sh failure after using MiX, please note the (fake because of actual failure to mount and errors reported before) success report on the last line; the trird pic was made after the failed install. Also, with Root explorer, it asks to remount the system partition as R-W for operation, after that the ast.install(.sh) fails exactly as shown on the middle pic.
The easiest way to know is probably to try to write an empty file into installation dir and check for its existance. Another way would be checking file timestamp.
Of course you don't have to accomodate or appease anyone. If maintaining renaming flexibility and extending that to install script is not you goal AST tool may benefit in terms of flexibility, just forget about this. And yes, I thought about ast prefix oversimplicity. That is the exact reason why I suggested ast.rename file template where one can explicitly define source-destination name pairs. So having a single fixed named file name for such template is all needed to avoid any possible clash.
Click to expand...
Click to collapse
Thank you for the quick response. Of course, if my script fails, so as everything else from command line. Now that we established my guess is an actual fact, I have another immediate concern.
Thanks to your screenshots, I have noticed storage.ast -lb command is not displaying the partition fs type and partition read&write status of /system and /userdata and there were errors. I installed Mixplorer and navigated to xbin and created a file. Went back to terminal and used ast.storage -lb online again and it reported everything correctly. You either have a corrupt fs table or there is a condition that I haven't seen before. To make sure, I would like to ask you to send me the following files by running these commands please:
Code:
cat /proc/mounts > mounts
cat /proc/self/mountinfo > mountinfo
cat /proc/self/mountstats > mountstats
Please make sure you have used Mixplorer or the usual things you do that may cause the problem first.
Edit: After a reboot, please run the ast.storage -lb online again and please report back if there were errors. I'm guessing if you do, there is something wrong on your end.
Disclaimer: At the time of publication of this article, I have not found a way to remedy the problem with the application mentioned in this article. If you did, please notify me to make the appropriate changes to this article.
This article came to existence after exchanging messages with @hotcell to which my further investigation revealed a problem with MIXplorer app. I understand MIXplorer has a thread on XDA so there is a chance the developer to be contacted to rectify the problem.
The problem is after /system partition is remounted 'rw' (Read & Write) MIXplorer does not set the partition back to 'ro' (Read-only) even after the application is closed explicitly. This can leave you extremely vulnerable in case a malicious app awaits for such opportunity. Fortunately, after a reboot all partitions will be set back to their default status. However, users might not reboot their phones for days.
Root Explorer from SpeedSoftware has a mount toggle (rw,ro) button for each partition you use which it gives you the control to change the status at will. Then I tested ES File Explorer, as soon as I closed the app the /system was remounted back to 'ro'.
Thanks to ast.storage -lb command I could easily tell what was going on. My advice to you is, to either contact the developer of MIXplorer and request the partitions to be remounted as 'ro' upon exiting the app or similarly to provide a toggle button. In the mean while, I wouldn't use MIXplorer on a device that is connected to the internet.
5th
@xdav20
Although irrelevant in the thread common context, please see the attachment below (as it looks like you disabled PM functionality).
I see your AST gives formatting errors, but practically I can't see any problems with my system. Also, looks like if /system left R-W mounted by a file manager or other app, AST has no way to proceed. As you noticed about re-mounting on-the-fly from UI, reboot can be avoided by remounting the /system as RO in Root Explorer. Also, another decent file manager X-plorer doesn't need an (clean) exit as it will re-mount the system as RO after FS operation finished.
hotcell said:
@xdav20
I see your AST gives formatting errors, but practically I can't see any problems with my system. Also, looks like if /system left R-W mounted by a file manager or other app, AST has no way to proceed..
Click to expand...
Click to collapse
Thank you for the files. I will start looking into them.
I have already stated, two posts up, ast.storage's -lb command works fine on my phone even with MIXplorer installed and /system remounted rw. While I'm trying to establish if your phone has a problem or not, I have to be here correcting your incorrect statement. Also, I'm wondering why you never reported the error messages before when you did about other things?
Edit: I have attached a screenshot to prove everything works. I deliberately set the /system to rw.
6th
xdav20 said:
Thank you for the files. I will start looking into them.
I have already stated, two posts up, ast.storage's -lb command works fine on my phone even with MIXplorer installed and /system remounted rw. While I'm trying to establish if your phone has a problem or not, I have to be here correcting your incorrect statement. Also, I'm wondering why you never reported the error messages before when you did about other things?
Click to expand...
Click to collapse
Perhaps my statement is incorrect, I've no idea. But how would you explain that after Root Explorer toggling to RO state ast.install works perfectly, what Root Explorer can do that ast.install can't?
For the last question there is an easy answer: When I reported about "fake installation success" clause, it was obvious the copy failed, screenshots were attached. Timing to report wasn't/isn't critical for me. Also, looks like you are using SuperSU while I've Magisk, maybe there are some diffs/settings related?
EDIT: After playing with renaming ast.net in /system/xbin via X-plore, Root Explorer and MiX more:
1. X-plore always know how to rename the file
2. Root Explorer knows and warns when in RO state, but fails to rename after subsequent renamings in other FMs. Toggling RW->RO>RW restores renaming capability.
3. MiX fails to rename first.
hotcell said:
Perhaps my statement is incorrect, I've no idea. But how would you explain that after Root Explorer toggling to RO state ast.install works perfectly, what Root Explorer can do that ast.install can't?
For the last question there is an easy answer: When I reported about "fake installation success" clause, it was obvious the copy failed, screenshots were attached. Timing to report wasn't/isn't critical for me. Also, looks like you are using SuperSU while I've Magisk, maybe there are some diffs/settings related?
EDIT: After playing with renaming ast.net in /system/xbin via X-plore, Root Explorer and MiX more:
1. X-plore always know how to rename the file
2. Root Explorer knows and warns when in RO state, but fails to rename after subsequent renamings in other FMs. Toggling RW->RO>RW restores renaming capability.
3. MiX fails to rename first.
Click to expand...
Click to collapse
Found the cause, I think I have the solution, and I have to leave to my dentist appointment soon. I will release a fix as soon as I can. There is nothing wrong with your device but with what you use that commonly cause problems to everyone else's (not literally) code. Thanks again for the files. The future fix will not fix the mount issue, mount issue is a common issue in Android because so many processes use /system partition and bound to be conflicts.
7th
xdav20 said:
Found the cause, I think I have the solution, and I have to leave to my dentist appointment soon. I will release a fix as soon as I can. There is nothing wrong with your device but with what you use that commonly cause problems to everyone else's (not literally) code. Thanks again for the files. The future fix will not fix the mount issue, mount issue is a common issue in Android because so many processes uses /system partition and bound to be conflicts.
Click to expand...
Click to collapse
Thanks, although I have no idea what you are going to fix (as it seems the issue is in mounting)
Anyway, I thought you can try to implement an algo like this:
1. check if /system looks mounted as RW, remember the state for later restoration, if not RW, try to re-mount
2. create am empty file named as current time in installation dir
3. try to check if it exists. if yes, delete it and set flag ready=true and proceed to #5.
4. if flag tried is not set (false), try to make double re-mount RW>RO>RW, set flag tried=true, return to #2.
5. if flag ready=false, return error message asking to either reboot or mount /system as RW and exit
6. if ast.rename is absent from install dir, perform scripts copy, otherwise the same with renaming according to the template
7. set chmod on script files as required. Done.
@hotcell
I have attached a pre-release version of AST to this post. This release contains support to handle multiple mountpints on online blocks. Android by default has one single mountpoint per block. However, components/su such as Magisk creates additional mountpoints, one on /dev/block/sda14 and two on /dev/block/sda18. AST can now handle multiple mountpoints on any online blocks, referring to -lb command. Thank you again for the files and your assistance in resolving this issue.
As you have guessed by now, Magisk was the cause of errors and I'm guessing the source of your /system mount issues. Now, that '-lb' command can show correct information on your device, you can keep your eyes on read and write status of both mountpoints on /dev/block/sda14. Please kindly provide a screenshot of '-lb online' so I can make sure everything was okay before releasing it on OP. Since you have installed AST in /system/xbin, please do not run anything locally without specifying its full parh in command line. I'm updating OP about this point shortly.
One minor matter, I have to respectfully ask you to refrain from referencing to AST scripts as your renamed versions. I got confused when you referenced ast.np to ast.net. For anyone following our conversations it can workout confusing too. At this point of time, I don't wish to make a rule and publish it on OP. I hope you can understand the point I raised. Thank you for your understanding.
Edit:01
Added two screenshots. Magisk-Partitions image shows the online partitions with Magisk being installed (based on your device data files) and Default-Partitions image shows a typical device without Magisk? Have you spotted the additional entries?
Currently running a OnePlus 8T + 5G with unlocked/TWRP bootloader which is not rooted, since neither of the two methods want to work on my specific version (KB2007; unlocked former T-Mobile).
Anyway, I'm trying to switch to another ROM but I'm wondering how best to backup/restore all of my apps. Loved using Titanium Backup way back in the day, but am I still correct in assuming that it doesn't work correctly without root access? If so, are there any non-root methods of backing up all or most of my apps along with their current configurations/etc to restore into the new ROM once it's installed? Obviously, most ROMs will support doing it through Google Play, but then it takes forever to log back in to each app, set it all back up, etc. If I've been missing some basic way of restoring all the apps with their configurations intact, please feel free to smack me upside the head with the answer =)
And my apologies in advance if I'm misusing any of the terminology. Before this phone, it has been at least five years since I even tried rooting/unlocking/etc, so I'm a bit rusty.
In the world of computers an app belongs to person who installed it, app's data are owned by the app itself.
Hence it should be obvious that only an user with elevated rights ( AKA Superuser or Root ) can perform a backup and/or restore.
Take note that a temporary root is enough to do the jobs.
Got it. So, in other words, figure out how to root the phone despite the troubles I've been having trying to do so. Unless there's some sort of temporary root privs available that I've never heard of?
To get a temporary root all you have to do is to add to Android OS the binary called SU
Example
Code:
adb push <LOCATION-OF-SU-BINARY-ON-COMPUTER> /data/local/tmp/
adb shell "chmod +x /data/local/tmp/su"
what then allows you to run Android shell commands when elevated rights are needed
Example
Code:
adb devices
adb shell "/data/local/tmp/su -c '<SHELL-COMMAND-HERE>'"
Am I correct in assuming that SU is the same as "switch/substitute user" in *nix? Does that mean I can run TB from the ADB shell, assuming I include the correct command line arguments? Something along the lines of doing a SUDO in *nix before running something that requires admin access or whatever.
I know this might be quite different from what you're looking for maybe?
In the future if you get a rooted rom, I use something called Migrate from the play store, it requires root and just copies all your data into a bunch of twrp flashable zip files.
Play Store
silentrawr said:
Am I correct in assuming that SU is the same as "switch/substitute user" in *nix? Does that mean I can run TB from the ADB shell, assuming I include the correct command line arguments? Something along the lines of doing a SUDO in *nix before running something that requires admin access or whatever.
Click to expand...
Click to collapse
SU in root context usually means super user, as a user with all privileges, but it's the same thing as super user, so yes.
Hello Everyone,
I too am interested in a backup solution for my Android smartphone.
I would happily root or temporarily root, but despite having a computer background that dates back to Unix, I am an Android novice and do not know how to perform these operations which to most people here seem elementary.
Could someone please point me to an easy to understand primer on either temporary root or permanent root.
I would be very appreciative and I am sure that there are other readers of this post who would benefit as well.
Thank you.
AndroidNewbie9000 said:
Could someone please point me to an easy to understand primer on either temporary root or permanent root.
I would be very appreciative and I am sure that there are other readers of this post who would benefit as well.
Thank you.
Click to expand...
Click to collapse
The thing is, that the "official" way to root a device nowadays usually includes a wipe of all user data. You basically have to decide that you want to do full backups before you use an app. This is a security measure so that an attacker cannot use the official way to e.g. access app-internal data on a stolen phone, like secret tokens of 2FA-apps. In order to backup existing app-internal data you either need to use the per-app-backup that the creators of that app did hopefully include or hope that the allowed to do adb backup. That can be used without root, but depending on your Android, apps either need to allow this explicitly or at least not explicitly disallow that in their manifest file.
In principle you can use exploits for non-official rooting to backup existing data that is blocked from adb backup - but this is only an option if you do not have the latest security updates in place and an exploit is publicly available.