Latest end-user Omnirom 4.4.2 for the LG P500 can be found here:
http://jenkins.androidarmv6.org/job.../archive/omni-4.4.2-20140214-p500-NIGHTLY.zip
I am starting this to stimulate interest in the Omnirom, get/give advice and help on how to get it working on our device. My hope is that one of the devs would take this over and move from a discussion to a dev thread if need be. I can really offer no help at this point as I have not yet gotten this installed and running.
Another reason to start this is to keep from less than courtiously cluttering other threads with this stuff.
Finally, cm-11 for our device is quite problematic so I seek another Kitkat chocolate treat
==================================
Omni has two big problems holding up a working install on our device:
1. Omni is not rooted by default. I tried flashing a superuser.zip, still had no root. I have copied a full cm-11 su (binary) to the zip, tried that but installation was aborted for other reasons so could not yet test this approach. Please, devs, give us normal root in this ROM. Not so useful without it.
2. No adb until boot completed and I approve it. Great idea for security, but this thing is still experimental. So I cannot ride herd on the installation as I am accustomed nor run a certain script that I need from later cm10.* and cm11. As it turns out, Omni will run the script, cm11 would not. However, once I have attempted an Omni boot, I cannot get adb back outside of that successful boot until I restore another ROM! Means no adb reboot, adb reboot recovery, nada. Makes things very very problematic.
Omni will run my /data/local/userinit.d/ scripts which recent cm10.* and cm11 refuse. I always ran ICS this way, and I could presumably get a complete startup sans boot this way. To try this next--caution: Kitkat Link2sd mount script is not identical to previous ones so this must be placed to try this. Using the older version (maybe newer one as well!), everything simply FCs out, get nowhere. Link2sd needs root the create the script normally, Xposed needs root to get going, and Titanium and other tools are more useful with root as well. Lack of root is the main problem right now. Please ...
==========================
The usual disclaimer: If you have rooted your device, the warantee is void. Of course, for this oldie but goodie, that is just a distant memory. However, these phones are still being sold so if you got a new one, be warned.
I can not be responsible for brickage and breakage. Especially without that always active adb umbillical, it is much easier to soft-brick the device and it can get hairy-scarey getting back to recovery. Again, be warned.
The recent JB and KitKat ROMs are too large for our devices and must be trimmed before installation. My philosophy is that anything not needed to get Android up and running does not belong on system. Practically, anything installable from Play or side-loadable as user apps should be removed from system/app. Examples are Calendar (install Play version), calculator, camera/gallery, browsers, emailers and such. There are superior choices on Play or side-load those included with the ROM. If using Google Search, also remove the quicksearchbox. system/usr/srec, system speech recognition config, can be pushed to sdext and symlinked from there, freeing a good few meg. You do not need a lot but do need a few meg free on system.
Link2sd or equivalant is needed to keep data space available. Things get flakey when data space gets too low. Gluttonous apps like the newer Swype and Tapatalk (just a few examples--great apps, do not get me wrong) will very quickly run you out of data space and gobble up too much RAM as well, slowing the works. Choose wisely
So here is my next trial:
BACKUP!
Make sure no old 11link2sd script is on /data/local/userinit.d/
Wiped dalvik-cache, restored the sdext from the backup since the CWM seems to wipe this as well.
Wiped cache partition (actually, no longer used for very much!).
Installed the omni nightly which formats /system and proceeds.
Installed the minimal GAPPSlight.zip.
Reboot.
Came up just fine. First asks to enable adb for this computer, said "yes," "always for this computer."
Adb now active and adb, in any event, adb does have root!
Went to link2sd. Cannot get root. Went through all the setup options (including root for apps and abd!). Still not root.
So copied a new 11link2sd to /data/local/userinit.d/
Power menu advanced reboot active in setting and it actually works, avoiding above-mentioned fears
Rebooted.
Bootup runs all my scripts so now have all the link2sd-linked apps.
I could call this a BUG: It neither re-asks the adb question nor places it online. So ... no more abd
Still no root -- tried to activate exposed which without root will not do anything.
Rebooted anyway.
Came up just fine, as before. No root, no Xposed, Still no abd.
Comments:
Otherwise, works just fine, seems responsive. If I were willing to live without root, I could go on with it as a daily driver. Next trial, I will not check "always for this computer." Maybe then it will re-ask me and so re-enable abd.
Shares with cm-11 the flash of a disabled homescreen before the lockscreen. Harmless (as long as it is very brief).
Shares with cm-11 the "upgrading ... restarting apps ..." message on each reboot. Harmless, as long as linked apps, dexes are not being unlinked. Did not check, but cm-11 was no longer do that with the newest link2sd version.
The screen begins to turn off much more quickly. In cm-11, this took a good few minutes, eating the battery as it went.
Background processes came up more quickly (subjective) than cm-11, even though some lacked root to function correctly.
Did not really check if it shares the dissappearing data space problem which for many is a showstopper in cm-11. Initial space seemed appropriate, not half of expected amount. Without adb, can be checked using the SLW storage widget. I should really have done this.
Root remains the main problem with this. Neither flashing a superuser nor placing a full cm-11 su on the ROM enable root. Someone know how?
Attempts at getting root:
The recommended way is to flash SuperSU's zip (available from their XDA thread, surprisingly, not from Play). Since flashing this has twice bricked me up, I am loath to try that once more.
First attempt was the create an init.d type script to start the su daemon. I had placed a Cm-11 su on the ROM's zip before flashing. Voile, manually running that script from adb got me root. The command on adb shell hung up but it had run. Link2sd made its mount script (of which I have my own copy so whatever ...), even accepting the previous approval!
So I placed it on /data/local/userinit.d/ with all my others. On reboot, daemon was indeed running. Tried to activate Xposed. Attempts hung up, then failed. Running superuser (installed from Play as user app, symlinked) would FC. Noticed that I had multiple incidences of the su running which might be indicative of something!
So went back to recovery, removed my script, and flashed the CMW superuser.zip. On reboot, daemon was running. However, any attempt to use superuser FC'd. Removed the apk from system/app, rebooted to regain use of my installed version. Same result.
This issue of root needs be properly resolved to use this ROM.
So back to recovery and cm-10.2 which meanwhile may well be the optimal ROM for this device!
BTW: If the always for this computer was not checked on giving adb permission, after reboot and after a while, the question will be re-asked and one can get adb once again which is good new, though a bit less convenient.
This omni ROM from my humble opinion is quite bizarre and funny. What's really the intention to release ROM that need rooted device to install it (need recovery so first device must be rooted), but then rooted apps didn't work since no SU installed .
Sorry omni devs and anyone. No offence. Just express my opinion.
I tried Superuser.apk and SU from xda but failed.
Sent from my Optimus One using xda app-developers app
Some things I'd like to ask/share
1. My play store isn't working. I've trimmed the ROM n installed gapps too n installed play services too. Bt when i open play store, it works fine. But i can only see spinner loading under 'My Apps' n when I install any app, it gives fc. Then i have to clear data to open it again. What to do? Is it something to do with dpi? Because I've changed the dpi.
2. How to change tiles? I can't get its settings.
3. Any other int2ext script working?
4. Screen record has a very low fps and after recording, the phone becomes unusable. Have to restart
5. I found this ROM more snappy than any other CM11. Thanks to performance controls. Its awesome!
6. Only if root worked, this would be the BEST KitKat ROM for our phone.
(I'm trying to fix it too)
This ROM can be used aa a daily driver if u don't use much apps and root isn't a big issue. Great work
:thumbup:
EDIT:
Link for root in Omni ROM:
http://forum.xda-developers.com/showpost.php?p=50863602
Sent from my LG-P500 using XDA Premium 4 mobile app
Tried again to get root:
I can, in adb shell, su --daemon.
This gets me root for this session. Link2sd will create its mount script!
Rebooted. Thought that the root could be magically persistent as someone posted on some thread somewhere (did a lot of searching! and there were two instances the last time when I used a init.d script to do this). It was not so did su --daemon. Tried to use Xposed. Chugged a while, permission denied. CWM superuser's UI does not work on cm-11, not on this either. But it did not FC!
So I adb pushed SuperSU to system (I have enough room!). It wanted to install its binary. So I rebooted into recovery and flashed that.
On reboot, the su daemon was indeed running It has an 'R' instead of an 'S' on the column before its name. SuperSU also had a process running so thought hey, OK (and it did not brick the phone this time!). Tried to run Xposed. Simply sat there. Tried to run SuperSU, said it needed its binary and could not install it. Yuk! Never did like this app. On cm-10.2, even if CWM superuser wants a new binary, its UI will work anyway. Tried to run that. FC this time.
I never did check free data space.This after several successful reboots with no alarms about it. Overlayed the SLW widget onto link2sd and ran it. Only had 20meg. Fact is I had never ran link2sd to clean up dalvik and such so tried it now. Relink all apps simply chugged along. This can take time, even if it reports nothing to do! Finally lost patience with it but could not kill link2sd with back key (My fault? Options do not take effect until setting run, even if they were checked, it seems). Have to consider the possibility that the "disappearing data space" bug may be in this ROM as well as cm-11 (which, if so, would place it in the AOSP code!). No real way to check it without working root so everything plays.
Rebooted recovery, back to cm-10.2. BTW: the su daemon here has the 'S'.
rhar**** said:
Some things I'd like to ask/share
1. My play store isn't working. I've trimmed the ROM n installed gapps too n installed play services too. Bt when i open play store, it works fine. But i can only see spinner loading under 'My Apps' n when I install any app, it gives fc. Then i have to clear data to open it again. What to do? Is it something to do with dpi? Because I've changed the dpi.
Click to expand...
Click to collapse
Don't know. I only change DPI using Xposed which has not been enabled yet
2. How to change tiles? I can't get its settings.
Click to expand...
Click to collapse
I assume you mean those on the right-side pulldown. Have not found the interface either. Toggle to get that and enough of them are there.
3. Any other int2ext script working?
Click to expand...
Click to collapse
Need root. I did get link2sd to create it mount script after su --daemon.
4. Screen record has a very low fps and after recording, the phone becomes unusable. Have to restart
Click to expand...
Click to collapse
Never tried it. May also be DPI related?
5. I found this ROM more snappy than any other CM11. Thanks to performance controls. Its awesome!
6. Only if root worked, this would be the BEST KitKat ROM for our phone.
(I'm trying to fix it too)
This ROM can be used aa a daily driver if u don't use much apps and root isn't a big issue. Great work
:thumbup:
Click to expand...
Click to collapse
Yeah. Since I can get link2sd mounts either by running the daemon once or placing my copy, I have all my apps available (root ones will not be very happy). I used Xposed and need one round of root for this but that, as opposed to link2sd, did not work.
I have to admit that I do not know much about how su works. But the same su file is present in /system/xbin and is listed in file_contexts. SU.apk or supersu.apk have not been included in /system/app for at least cm10.1+.
Sent from my LG-P509 using Tapatalk 2
ibub said:
I have to admit that I do not know much about how su works. But the same su file is present in /system/xbin and is listed in file_contexts. SU.apk or supersu.apk have not been included in /system/app for at least cm10.1+.
Sent from my LG-P509 using Tapatalk 2
Click to expand...
Click to collapse
Is that su in /system/xbin is binary command to get root access on system file? You must run this command in terminal. However, Terminal.apk only can be launched if SU.apk or Superuser.apk present in /system/app.
So, in my opinion SU or Superuser is needed to run rooted apps (such as TB, Link2SD). Maybe Busybox is required too?
Sent from my Optimus One using xda app-developers app
ibub said:
I have to admit that I do not know much about how su works. But the same su file is present in /system/xbin and is listed in file_contexts. SU.apk or supersu.apk have not been included in /system/app for at least cm10.1+. :confused
Click to expand...
Click to collapse
System/xbin/su is the binary. One included on the ROM is tiny, barebones (no root). I replaced it with one from cm-11. When it is working right, I believe this gives you the dialog: Allow-Deny, Now-10min-always and such. It also has a daemon mode which services root access. I have not gotten the dialog on the Omni after manually starting the daemon.
That daemon needs be started early-on. Even an init.d script may not be good enough (Omni has real init.d capability as opposed to cm-11!). There is a "persistant-root" item in cm-11's build.prop. Maybe this will work here too the with cm-11 binary?
The apk is a user installable app (or gets placed on system by flashing zip). This gives access to the application-by-application permissions granted or denied in the above dialog, enabling changing them. SuperSU offers the most alternatives but is the most ticklish. CWM superuser is simpler, less finicky but seems not to work on 4.4.*. This is part of the problem. On cm-11, I have root, have the above dialog, superuser does not FC but no UI. On the Omni, since root was achieve manually after-the-boot, more problematic.
There are other apks around, superuser-elite, paid versions, etc. They are not exclusive--I had three of them around until I removed them and kept CWM. Any one of them good on cm-11? Should!!! work here too, he-he. The apk is not necessary to service root (i.e. mine is link2sd-symlinked and before link2sd gets its root, no mount script so no app seen).
xu3sno said:
Is that su in /system/xbin is binary command to get root access on system file? You must run this command in terminal. However, Terminal.apk only can be launched if SU.apk or Superuser.apk present in /system/app.
So, in my opinion SU or Superuser is needed to run rooted apps (such as TB, Link2SD). Maybe Busybox is required too?
Click to expand...
Click to collapse
Busybox is there, we do not have gnutls like normal distros--most everything goes through included busybox.
Terminal will work without the apk on /system/app. Cannot judge from the Omni because of no or incorrect root
I just learned a new set of tricks.
[email protected]:/ $ su -h
Usage: su [options] [--] [-] [LOGIN] [--] [args...]
Options:
-c, --command COMMAND pass COMMAND to the invoked shell
-h, --help display this help message and exit
-, -l, --login pretend the shell to be a login shell
-m, -p,
--preserve-environment do not change environment variables
-s, --shell SHELL use SHELL instead of the default /system/bin/sh
-v, --version display version number and exit
-V display version code and exit,
this is used almost exclusively by Superuser.apk
[email protected]:/ $
Sent from my LG-P509 using Tapatalk 2
ibub said:
I just learned a new set of tricks.
[email protected]:/ $ su -h
Usage: su [options] [--] [-] [LOGIN] [--] [args...]
Options:
-c, --command COMMAND pass COMMAND to the invoked shell
-h, --help display this help message and exit
-, -l, --login pretend the shell to be a login shell
-m, -p,
--preserve-environment do not change environment variables
-s, --shell SHELL use SHELL instead of the default /system/bin/sh
-v, --version display version number and exit
-V display version code and exit,
this is used almost exclusively by Superuser.apk
Click to expand...
Click to collapse
Yes, this simply a root version of sh. The one on this ROM probably will not allow anything.
The one from cm-11 will check permissions, give the dialog to ask if root working correctly.
Latest build omni-4.4.2-20140227 is up, triggered by androidmeda :good:
http://jenkins.androidarmv6.org/job/omni/4/
Download here:
http://jenkins.androidarmv6.org/job/omni/4/artifact/archive/omni-4.4.2-20140227-p500-NIGHTLY.zip
Will try is that SU or Superuser included
EDIT:
Just flashed it with clean install.
1. System reboot took under 3 minutes :good:
2. su binary exist at /system/xbin but not link to busybox binary which is present also at /system/xbin.
3. Installed Terminal.apk, it works but denied to run su command line
4. Installed Root Explorer.apk, works fine but failed to access root, such to change permission R/W of /system folder.
5. Referring to 3 and 4, apps need root access failed to work.
6. Tried to install SuperSU flashable zip, it replaced su binary from stock and it caused apps which is need root access (in my case gooim manager, root explorer, and Link2SD) not responded and apps're getting hang
7. Installed Superuser, launched it, works but need su binary.
Do we need latest SuperSU or Superuser, hence su binary is compatible with Android 4.4.2 ?. The installed one is for Android 2 and 3.
xu3sno said:
Latest build omni-4.4.2-20140227 is up, triggered by androidmeda :good:
http://jenkins.androidarmv6.org/job/omni/4/
Download here:
http://jenkins.androidarmv6.org/job/omni/4/artifact/archive/omni-4.4.2-20140227-p500-NIGHTLY.zip
Click to expand...
Click to collapse
Do not know what has changed. There have been kernel merges, etc.
***
2. su binary exist at /system/xbin but not link to busybox binary which is present also at /system/xbin.
3. Installed Terminal.apk, it works but denied to run su command line
***
Click to expand...
Click to collapse
The /system/xbin/su included with this ROM is for no-root access allowed. A blocker.
I placed the su from a cm-11 ROM. This can run its daemon and get root access. Works for link2sd but nothing else (i.e. Xposed), apparently. According to some googled posts, that daemon must be started very early on (as I stated before). I had it in an init.d script. Started but had same negative results. May try the persist.sys.root_access=1 flag in build.prop. Maybe the internally buried code in boot.img will start the daemon as requested here (if it was not removed). There is no explicit script in the cm-11 ROMs to start that daemon.
i have got an idea. But where is the source?
is this the source?
If yes, then where is settings?
EDIT:
Ok got it. Editing
rhar**** said:
i have got an idea. But where is the source?
is this the source?
If yes, then where is settings?
EDIT:
Ok got it. Editing
Click to expand...
Click to collapse
Okay. Waiting for edited omni ROM (SuperSU included ?), as you did with cm-10.1.5-KITKAT-Update_3 :good:
Wish you luck
Sent from my SM-T311 using xda app-developers app
rhar**** said:
i have got an idea. But where is the source?
is this the source?
If yes, then where is settings?
EDIT:
Ok got it. Editing
Click to expand...
Click to collapse
Great. SuperSU itself is problematic but will suffer with it if it works. Would prefer generic like other ROMs.
Anyway, as in my OP, I would be looking for a dev to take this thread over as a dev thread (or open one).
Another OMNI build
Another Omni build is released @ Jenkins, triggered by Androidmeda.Can d'load it from : http://jenkins.androidarmv6.org/view/All/job/omni-experimental/12/
sumansur2008 said:
Another Omni build is released @ Jenkins, triggered by Androidmeda.Can d'load it from : http://jenkins.androidarmv6.org/view/All/job/omni-experimental/12/
Click to expand...
Click to collapse
Labeled for commits about boot animation.
Anyway, downloading.
Related
would have just asked in :
http://forum.xda-developers.com/showthread.php?t=1142872&page=67
but i don't have enough posts, and don't want to spam a bunch of useless "cool" posts to get my count up.
Anyways,I did every thing in that topic and have CM7 running fine on my Cell South Showcase. But, i don't seem to have root access superuser is there but seems to do nothing. i tried checking via the terminal with just a "su" command and got nothing. Tried Superoneclick (my go to rooter for awhile) and it just hangs at "looking for device" . and, Z4 seems to not work with 2.3.4 phones.
So is there any fix to this, or have i just hit some crazy bug?
I have seen some people allude to changing the kernel, but the last time i tried to upgrade/change the kernel on this phone i had to save it via odin
Don't you HAVE to be rooted in order to run cm7?
i know, it breaks all logic
i just know i cant grant superuser to anything, busybox installer says it isnt rooted, and Titanium cant do anything
thenumber5 said:
i know, it breaks all logic
i just know i cant grant superuser to anything, busybox installer says it isnt rooted, and Titanium cant do anything
Click to expand...
Click to collapse
Clear data on superuser app and/or uninstall/reinstall it.
Ah,I see.. yes, try above. If no. Maybe wipe and reflash?
ok cleared the data, did nothing
can you ever uninstall/reinstall superuser?
thenumber5 said:
ok cleared the data, did nothing
can you ever uninstall/reinstall superuser?
Click to expand...
Click to collapse
Yup just an app
Also:
i have already flashed via Odin back to stock once and did the whole CM7 flash again from a fully clean rom
ok, Flashed Superuser 3.0 beta 3
no go, says my SU binary is out of date, and the app crashes when it tries to update it
checked my bin and xbin, both have a "SU" file in them
in terminal when i CD in to both folders and try to run "SU" i get an error that looks like it is trying to relocate a library and failing to do so
Can i just download the new SU binary my self and manual drop it in to the folders?
well that didnt work, cant modify anything in the system folder so i cant delete that old "SU" and replace it with the one from the superuser 3.0 apk
LOL
well i got it to let me replace the SU in /bin but not in /xbin
so now i got some half confused phone, i can grate Superuser "superuser" but when it tries to update or do any thing the log says "gaining root access....fail"
i still dont know how i have have a CM7 phone that by it very nature is rooted that thinks it is not rooted
ok for anyone who cares, i just gave up flashed via odin back to stock and tried the MIUI port, worked great once i fangled MMS in to working again
I had a similar problem, at which point I grabbed stericson's busybox app from the market which allowed me to flash a working busybox which after a reboot or two and running the installer again fixed me up..there is an app called root checker that can give info on su, superuser.apk, and busybox installs
I am almost positive that when I used jrummys busybox installer our killed root access on my phone. I had superuser.apk but without busybox it was rather useless as no apps could get root. the fix was flashing busybox 1.19.0 and leaving it in xbin and letting the app do its thing once I had rebooted.. then I rebooted again and everything was fine! after bring rooted for so long I don't think I could function without it!
for others out there, my experience has been this: stay weary of the jrummy busybox installer...its never given me anything but problems...and honestly unless busybox is borked, or ya have a damn good reason to upgrade or downgrade my suggestion is to leave it! the potential problems that can arise (for me every time, using jrummy's version..3 times) can be a pain!
Sent from my SCH-I500 using XDA Premium App
i had the same issue but dont recall if it was CM7 that did it or not but i think it was.
i had to completely blow out the phone and start from scratch.
if i recall, CM7 uses a different version of SuperUser and it just want bonkers on me but completely blowing everything out reformatting and everything seemed to work.
If you're on CM7 already, you should be rooted. If not, try SuperOneClick (Google).
Hi Everyone
Because I'm lazy and was tired re-rooting manually my devices after installing manufacturers OTA updates, I wrote an app that protects root in one touch event.
It is available for free on Android market and its source code is Open Source under WTFPL (github).
Translations and code contributions are welcome.
Features: :
- Backup root before OTA & Restores it right after.
- Temporary un-root your device.
Requirements:
- Device must be already rooted.
- Protection is effective only for devices with Ext2/Ext3/Ext4 /system partition
- Non ExtFS devices will still be able to use the temporary un-root feature
OTA RootKeeper will detect what's possible or not and display available options accordingly.
Typically works for: Nexus S, Every Honeycomb tablets.
On ExtFS partition, root survives anything but true formating or partition wiping.
It means some update tools like KIES/Odin for Samsung device will wipe the whole thing anyway because they write complete new partition.
I needed this app so I wrote it, hopefully it will be useful to you too!
Android 4.3 Notes:
Based on Android 4.3 release notes, on Enterprise and Security, Restrict Setuid from Android Apps, su binaries and Superuser apps designed for previous Android generation will simply not work on 4.3:
Restrict Setuid from Android Apps
The /system partition is now mounted nosuid for zygote-spawned processes, preventing Android applications from executing setuid programs. This reduces root attack surface and likelihood of potential security vulnerabilities.
Click to expand...
Click to collapse
It means preserving root with OTA Root Keeper won't be possible anymore as new rooting techniques rely on more than just a setuid su binary in /system.
I'll look into solution of course to preserve the functionality if possible, but until then please follow Chainfire's job on SuperSU betas.
Aw, so its a no go on my sgs2..
Thanks for the amazing work as always anyways!
nanujra said:
Aw, so its a no go on my sgs2..
Thanks for the amazing work as always anyways!
Click to expand...
Click to collapse
You're welcome
On Galaxy S II, temporary unroot is working and allows you to "hide" root from stupid apps refusing to work as expected after detecting root.
Its not really hidden but so far, those stupid apps (like Google movies) use stupid detection routines.
Supercurio. do you think you can backup Superuser.apk too please. I can see where it needs to be done in github but I'm no expert in compiling apk. or Will apkmanager work for that and i Will have a go at that.
crypticc said:
Supercurio. do you think you can backup Superuser.apk too please. I can see where it needs to be done in github but I'm no expert in compiling apk. or Will apkmanager work for that and i Will have a go at that.
Click to expand...
Click to collapse
Why backup Superuser.apk?
If it's not installed, you already get automatically a button to access the market page automatically.
When you update your device via an OTA, Superuser.apk is not uninstalled.
Please describe your need
supercurio said:
Why backup Superuser.apk?
If it's not installed, you already get automatically a button to access the market page automatically.
When you update your device via an OTA, Superuser.apk is not uninstalled.
Please describe your need
Click to expand...
Click to collapse
Thanks for replying.
Busybox because is part of xbin and could be lost.
superuser apk because that would be a full unroot and reroot in one app. E.g. If I want to unroot during work hours and reroot after say if work sync calendar app doesn't like root.
Or do you think this will be a nice way to cut my teeth on android development? I see two java code places that seem to backup and then restore.
crypticc said:
Thanks for replying.
Busybox because is part of xbin and could be lost.
superuser apk because that would be a full unroot and reroot in one app. E.g. If I want to unroot during work hours and reroot after say if work sync calendar app doesn't like root.
Or do you think this will be a nice way to cut my teeth on android development? I see two java code places that seem to backup and then restore.
Click to expand...
Click to collapse
I never noticed an OTA that destroyed xbin directory? Do you have an example? (please show me the updater-script so I can study it)
Why I made this utility is because /system permissions are reset via recursive chmods during OTAs: what causes su binary to not be efficient anymore.
But saving files in not the main purpose. As long as you're rooted, you can re-install busybox in /system anyway.
Ah. I am thinking odin not ota
Ta
crypticc said:
Ah. I am thinking odin not ota
Ta
Click to expand...
Click to collapse
With Odin the whole partition is wiped, I can't backup/restore root − and as a result restore busybox either because it would require root to do so.
Any reason not to backup su to /data instead of /system? I've tried this on a Bionic and it works just fine. I tried this:
adb shell
su
cp -p /system/bin/su /data/su
rm /system/bin/su /system/xbin/su
exit - reboot phone
adb shell
/data/su
I'm root.
Seems like /data has a better chance of being untouched and as long as it's mounted correctly that copy of su will be there and executable.
crpeck said:
Any reason not to backup su to /data instead of /system? I've tried this on a Bionic and it works just fine. I tried this:
adb shell
su
cp -p /system/bin/su /data/su
rm /system/bin/su /system/xbin/su
exit - reboot phone
adb shell
/data/su
I'm root.
Seems like /data has a better chance of being untouched and as long as it's mounted correctly that copy of su will be there and executable.
Click to expand...
Click to collapse
Yes. Every Android device is supposed to mount /data with "nosuid" option, which makes su permissions inoperative.
The modded test device you used miss that; it's kind of a bug
thank you very much
as iran
Do you have to install this program after reverting to stock? Or can you install it in any custom rom before the OTA update?
matthskim said:
Do you have to install this program after reverting to stock? Or can you install it in any custom rom before the OTA update?
Click to expand...
Click to collapse
You need to install this app, make the su backup before applying your OTA.
Then, the app will be able to restore su.
If it's an OTA, this app and Superuser apk will still be installed after applying it.
Do you need to revert to stock or not before applying an update? That I don't know; depends.
Wow, this may be the app I have been looking for. I have an app for work that will not work if it detects root. Really would like to keep my phone rooted as some apps I have require it, such as Titanium Backup (which I love). I am going to give this a shot tomorrow and see if this works for me.
you are a god send
Thanks a lot, great app, works on Asus TF101 !
Faher said:
Thanks a lot, great app, works on Asus TF101 !
Click to expand...
Click to collapse
Hehe yes I saw there's an OTA for Transformer ATM
Thank you!
Playing Rented Movies that you rent from the Android Market WORK AROUND confirmed working!
Playing UltraViolet Digital Copy Movies in the Movies aka Flixster App WORK AROUND confirmed working!
pocket BLU WORK AROUND NOT confirmed working Yet! If you try it let me know
jangst123 said:
Thank you!
Playing Rented Movies that you rent from the Android Market WORK AROUND confirmed working!
Playing UltraViolet Digital Copy Movies in the Movies aka Flixster App WORK AROUND confirmed working!
pocket BLU WORK AROUND NOT confirmed working Yet! If you try it let me know
Click to expand...
Click to collapse
Thanks for the feedback about the "plus" feature which is not the main aka temporary un-root
How to test pocket BLU?
I'll try to keep this as short and simple as possible:
I am a total newb to the touchscreen, smart-phone, I just got a USCC Samsung Mesmerize SCH-i500, came installed w/ 2.3.4 Gingerbread & I just had to reflash it w/ USCC EH09 root using Odin 3 v1.85, now, everything I have "hacked" in the past (PSP (both fat & slim), iPod Touch, etc) I've always had to use step-by-step instructions (I am not a dev & know absolutely nothing about programming) & the same applies here.
So, it has root access & BusyBox (I don't even know what that is) installed, so my question is what was the point?
What exactly can/should I do from here? Any suggestions?
well, with a rooted android device you can
*remove bloatware (you're wasting your root if you don't do this)
*system-wide adblock (my personal fav)
*change boot animations
*flash custom ROM
*free wifi tethering
*overclock the CPU
and more!
Thank you for the answer, I'll look into these things but on a side note: my su app keeps saying that theres an update available for my su binary & every time I tap update it goes through the process & less than half-way through it pops up a message saying: "This updater cannot update the su binary on phones that have some kind of write protection on the system partition like S-ON. You can continue to use Superuser with your outdated binary, or update su with ROM Manager."
I have tried to use ROM Manager, I even bought the Premium version, either way it gives me the same message, even after doing the Fix Permissions option, is there a way to manually allow su access to the files it needs to overwrite/update?
Oh, and, yes, I have allowed it when su asked, so now I'm at a loss....
Xeno Templar said:
Thank you for the answer, I'll look into these things but on a side note: my su app keeps saying that theres an update available for my su binary & every time I tap update it goes through the process & less than half-way through it pops up a message saying: "This updater cannot update the su binary on phones that have some kind of write protection on the system partition like S-ON. You can continue to use Superuser with your outdated binary, or update su with ROM Manager."
I have tried to use ROM Manager, I even bought the Premium version, either way it gives me the same message, even after doing the Fix Permissions option, is there a way to manually allow su access to the files it needs to overwrite/update?
Oh, and, yes, I have allowed it when su asked, so now I'm at a loss....
Click to expand...
Click to collapse
I had the same issue today, couldn't update SU.
but after I had updated the terminal emulator, I was able to update SU.
Fixed the Problem with updating SU Binary
Recently updated my device with a new rom and was unpleasantly surprised to not be able to update my SU binary with either the application itself or CWM. I am not sure that this is the best way to handle the problem, but I found a solution that worked for me.
1. Open "System/XBin" in RootExplorer (or a similar app)
2. Mount the drive as R/W using the button up at the top left
3. Open the superuser app and update the binary from within the app
4. There may be an error in the log about the device not being able to remount the drive properly, but the update WILL occur.
5. Use RootExplorer to open the directory again and mount as R/O.
I hope this helps!
This IS working for 4.3+ using xposed module.
http://forum.xda-developers.com/showpost.php?p=49878296&postcount=679
All credit goes to Phantasm4489. I am only adding the the OP so people can find it.
Below can be used for anything below 4.2 but I still think the xposed module above is better.
Standard Disclaimer:
**************************************************************************************************************
I AM NOT RESPONSIBLE FOR YOU BEING FIRED BY CIRCUMVENTING THE POLICY YOUR IT STAFF HAS PUT IN PLACE. I AM NOT RESPONSIBLE FOR BRICKING YOUR PHONE (ALTHOUGH SERIOUSLY DOUBT IT COULD POSSIBLY DO THAT). I AM NOT RESPONSIBLE FOR ANY DAMAGE WHAT SO EVER. THIS IS FOR EDUCATIONAL PURPOSES ONLY!!
**************************************************************************************************************
Click to expand...
Click to collapse
First off:
THANKS to sparky for the 'su' binary I use in my newer scripts.
THANKS to chainfire for the 'su' binary I use in my older scripts.
THANKS to Fallon for helping fine tuning the directions.
This thread is dedicated to using GFE on rooted devices. My intent is to understand root detection schemes for my own personal education. If the information here is beneficial to others, then that is a plus.
I came up with a process that satisfies both GFE and its use on rooted (technically temp unrooted) devices. Basically unrooting and rerooting the phone so that the GFE app functions and I comply with not running GFE on a rooted phone. .
Tested on CM9 and CM10 for the Epic 4 Touch and the Galaxy S3. I've seen success on other ROMS as well. If you run into issues, i'd be happy to help and improve the process.
What GOOD(GFE) detects and what it doesn't care about
Some key notes about what GFE seems to detect:
Detects 'su' anyplace on the phone /system partition (usually located in /system/bin/su or /system/xbin/su).
Detects the superuser apk and supersu apk
Detects if you have su'd in adb or shell while it is running. Close adb and log out of and shells before launch!
If you use a root tool like titanium, reboot before launching good! Titanium will sometimes leave open rooted processes running.
In pre-JB, it could use the READ_LOGS android permission to comb the system logs and find 'root like 'activity'. In JB, that 'security hole' is closed and that permission is locked down by android.
It detects if /system is RW.
The software is setup to never be shutdown. Once its started, it runs no matter what. Preventing it from starting is a good thing IMHO.
Seems that for some unknown reason, if es explorer was run in root mode at any point before running good, it detects root. Even if I manually kill all the back ground processes before unfreezing/launching Good.
Sometimes I get a compliance failed when I was working in ADB prior to running good. Typically if I was in ADB doing root work, i'll reboot the ROM before enabling good.
Turn off 'automatic update' for super user app from market
What GFE does not seem to care about:
busybox
CWM
locked/unlocked bootloaders
Here is how to make root and GFE play as nice as possible. This isn't perfect but it works pretty good. I still get the 'compliance failed' once in a while when i do something dumb. I am lucky in that I can clear data on the GFE app and reuse the prior key or request a new key from our IT system on demand. If you cannot do this easily, then this may be cumbersome. As we further progress this, we should get less and less lockouts.
SCRIPTED PROCESS
Downloads:
Something to run the scripts One of these will do:
- Connectbot or any shell execution program from play store. connectbot has widgets. I use connectbot.... - Script Manager found here: http://db.tt/Vonx78NI . Or playstore.
(required for PRE-JB roms only). Install Permissions Denied from the Market
The latest cwm/twrp flashable zip attached to this OP.
An installation of busybox. Typically comes with CM and lots of other ROMs but just making the point here that it is required.
Setup app and dependencies:
Flash the gfe_workaround_setup zip attached to this OP in CWM. This will create four scripts and a "backdoor" su binary. They are as follows:
/system/xbin/dger
/system/xbin/egdr
/system/xbin/fu. (The sparkysu binary is insecure so be careful out there! Just a disclaimer)
/system/xbin/r_dger
/system/xbin/r_egdr
Install Good Application
If pre-JB (NOT REQUIRED ON JB+), open Permissions Denied and disable the READ_LOGS permission for the Good Application. Immediately after disabling that permission reboot the device from within the Permissions Denied app (in the menu). It must be done from within the application immediately after toggling the permissions to denied.
Optional but recommended: use "autostarts app" (or similar) from market to turn off all autostarting flags for Good app. This is incase you forget to disable root before you reboot and dont want it to start after again after flashing a rom which would restore root..
Use Connectbot or old script manager to execute the enable/disable scripts.
HOW TO Use the scripts and run the Good.
These scripts will basically temp unroot your phone and disable the superuser user whenever you want to run good. It will reverse the operation whenever you want to return root and lockup good.
I typically leave good disabled unless I am using it but that is up to you.
Whenever you want to 'run good'. You will run the script egdr.
Whenever you want to disable good and return root to your phone run dger (prior to reboot for example or flashing roms or whatever)
DO NOT FORGET TO run the DGER script before flashing a rom since that rom will repush superuser and su and if good was enabled when you shutdown to reflash the rom, good will detect root and deactivate the handheld. Also since I disable the superuser user entirely when you flash the new rom, you will lose root and will need to enable the superuser user and reflash the rom to fix things... You can always just fix it with adb but renabling superuser... But that is a pain.
(pre-JB only) Permissions Denied takes FOREVER to startup, several minutes at least & you repeatidly see it getting root permissions, at first I thought it was having issues but that is how it works.
No need to "Lock Permissions" within the Permissions Denied app from what I've seen but ymmv
Under the ROM Developer Options "Root access" is irrelevant, GFE is working just fine with it set to "Apps and ADB right now"
GFE will work fine by wiping app data & initilizing it with a new PIN if you get things cleaned up after a policy violation
No need to get an unlock code from your sysadmins after a policy violation, just wipe app data for GFE & get a new PIN (assuming you have access to a website to request a new PIN
A mini-how to for connectbot:
I prefer this because connectbot is a simple tool and I like to keep it simple. But you may prefer the script manager interface instead.
With connectbot, you can create 2 'local' connections. One for each of the enable/disable scripts appropriately named. You can edit each of the local connections and setup 'post-login automation'. In the post-login automation you add the following (Note that <enter> means to put a line feed... i.e. hit enter ):
Code:
/system/xbin/dger;exit
<enter>
Code:
/system/xbin/egdr;exit
<enter>
You can either open connectbot each time and run the enable or disable scripts or you can add connectbot shortcuts to each local connection on your launcher's desktop. Its under 'add shortcut' you will see connectbot.
If you, like me, get annoyed by the notification icon from connectbot, you can optionally do these steps to execute it.
In the connectbot options, disable persistence. Also you can replace the ';exit' in the post automation commands with ';kill $PPID' and that will get you very close a self closing command. That will terminate the shell session you are in. When disabling GFE you'll still have to hit the back button but when enabling GFE it wont stay in your notification bar.
Example:
Code:
/system/xbin/dger;kill $PPID
<enter>
The negative is that if there was an issue, you wont see the log. I may add logging support in the scripts so that we can go back and look easier anyway at what failed if we get a lock out. If you ever needed to debug though just remove that temporarily and you'll see the log again.
If you wanted a few seconds to review the log, you could do something like this also:
Code:
/system/xbin/dger;[COLOR="Red"]sleep 5[/COLOR];kill $PPID
<enter>
A mini-how to for script manager:
In script manager you will add the scripts into script manager and execute them via the app or it's widgets. The scripts should NOT be setup to run as superuser but they still will prompt for super user when the disable one is actually executed and you should respond GRANT to that request. You will use the app to find the scripts in /system/xbin chosing the following:
Code:
/system/xbin/dger
Code:
/system/xbin/egdr
FAQ
Q: If I am going to dirty flash a new rom (no data wipe), What do I need to do to keep GOOD in compliance?
A: IT'S LIKE DANCING AROUND A LAND MINE! You will want to follow this process before and after flashing dirty:
Run dger to return root to your device and disable GOOD
Reboot into cwm
Flash rom and do any other rom specific instructions including any reboots or whatever the rom maintainer wants you to do.
Reflash the gfe_workaround zip from the op since flashing the rom overwrites it.
Boot into the rom and set it up as you like with root...
Run disable good enable root.sh to make sure things are well after rom flash.
reboot one last time
use scripts as normal
Q: If I am going to clean flash a new rom (wipe data), What do I need to do to keep GOOD in compliance?
A: Clean Flashing will require you to restore the good app or jsut reactivate it. You can likely avoid reactivation by following this. YMMV
Run dger to return root to your device and disable GOOD
Use Titanium Backup (or similar like carbon) to backup the GOOD app and data.
Reboot into cwm
Flash rom and do any other rom specific instructions including any reboots, wiping data/system or whatever\ the rom maintener wants you to do.
Reflash the gfe_workaround zip from the op since flashing the rom overwrites it.
Boot into the rom and set it up as you like with root...
Restore GOOD with Titanium. You may need to also restore your android ID with titanium as I am not sure if it hashes that ID with activation credentials.
Immediately run dger BEFORE REBOOTING to make sure things are well after rom flash.
Ensure you redisable any permissions denied things and autostarts.
reboot one last time
use scripts as normal
DEBUGGING PROCESS
So you've experienced a policy break/lockout? Now what?? This is how you can debug and give me what I need to help you if required:
flash newest scripts in OP and boot up and let it settle.
run the disable good script.
run enable good script.
run disable good script again.
That will create log files in /sdcard/ with the same names as the scripts. You can review those or submit them to me in this thread and I can look. I will also need the following. I review these files to see if there are any 'other' superuser or supersu apks that my scripts have missed. I will need the /sdcard/gfe.txt after you run the below to assist posted in the thread.
Run the following commands in a connectbot shell after above:
Code:
Code:
su
find /system/app /data/app /system/bin /system/xbin|sort > /sdcard/gfe.txt
pm list packages >> /sdcard/gfe.txt
Then give me these following logs:
/sdcard/gfe.txt
/sdcard/egdr.......log
/sdcard/dger.......log
Some of the most common reasons for lockouts are because of the running of certain root apps prior to enabling good. Certain root apps still retain root access after you close them. Notably es explorer and titanium. I'm sure there are others but this is two that I know of. If you use those tools either disable root access in them if applicable or reboot before running good after using them.
Change log
04-20-2013 (v16):
Renamed scripts and binary
04-03-2013 (v16):
Added "script complete" messages to output.
04-02-2013 (v15):
Added command line option to turn off auto-launch of GFE. The default will remain to auto-launch it.
04-01-2013 (v14):
Went back to sparky su as other su is causing too many anomolies.
FAQ added to OP.
02-26-2013 (v13):
Removed execution speed enhancement introduced in v11 as it caused some issues.
02-22-2013 (v12):
Further improved Logging to sdcards
Added some enhancements and termination of some root apps(titanium)
02-14-2013 (v11):
Improved script execution speed by parallelizing some operations
Added logging to /sdcard if available
02-04-2013 (v10):
Changed the way I handled superuser apps (or multiples) stored in data and system.
Added ability to handle chainfire's nonag apk in addition to regular supersu.
Started using supersu's su for a more secure setup.
Revamped directions and cleared up some errors in the OP.
01-29-2013 (v9):
added new mask for apk
added error handling for mounts incase.
01-25-2013 (v8):
reversed order of hiding apks between system/data to resolve
issue of supersu/superuser "forgetting" settings when rerooting.
12-18-2012 (v6):
added supersu support
fixed left over apks from super app upgrades
12-14-2012 (v3):
Added clean exit commands.
12-13-2012 (v2):
- Discovery that new script manager may cause compliance issues and doesn't work after temp unrooting!
12-12-2012 (v1):
- Fixed bugs
- Automated variables
- Created flashable setup script
- Simplified the install process
12-10-2012 ():
- Initial design
The 'manual' process may not work anymore. I believe supersu apks are getting picked up for compliance. There are a few more manual ways listed in this thread that may or may not work for you but you are welcome to try them.
MANUAL PROCESS
If the script process is too complicated for you and you want to do things manually, you can do this as well. It is a pain though and more prone to getting the handheld disabled by good because of user error (forgetting to do something).
The key to this way is that gfe doesnt appear to detect supersu apk and does detect superuser apk. Not sure how long this will last! ymmv
You can install supersu, open it and let it authorize. Then rename /system/app/Superuser.apk to super_user.rob since its not needed anymore and let supersu do the authorizations.
Then install "app quarantine" from the market or titanium backup. These apps let you freeze and unfreeze the gfe app so you can bounce between a rooted and unrooted phone. (hint: there are widgets for this in titanium and app quarantine that are much more convenient)
If pre_JB, Install "permissions denied" (in app store) to remove the some of the permissions from the app. specifically you must remove
READ_LOGS
The process is as follows once the above is complete and gfe is installed and you want to use gfe:
FROST GFE(reroot)
open gfe and go into preferences and select "disconnect" and then select shutdown good. VERY IMPORTANT TO DISCONNECT AND SHUTDOWN from within the GOOD app. Do NOT just hit the 'HOME' button and reroot. It WILL detect that it has been frosted and unfrosted if you do not follow this advice
immediately open supersu app and go to settings and select "enable supersu" to reenable root.
open app quarantine (or titanium) and freeze good so it won't autostart.
You can now use the rooted phone like normal.
when you want to use gfe, temp unroot as follows:
UNFROST GFE(temp unroot)
using titanium or app quarantine defrost gfe.
immediately open supersu and go to settings and uncheck "enable supersu". the will hide the su binary and temp unroot.
open gfe and use it like normal.
once done using gfe, refrost it like above
this works very well but ymmv. The scripted method works much better.
Finally had success getting GFE running a recent CM10 nightly on my AT&T SGS3 thanks to calisro. Thanks for figuring out a good work around to enable GFE! It looks like my issues this go around were with Permissions Denied & me doing some uninstall-re-install of GFE.
My process (tweaks to calisro's stuff mostly):
Uninstalled ES explorer (just to make sure it is not causing issues for now)
Installed GFE
Installed Script Manager (I've since upgraded to Script Manager-SManager(NoAds), always a good idea to support the devs)
Installed Permissions Denied
Installed su as /sdcard/rob_su
Opened Permissions Denied and disabled the following permission for the Good Application: READ_LOGS and RECEIVE_BOOT_COMPLETED
Rebooted from within Permissions Denied, checked & verified Good had the 2 permissions in question denied
Created the 3 scripts using the updated versions recently posted
setup_rootdoor.sh
enable_good_disable_root.sh (complete with the missing final line noted above)
disable_good_enable_root.sh
With Script Manager, ran setup_rootdoor.sh
Deleted all data for GFE through app manager
With Script Manager, ran enable_good_disable_root.sh
Activated GFE
Working GFE
Notes:
Permissions Denied takes FOREVER to startup, several minutes at least & you repeatedly see it getting root permissions, at first I thought it was having issues, but I guess that's normal behavior
No need to "Lock Permissions" within the Permissions Denied app from what I've seen
Under Developer Options "Root access" is irrelevant, GFE is working just fine with it set to "Apps and ADB right now"
GFE seems to be sucessfully cleaned up by deleting app data from within app manager
GFE will work fine by wiping app data & initializing it with a new PIN if you get things cleaned up after a policy violation
No need to get an unlock code from your sysadmins after a policy violation, just wipe app data for GFE & get a new PIN (assuming you have access to a website to request a new PIN
Logs & thoughts from of my previous failures & troubleshooting steps http://forum.xda-developers.com/showpost.php?p=33025295&postcount=5
Fallon said:
Finally had success getting GFE running a recent CM10 nightly on my AT&T SGS3 thanks to calisro. Thanks for figuring out a good work around to enable GFE! It looks like my issues this go around were with Permissions Denied & me doing some uninstall-re-install of GFE.
My process (tweaks to calisro's stuff mostly):
Uninstalled ES explorer (just to make sure it is not causing issues for now)
Installed GFE
Installed Script Manager (I've since upgraded to Script Manager-SManager(NoAds), always a good idea to support the devs)
Installed Permissions Denied
Installed su as /sdcard/rob_su
Opened Permissions Denied and disabled the following permission for the Good Application: READ_LOGS and RECEIVE_BOOT_COMPLETED
Rebooted from within Permissions Denied, checked & verified Good had the 2 permissions in question denied
Created the 3 scripts using the updated versions recently posted
setup_rootdoor.sh
enable_good_disable_root.sh (complete with the missing final line noted above)
disable_good_enable_root.sh
With Script Manager, ran setup_rootdoor.sh
Deleted all data for GFE through app manager
With Script Manager, ran enable_good_disable_root.sh
Activated GFE
Working GFE
Notes:
Permissions Denied takes FOREVER to startup, several minutes at least & you repeatedly see it getting root permissions, at first I thought it was having issues, but I guess that's normal behavior
No need to "Lock Permissions" within the Permissions Denied app from what I've seen
Under Developer Options "Root access" is irrelevant, GFE is working just fine with it set to "Apps and ADB right now"
GFE seems to be sucessfully cleaned up by deleting app data from within app manager
GFE will work fine by wiping app data & initializing it with a new PIN if you get things cleaned up after a policy violation
No need to get an unlock code from your sysadmins after a policy violation, just wipe app data for GFE & get a new PIN (assuming you have access to a website to request a new PIN
Logs & thoughts from of my previous failures & troubleshooting steps http://forum.xda-developers.com/showpost.php?p=33025295&postcount=5
Click to expand...
Click to collapse
FYI, I simplified the install with a flashable zip and some modifications to the scripts so that the work they do is dynamic rather than hard coded.
Discovered that the new Script Manager is potentially causing policy compliance issues. See the op for alternative or older version of script manager.
calisro said:
Discovered that the new Script Manager is causing policy compliance issues. See the op for alternative or older version of script manager.
Click to expand...
Click to collapse
Does it only trip when you use it? I think I saw Script Manager update a couple days ago, but haven't had any problems yet. Then again I haven't needed to mess with SM at all since then or even engage root for anything since I got GFE working on CM10 a week or so ago.
I'm having it fail compliance by simply having it installed. I've gone through and upgraded, tested, downgraded, tested, etc for a number of times to be sure and it keeps tripping as soon as it is used once. I've even installed it,denied superuser for the app, then used connectbot to actually run the script and it still failed. As soon as I go back to older version it works flawlessly again.
I'll be interested if yours' trips when toggle root and good once again.
De easiest way to perform tasks that require root is to use chainfire's exynos exploit apk to acquire root and when you're done use supersu to unroot.
Make sure you stop de GFE service before rooting! I just did this and GFE really stops working as I rooted, cleaned up my new polish Note 2 4.1.2. rom, unrooted, booted and used GFE like before, no policy violations.
Whatever you do, do not boot before you unrooted.
blackspp said:
De easiest way to perform tasks that require root is to use chainfire's exynos exploit apk to acquire root and when you're done use supersu to unroot.
Make sure you stop de GFE service before rooting! I just did this and GFE really stops working as I rooted, cleaned up my new polish Note 2 4.1.2. rom, unrooted, booted and used GFE like before, no policy violations.
Whatever you do, do not boot before you unrooted.
Click to expand...
Click to collapse
I wouldn't call that the easiest but to each their own.
While that may work for some people for a short time, it doesn't address a lot of things:
1) Doesn't work with superuser since Good detects the superuser apk and doesn't detect supersu yet. Detection of supersu will be added to Good at some point since its use is being coming more prevalent.
2) That exploit will be addressed soon since it affects millions of hand sets. Samsung will close the exploit and AOSP/AOKP will also address the exploit. So it will be useful for a short time only.
3) It only works for Samsung exynos based handsets only. My method is generic.
4) Requires reboots to bounce back and forth between root and unroot. Would be tiresome to do this many times a day.
5) if you reboot while your rooted, you'll get policy breaks.
v6 works great. the new method of CWM installation of scripts makes it very easy. i used the free autorun app "autorun manager" to disable the receiver flags of GFE.
the only annoyance that really is not bad is that when GFE is disabled, the shortcuts/widgets i have are removed since the app is hidden. a very acceptable price to pay considering my company has the "root" compliance turned on. this at least gives me access to email w/o rebooting when needed.
Thanks for all the work!
Do you have to use CWM recovery to flash the zip or can I use the team win recovery. I'm on Verizon note 2 with jelly beans v4 rom.
Thanks, Will
Sent from my SCH-I605 using xda app-developers app
wc4482 said:
Do you have to use CWM recovery to flash the zip or can I use the team win recovery. I'm on Verizon note 2 with jelly beans v4 rom.
Thanks, Will
Sent from my SCH-I605 using xda app-developers app
Click to expand...
Click to collapse
I have not tried twrp but it should work fine.
calisro said:
I have not tried twrp but it should work fine.
Click to expand...
Click to collapse
Just wanted to say thank you for your scripts. Installation worked perfectly on TWRP and to be safe I froze ES file Explorer in titanium since it came with my ROM.
I think my favorite part of the re root script is killing Good and not being bothered by work emails unless I want to be.
Sent from my SCH-I605 using xda app-developers app
glad they are working for you. what rom and phone are you on?
calisro said:
glad they are working for you. what rom and phone are you on?
Click to expand...
Click to collapse
Jelly Beans v4 ROM for Verizon Galaxy Note 2
Sent from my SCH-I605 using xda app-developers app
Good unrooted
Hi,
I've tried lots of different options, being a complete noob at this unrooting malarkey.
Having had a nightmare rooting, I finally managed it, only for Good to then not work because it was rooted.
I finally managed it thus: Downloaded the paid for version of SuperSU. Selected the 'clean up for complete unroot option', downloaded GFE, and self served a new pin, installed Good, went through the setup steps, et voila!
Have rebooted a couple of times and it's still working. Fingers crossed.
Galaxy S3 i9300 with a nightly build of CyanogenMod 10.1 Jelly Bean 4.2.
Not sure if it'll keep working, but I really hope so!
Bestbaldmanever said:
Hi,
I've tried lots of different options, being a complete noob at this unrooting malarkey.
Having had a nightmare rooting, I finally managed it, only for Good to then not work because it was rooted.
I finally managed it thus: Downloaded the paid for version of SuperSU. Selected the 'clean up for complete unroot option', downloaded GFE, and self served a new pin, installed Good, went through the setup steps, et voila!
Have rebooted a couple of times and it's still working. Fingers crossed.
Galaxy S3 i9300 with a nightly build of CyanogenMod 10.1 Jelly Bean 4.2.
Not sure if it'll keep working, but I really hope so!
Click to expand...
Click to collapse
If you completely unrooted it should be fine but now you don't have root unless you reflash. The point here was to offer a way to temp unroot.
calisro said:
If you completely unrooted it should be fine but now you don't have root unless you reflash. The point here was to offer a way to temp unroot.
Click to expand...
Click to collapse
*hangs head in shame for being a dumbass*
That said, it's no biggie to reflash with CF Root whenever I need Root. Which won't be very often I can't imagine... I've had the phone six months and only flashed it cos I got so frustrated with TouchWiz and the horrendous lag I was getting.
The SGS3 is my work phone; I'm an iOS boy for all my personal stuff (sorry!), so I'm quite used to operating without Root access!
Bestbaldmanever said:
*hangs head in shame for being a dumbass*
That said, it's no biggie to reflash with CF Root whenever I need Root. Which won't be very often I can't imagine... I've had the phone six months and only flashed it cos I got so frustrated with TouchWiz and the horrendous lag I was getting.
The SGS3 is my work phone; I'm an iOS boy for all my personal stuff (sorry!), so I'm quite used to operating without Root access!
Click to expand...
Click to collapse
But the scripts in the OP didn't work for you? What problems did you have?
I understand if it ain't broken don't fix it, but I'm also a noob and was able to get this working- the best of both worlds now!
Sent from my SCH-I605 using xda app-developers app
wc4482 said:
But the scripts in the OP didn't work for you? What problems did you get have?
I understand if it ain't broken don't fix it, but I'm also a noob and got the best of both worlds now!
Sent from my SCH-I605 using xda app-developers app
Click to expand...
Click to collapse
Truth be told, i'm not sure what happened. Flashed the ROM, installed connectbot, ran the scripts; nothing happened. Searched for the scripts in system/xbin but couldn't find them.
This was at the end of two days of battling with connection problems with Odin, phone getting stuck in Download mode, SD card not being recognised with the nightly build of CM 10.1 I was using, and a few other things.
I could probably have made it work, but being as my primary goal was to get rid of TouchWiz and all the Vodafone clag on the phone, that has been achieved.
At some point in the future, i might have another go. But as I'm someone who loves technology but isn't a techie, the instructions on most of these blogs are a bit difficult for my small brain to follow.
That's obviously my problem, not anyone else's, but it takes me a while to penetrate the language and understand what people mean. So, unless I really, really need to be switching back and forth between root and no root, I'll probably leave well alone for a while now.
Thanks, though, to everyone who is clearly a lot, lot cleverer and more persisten than I am for making all this wonderful stuff available.
Dear early adopters, I recently switched to Android 10 without any hassle. Root and TWRP have been contained after taking the necessary steps, already mentioned over and over.
The one thing I do not get however is why the app "System App Remover (root needed)" seems to be softbricking my device.
I am on the latest TWRP 3.3.1-65 by mauronofrio, Magisk beta 19.4. Everything is working fine, until I use the app mentioned above.
The apps I am deleting did not yet ever cause any problem at all getting deleted by this exact app so this seems to be app-specific.
Apps I am deleting e.g.:
Chrome
Netflix
Gmail
Google
Google Movies
Google Music
Google Books (or slightly different)
In general just some bloatware. Everything is working flawlessly until I reboot. I am then shown the typical safetynet screen for about 30 seconds and then taken to the fastboot screen, rendering the device useless-as-is. I did try deleting Netflix only as well with the same results.
The only thing reverting those steps is flashing the ROM in TWRP, flashing TWRP and magisk for obvious reasons and trying all over again.
I did try deleting the same apps in Titanium Backup. Deleting Netlix worked without any hickups it seemed. A reboot brought it back up again.
Google apps such as Chrome and Gmail are even getting me a nice "apk-file could not be found/located" message.
How do you guys get rid off those unwanted apps on Android 10 then? Am I missing something? I would appreciate a more technical explanation on the topic as to why things are the way they are if anyone of you guys experiences the same.
I had the same problem until I flashed Magisk Stable. Now no problem to remove system apps on android 10.
You can manually remove system apps using a file manager with root access. Go to system/app and delete the apks. If you mess up, just reflash the rom.
Yes with root file manager I was having the same problem with apps returning after reboot. Canary Magisk was the problem. After installing Magisk Stable all problems were gone. hope this helps someone.
I meanwhile flashed the 19.3 stable magisk. Seems like I had a broken instance of 19.3 on my device as well which caused the same bootloop as the beta. Thanks for the hint.
dtown808 said:
Yes with root file manager I was having the same problem with apps returning after reboot. Canary Magisk was the problem. After installing Magisk Stable all problems were gone. hope this helps someone.
Click to expand...
Click to collapse
tropical cactus said:
You can manually remove system apps using a file manager with root access. Go to system/app and delete the apks. If you mess up, just reflash the rom.
Click to expand...
Click to collapse
Yes, I know that is possible. Still I would prefer some more technical insight on the topic. Status quo at magisk 19.4 is that the apps can be deleted in "root remover"-apps and else, but show up again after a reboot.
Titanium still tells me the apks could not be found. What has been changed by switching to Android Q causing this to happen? After all it was still working fine that way in Pie.
why not disable them ? all this hassle
RfBob said:
Titanium still tells me the apks could not be found. What has been changed by switching to Android Q causing this to happen? After all it was still working fine that way in Pie.
Click to expand...
Click to collapse
Take a look at this post
Toutatis_ said:
Take a look at this post
Click to expand...
Click to collapse
Thank you a lot. This clears the fog. Exactly what I was looking for.
Yandvoiris said:
why not disable them ? all this hassle
Click to expand...
Click to collapse
I don't like freezing/disabling apps instead of deleting them so this is a no-no. Probably more of a personal preference in attempt to keep the device relatively bloatware free.
It's the same with storage extension back in the days. Of course you could go for the 32gb version of the phone and expand by SD card. But I'd rather take the 64gb one and still be able to but not necessarily have to use the SD slot. You get the point, I guess.
Why not just use ADB to remove them? It works fine and is simple enough.
You can also boot in twrp. In mount option put check mark on System. Then in the advanced option use the file manager and navigate to system/system/product/app OR /priv-app. There are the google and other apps. Delete what you wish. when done, unmount system and reboot
There's a magisk modules I used to use on pie that worked flawlessly. Its called debloater or debloat. It removes system apps by using a terminal app by typing the command 'debloat', and its self explanatory from there. Also if there's any issue, you can reinstall the app right back the same way you uninstalled. Haven't tried on Android 10 just yet tho. Worth a try.
One other thing, I'm the same way, if I'm never going to use certain apps, I want them gone. However, phones these days that are coming with base model of 128gb and 8gb( like the one plus 7 pro) I'm not as worried as I used to be with removing the bloat.
P.s. im guessing by the apps you named you also have a 7pro, but I might be wrong. If you a Samsung device, there is the Package disabler app on the play store. And now, I guess they have a version for all Android devices and you don't need root. Here it is https://play.google.com/store/apps/details?id=com.pdp.deviceowner
Good Luck
Debloat indeed does still work. I used it today on 10
Sheetzie03 said:
There's a magisk modules I used to use on pie that worked flawlessly. Its called debloater or debloat. It removes system apps by using a terminal app by typing the command 'debloat', and its self explanatory from there. Also if there's any issue, you can reinstall the app right back the same way you uninstalled. Haven't tried on Android 10 just yet tho. Worth a try.
One other thing, I'm the same way, if I'm never going to use certain apps, I want them gone. However, phones these days that are coming with base model of 128gb and 8gb( like the one plus 7 pro) I'm not as worried as I used to be with removing the bloat.
P.s. im guessing by the apps you named you also have a 7pro, but I might be wrong. If you a Samsung device, there is the Package disabler app on the play store. And now, I guess they have a version for all Android devices and you don't need root. Here it is https://play.google.com/store/apps/details?id=com.pdp.deviceowner
Good Luck
Click to expand...
Click to collapse
Well I don't know what happened me, but youtube (system app) was gone from my phone this morning for no apparent reason. Had to reinstall it from the store as just a normal user apk. Very strange
equlizer said:
Debloat indeed does still work. I used it today on 10
Click to expand...
Click to collapse
Well here you go @RfBob confirmation from @equlizer that Debloat works on 10.
Good to know equlizer, I appreciate you jumping in and confirming this.
On pie, it was my go to, because it worked so well.
Neat little mod. And if you run into issues by uninstalling an app and the system goes haywire, because it has happen to me before where I was sure removing a certain system app would be fine, but it found out it was not, so you can easily reinstall the app the same you uninstalled it.
Take care.
Meanwhile I found some time to play around with the debloater terminal module.
Unfortunately most of the apps good to go are nowhere to be found. E.g. chrome, duo and else. I guess they should be located in vendor apps but they're not. Any suggestions?
I have not yet tried the adb method but guess it should work. For sake of simplicity I'd prefer the debloater module though as my devices are rooted anyway and reverting back to stock apps is no hassle.
RfBob said:
Meanwhile I found some time to play around with the debloater terminal module.
Unfortunately most of the apps good to go are nowhere to be found. E.g. chrome, duo and else. I guess they should be located in vendor apps but they're not. Any suggestions?
Click to expand...
Click to collapse
Three of the first four choices you can search for apps you want to uninstall. The fourth choice you can insert yourself ie., /system/product/app or priv-app. That will give you more choices also.
jcsww said:
Why not just use ADB to remove them? It works fine and is simple enough.
Click to expand...
Click to collapse
Indeed, if you are rooted, then a couple of basic linux commands will do.
You just have to remount the /system partition as writeable.
Code:
> adb shell
$ su
# mount -o rw,remount /system
# cd /system/app/
# rm -rf Netflix_Stub
# rm -rf xxx
# rm -rf yyy
# ...
# sync
# reboot
Above is example to remove the Netflix_Stub ...
If the above is like Chinese for you ... then stay away from it.
Yep, also usually prefer ADB...
foobar66 said:
Indeed, if you are rooted, then a couple of basic linux commands will do.
You just have to remount the /system partition as writeable.
Code:
> adb shell
$ su
# mount -o rw,remount /system
# cd /system/app/
# rm -rf Netflix_Stub
# rm -rf xxx
# rm -rf yyy
# ...
# sync
# reboot
Above is example to remove the Netflix_Stub ...
If the above is like Chinese for you ... then stay away from it.
Click to expand...
Click to collapse
You cannot mount system as rw anymore on android 10, even if rooted.
Code:
flame:/ # mount -o rw,remount /system
mount: '/system' not in /proc/mounts
Code:
flame:/ # mount -o rw,remount /
'/dev/block/dm-4' is read-only
Worked using debloater, but...
Sheetzie03 said:
Well here you go @RfBob confirmation from @equlizer that Debloat works on 10.
Good to know equlizer, I appreciate you jumping in and confirming this.
On pie, it was my go to, because it worked so well.
Neat little mod. And if you run into issues by uninstalling an app and the system goes haywire, because it has happen to me before where I was sure removing a certain system app would be fine, but it found out it was not, so you can easily reinstall the app the same you uninstalled it.
Take care.
Click to expand...
Click to collapse
I did follow the steps to remove youtube app from OOS 10 on One plus 6 and rebooted but it didn't completely remove it, instead it converted it to user app. I simply uninstalled it like a user app, did a reboot and then installed youtube vanced from Magisk. So far everything is working fine.