Related
I've rooted a previous phone (G2) and I'm planning on rooting my Galaxy Nexus before I get too much stuff on it.
I know that I have to unlock the bootloader first and plan on doing that soon. I'll probably use the WugFresh utility linked here: http://forum.xda-developers.com/showthread.php?t=1454314
That said, I'm trying to understand why running a custom recovery is necessary for rooting. I can understand wanting root on startup, but once you're unlocked is it not possible to gain root after the phone was booted?
My concern with running Clockwork is of three parts:
I don't want OTA updates to fail
I don't want to have to reflash stock recovery to get the OTA to install
I don't want to have to reinstall Clockwork Mod between OTAs just to keep root
Perhaps I'm not understanding something in the process here. If someone could spoon feed this information to me it would be greatly appreciated.
1. Don't use a one-click method. Learn to use fastboot and do it manually...it'll serve you well in the long run
2. Once you have CWM you'll have to flash OTA updates manually so they will fail if just downloading so you WILL have to flash the stock recovery to successfuly apply OTA updates without intervention
Mostly what eddyOS said.
CWM isn't permanent unless you remove the install-recovery.xxx (don't remember extension) file from system/etc and I think there is another file in a separate folder but I don't recall where off the top of my head.
so you can use fastboot flash clockwork mod, install a zip and the next time you boot the phone it will restore the stock recovery.
If you want to use clockwork mod to install a zip later just fastboot flash recovery <clockworkmod.img>, then fastboot reboot recovery and you are back in clockwork mod, reboot the phone after flashing and back to stock recovery no problem.
I personally prefer to have CWM permanently on the phone, mostly because i'm lazy and sometimes i like to flash things when I'm not next to my PC. Now that I think about it though ROM manager might let you flash the recovery while on the go.
I wound up using the GNex toolkit linked here to root the phone: http://forum.xda-developers.com/showthread.php?t=1392310
I have the Superuser installed on the phone now, but I didn't flash CWM. I verified that I have root access from Titanium Backup Pro.
That said, can someone tell me why Clockwork either is or sounds like it's required for root?
Is the consequence of rooting my phone with the GNex Toolkit without CWM that the next OTA will remove root?
I still am not sure I completely understand the correlation between the two. As Michael Scott would say, explain it to me like I'm eight...
CWM is not required to gain root access and install the superuser stuff.
There are 2 main components to "rooting" or gaining root access, the su binary and the Superuser.apk app. The su binary provides root access and the Superuser.apk app provides app level root access to other Android apps.The Superuser.apk app can be installed normally through Android but the su binary needs to be installed on the /system mount which is read only.
On most Android devices there have been various exploits of getting the su binary in /system and getting it to stick there. Traditionally these are referred to as rooting methods. On the Galaxy Nexus, because it is a Nexus device, we are provided source code and access to the boot process and storage on the device (referred to as unlocking the bootloader).
When an Android device powers up it goes through a boot up process to load and start the necessary components and services to get the device running. One phase of this boot process is to temporarily load a working OS so various initialization tasks can be done, such as loading device drivers and mounting file systems. This working OS is actually a very barebones linux configuration by loading an instance of the kernel and setting up its file system in RAM.
Because we have access to the source code for this boot process and because the bootloader can be unlocked we can modify the boot process to place the su binary in the /system mount for us. This modified source code can be compiled and used to boot the phone. This is how we "root" the Galaxy Nexus. The toolkits have a copy of this modified boot.img and all it does is unlock your bootloader and boot this boot.img which install the su binary and Superuser.apk files for you.
In regards to CWM. The Android recovery is a special process that can be triggered in the boot process. It itself is also an instance of a working OS by loading a kernel and setting up its file system in RAM. What the CWM developer has done is in addition to his modifications and additions to the recovery utilities he has enabled the ADB daemon and set up the su binary in the recovery's file system so we have ADB and root access when CWM boots up - a very handy feature.
So CWM doesn't "root" your phone at all - it only provides root access when it's booted. OTA updates may remove the su binary but generally it can be restored by rebooting the modified boot.img. There are caveats that I haven't mentioned. Sometimes these OTA updates contain a new bootloader that can invalidate booting a previous boot.img.
silow said:
CWM is not required to gain root access and install the superuser stuff.
There are 2 main components to "rooting" or gaining root access, the su binary and the Superuser.apk app. The su binary provides root access and the Superuser.apk app provides app level root access to other Android apps.The Superuser.apk app can be installed normally through Android but the su binary needs to be installed on the /system mount which is read only.
On most Android devices there have been various exploits of getting the su binary in /system and getting it to stick there. Traditionally these are referred to as rooting methods. On the Galaxy Nexus, because it is a Nexus device, we are provided source code and access to the boot process and storage on the device (referred to as unlocking the bootloader).
When an Android device powers up it goes through a boot up process to load and start the necessary components and services to get the device running. One phase of this boot process is to temporarily load a working OS so various initialization tasks can be done, such as loading device drivers and mounting file systems. This working OS is actually a very barebones linux configuration by loading an instance of the kernel and setting up its file system in RAM.
Because we have access to the source code for this boot process and because the bootloader can be unlocked we can modify the boot process to place the su binary in the /system mount for us. This modified source code can be compiled and used to boot the phone. This is how we "root" the Galaxy Nexus. The toolkits have a copy of this modified boot.img and all it does is unlock your bootloader and boot this boot.img which install the su binary and Superuser.apk files for you.
In regards to CWM. The Android recovery is a special process that can be triggered in the boot process. It itself is also an instance of a working OS by loading a kernel and setting up its file system in RAM. What the CWM developer has done is in addition to his modifications and additions to the recovery utilities he has enabled the ADB daemon and set up the su binary in the recovery's file system so we have ADB and root access when CWM boots up - a very handy feature.
So CWM doesn't "root" your phone at all - it only provides root access when it's booted. OTA updates may remove the su binary but generally it can be restored by rebooting the modified boot.img. There are caveats that I haven't mentioned. Sometimes these OTA updates contain a new bootloader that can invalidate booting a previous boot.img.
Click to expand...
Click to collapse
Thanks a lot for breaking it down for me; much appreciated.
silow said:
CWM is not required to gain root access and install the superuser stuff.
There are 2 main components to "rooting" or gaining root access, the su binary and the Superuser.apk app. The su binary provides root access and the Superuser.apk app provides app level root access to other Android apps.The Superuser.apk app can be installed normally through Android but the su binary needs to be installed on the /system mount which is read only.
On most Android devices there have been various exploits of getting the su binary in /system and getting it to stick there. Traditionally these are referred to as rooting methods. On the Galaxy Nexus, because it is a Nexus device, we are provided source code and access to the boot process and storage on the device (referred to as unlocking the bootloader).
When an Android device powers up it goes through a boot up process to load and start the necessary components and services to get the device running. One phase of this boot process is to temporarily load a working OS so various initialization tasks can be done, such as loading device drivers and mounting file systems. This working OS is actually a very barebones linux configuration by loading an instance of the kernel and setting up its file system in RAM.
Because we have access to the source code for this boot process and because the bootloader can be unlocked we can modify the boot process to place the su binary in the /system mount for us. This modified source code can be compiled and used to boot the phone. This is how we "root" the Galaxy Nexus. The toolkits have a copy of this modified boot.img and all it does is unlock your bootloader and boot this boot.img which install the su binary and Superuser.apk files for you.
In regards to CWM. The Android recovery is a special process that can be triggered in the boot process. It itself is also an instance of a working OS by loading a kernel and setting up its file system in RAM. What the CWM developer has done is in addition to his modifications and additions to the recovery utilities he has enabled the ADB daemon and set up the su binary in the recovery's file system so we have ADB and root access when CWM boots up - a very handy feature.
So CWM doesn't "root" your phone at all - it only provides root access when it's booted. OTA updates may remove the su binary but generally it can be restored by rebooting the modified boot.img. There are caveats that I haven't mentioned. Sometimes these OTA updates contain a new bootloader that can invalidate booting a previous boot.img.
Click to expand...
Click to collapse
su binary provides root level access.
SuperUser.apk is nothing more than a firewall to save you from yourself.
Busybox is a very important util that provides a lot of the su copy, read, write functions.
Having the correct permissions enabled is essential for all of these to work...
The bootloader has write access to system and recovery, but in its locked state it can only flash files signed by the same originator as the bootloader itself. Unlocked, it can flash anything...
Similarly, stock recovery had write access to system etc, but the stock recovery can only flash files by the same originator as the the recovery. Custom recovery has a lot more flexibility...
Unlocking the bootloader allows you to flash a non-signed recovery. The custom (non-signed) recovery allows you to modify pretty much anything, including the installation of the su binary and busybox into /system
It seems that most of the community is gravitating toward disabling forced encryption, so I might be alone here, but I actually like the idea of having the device encrypted.
I rooted my device without flashing twrp (I'll cover the steps I took in just a second) so that it could retain the original stock recovery. I'm trying to keep the device as stock as possible, just with root and xposed.
Steps I took are as follows...
Download
Minimal ADB and Fastboot
TWRP
SuperSU (beta)
Xposed
Enable developer mode on device
Code:
adb reboot fastboot
Code:
fastboot boot twrp*.img
(I had to nuke /data at this point, otherwise it wouldn't boot)
Turn on ADB sideload in TWRP
Code:
adb sideload BETA*.zip
Code:
adb sideload xposed*.zip
It's successfully rooted and xposed framework is installed, but it's not encrypted, and if I go into Settings -> Security -> Encryption and attempt to encrypt the device, it will just hang for hours at a time.
If anyone can offer any insight as to how I can get it rooted with xposed framework while retaining device encryption, that would be super helpful.
Figured it out.
Have to create a flag file for SuperSU. It can be any of the following (note leading dot to indicate it's a hidden file)...
/data/.supersu
/cache/.supersu
/system/.supersu
In it, the file needs to contain the following:
Code:
KEEPFORCEENCRYPT=true
Easiest way to accomplish this, for my purposes, is to do
Code:
adb shell 'echo "KEEPFORCEENCRYPT=true" >/data/.supersu'
I restored completely to stock before doing this, to avoid any possible issues. Also, this currently only works with BETA version (SuperSU 2.74). This particular flag's behavior might be inverted in the future, i.e., SuperSU might leave forceencrypt flag by default and require a flag to disable forceencrypt.
This guide presupposes that you have Supersu installed as systemless, and that you have access to adb.
This will bypass provisioning checks for builtin tether app. The modded apk should work with future updates without touching /system at all.
Installation
Method 1 - Manual install
Download the attached CarrierEntitlement apk.
If you have su.img su:
Code:
adb push CarrierEntitlement.apk /sdcard/CarrierEntitlement.apk
adb shell
su
mkdir /su/CarrierEntitlement
cp /sdcard/CarrierEntitlement.apk /su/CarrierEntitlement/CarrierEntitlement.apk
chmod 644 /su/CarrierEntitlement/CarrierEntitlement.apk
echo "mount -o bind /su/CarrierEntitlement/CarrierEntitlement.apk /system/priv-app/CarrierEntitlement/CarrierEntitlement.apk" > /su/su.d/05TetherMod
chmod +x /su/su.d/05TetherMod
reboot
If you have sbin su (Android 8.0+)
Code:
adb push CarrierEntitlement.apk /sdcard/CarrierEntitlement.apk
adb shell
su
mkdir /sbin/supersu/CarrierEntitlement
cp /sdcard/CarrierEntitlement.apk /sbin/supersu/CarrierEntitlement/CarrierEntitlement.apk
chmod 644 /sbin/supersu/CarrierEntitlement/CarrierEntitlement.apk
echo "mount -o bind /sbin/supersu/CarrierEntitlement/CarrierEntitlement.apk /system/priv-app/CarrierEntitlement/CarrierEntitlement.apk" > /sbin/supersu/su.d/05TetherMod
chmod +x /sbin/supersu/su.d/05TetherMod
reboot
Method 2 - Flashable Zip (su.img only)
Code:
1. Download attached zip.
2. Flash in TWRP (Last tested in alpha 2)
Information
This mod is accomplished by replacing the following function:
Code:
.method public static getCarrierEntitlement(Landroid/content/Context;)Lcom/google/android/carrierentitlement/CarrierEntitlement;
.registers 2
.param p0, "context" # Landroid/content/Context;
.prologue
.line 56
const/4 v0, 0x0
return-object v0
.end method
NOTE: Post install
You may need to edit your APNs to get tethering working for your carrier.
On sprint, where editing APNs is disabled, the fix is here: Sprint Fix
Be sure to thank @Builtfordtough1 for all his help in diagnosing the issue at this post: The Solution!
Be sure to thank sb1893 for sbin su instructions.
Worked Perfectly
This worked perfectly. Fantastic job!
So I am on stock with unlocked bootloader, twrp installed, and rooted with SuperSU. Because this is an apk file, do i just download onto the phone and install as I would with any other .apk file?
coolhandz said:
So I am on stock with unlocked bootloader, twrp installed, and rooted with SuperSU. Because this is an apk file, do i just download onto the phone and install as I would with any other .apk file?
Click to expand...
Click to collapse
The directions clearly state in adb speak that you need to create a directory for the file. Move to said directory, change permissions, etc etc. Nothing about installing via the apk.
pcriz said:
The directions clearly state in adb speak that you need to create a directory for the file. Move to said directory, change permissions, etc etc. Nothing about installing via the apk.
Click to expand...
Click to collapse
well, i can follow basic commands in minimal adb & fastboot. I think this may be above me unless there is an idiots' guide.
coolhandz said:
well, i can follow basic commands in minimal adb & fastboot. I think this may be above me unless there is an idiots' guide.
Click to expand...
Click to collapse
Do you have access to adb? They are pretty straight forward. May need to view them on the website but if you are using an app it may throw the word wrap off and make the commands seem confusing. The directions are pretty word for word.
pcriz said:
Do you have access to adb? They are pretty straight forward. May need to view them actually on the website but if you are using an app it may throw the word wrap off and make the commands seem confusing. The directs are pretty word for word.
Click to expand...
Click to collapse
If by adb you mean minimal adb & fastboot, then yes I have access and I could probably brave it.
coolhandz said:
If by adb you mean minimal adb & fastboot, then yes I have access and I could probably brave it.
Click to expand...
Click to collapse
I wouldn't suggest doing it how I did it but I downloaded the file to my phone. I created the directory using a root enabled file browser (see mkdir command {make directory}). I even used the file properties option in solid explorer to change the permissions (see chmod 644). Every other command I did on the phone from a terminal emulator. Just had to ignore the adb shell command because I am actually doing them on the device and not through a shell on my computer.
pcriz said:
I wouldn't suggest doing it how I did it but I downloaded the file to my phone. I created the directory using a root enabled file browser (see mkdir command {make directory}). I even used the file properties option in solid explorer to change the permissions (see chmod 644). Every other command I did on the phone from a terminal emulator. Just had to ignore the adb shell command because I am actually doing them on the device and not through a shell on my computer.
Click to expand...
Click to collapse
yeah, all that is definitely outside of my comfort zone, but thank you for the info.
Can you normally update your device with OTA-updates like a un-rooted device, without flashfire or connect to your computer?
Is there an advantage to doing this over adding "net.tethering.noprovisioning=true" to the build.prop file?
airmaxx23 said:
Is there an advantage to doing this over adding "net.tethering.noprovisioning=true" to the build.prop file?
Click to expand...
Click to collapse
This mod is systemless, and should survive OTAs. That mod changes the build.prop on the system partition, which could prevent taking OTAs.
njeri123 said:
Can you normally update your device with OTA-updates like a un-rooted device, without flashfire or connect to your computer?
Click to expand...
Click to collapse
Any modification to the boot image *should* prevent OTAs from working at all. However, you can flash back to stock boot images, and take OTAs as long as you have not modified /system, which this mod does not do.
Furthermore, as long as you don't wipe /data/ this mod will live in su.img and survive when you flash newer system software.
Fenny said:
This mod is systemless, and should survive OTAs. That mod changes the build.prop on the system partition, which could prevent taking OTAs.
Any modification to the boot image *should* prevent OTAs from working at all. However, you can flash back to stock boot images, and take OTAs as long as you have not modified /system, which this mod does not do.
Furthermore, as long as you don't wipe /data/ this mod will live in su.img and survive when you flash newer system software.
Click to expand...
Click to collapse
Thanks for the explanation, I removed the build.prop line and used this method and it's working fine. Thank you.
@Fenny
Thank you so much for putting this into a .zip file. It is greatly appreciated!
is there a non root method to bypass the checks? i dont plan on unlocking or rooting since i use android pay...
ddarvish said:
is there a non root method to bypass the checks? i dont plan on unlocking or rooting since i use android pay...
Click to expand...
Click to collapse
I also use Android pay, so I have two boot images ready to fastboot or flash. I have a boot image with root, and a boot image without root running a kernel that hides the bootloader unlocked flag.
So, the way I handle this, I flash the unrooted (bootloader flag hidden) image as my daily driver kernel, this passes safetynet, and allows me to use Android pay.
I make a backup of that boot image. Then, I install TWRP, my custom kernel, and SuperSU. I make a backup of that image as well.
So I have two backed up boot images:
rooted.img
HideBLUnlock.img
I flash HideBLUnlock.img to boot a, and boot b, safetynet passes.
Whenever I need to tether I have my computer with me, so I "fastboot boot rooted.img" which leaves me rooted until my next reboot.
Depending on your usage you might want to reverse that.
All my mods get stored in su.img, so switching out the boot images is all I need to have the best of both worlds.
Is it possible to fastboot boot twrp and flash the zip without being rooted or having twrp actually installed? O unlocked my bootloader but that's been it
Ocelot13 said:
Is it possible to fastboot boot twrp and flash the zip without being rooted or having twrp actually installed? O unlocked my bootloader but that's been it
Click to expand...
Click to collapse
You can use the fastboot twrp image to install this mod but you MUST have SuperSu. I have basic validation to check that in my update.zip. If you don't have a su.img in /cache or /data, this mod cannot be installed.
Flashed via TWRP and now i finally have a fully functioning hotspot!!
Fenny said:
I also use Android pay, so I have two boot images ready to fastboot or flash. I have a boot image with root, and a boot image without root running a kernel that hides the bootloader unlocked flag.
So, the way I handle this, I flash the unrooted (bootloader flag hidden) image as my daily driver kernel, this passes safetynet, and allows me to use Android pay.
I make a backup of that boot image. Then, I install TWRP, my custom kernel, and SuperSU. I make a backup of that image as well.
So I have two backed up boot images:
rooted.img
HideBLUnlock.img
I flash HideBLUnlock.img to boot a, and boot b, safetynet passes.
Whenever I need to tether I have my computer with me, so I "fastboot boot rooted.img" which leaves me rooted until my next reboot.
Depending on your usage you might want to reverse that.
All my mods get stored in su.img, so switching out the boot images is all I need to have the best of both worlds.
Click to expand...
Click to collapse
This is facinating, do you ever think where we can use boot a and boot b in a multiboot like fashion so that when you turn on the device you can choose what to boot?
I think I already know the answer but you'll never know.....
I am looking into options to use LOS17 in combination with LOS recovery because then it is possible to have OTA updates even when storage is encrypted.
Though, I would like to have the option to use a script so I can remove some system apps, add some stuff to build.prop and remove some temporary files after every OTA.
As far as I know the only way this is possible is to add an a script to /system/addon.d.
Therefor I have tried using adb to push a file, though when phone is not rooted, it is not possible to use adb root and then adb remount rw and adb push.
So here the questons;
- Is is possible to add a script to /system/addon.d, though without root and without TWRP?
- When not; is there another way to run a script after every OTA without root and without TWRP?
Setup:
LOS 17.1 without root, encrypted and locked bootloader
I will answer myself as it seems OR a stupid question OR something else....
But, as already expected, without root en with a locked bootloader, the recovery is the only place where you can do something root-related when the recovery is giving this option ofcourse. LOS recovery, automatic OTA updates and additional scripts is therefor not possible because you can not place or modify stuff in /system (as it should be out of security concerns on non-rooted devices).
Though, @nvertigo67 posted a nice post about this topic. After reading I realised that, as I want to be in control of my phone AND I want to pay something back to our great dev's, I will definitely stick with TWRP and flashing and running scripts myself.
How to install LOS with TWRP, encrypt en relock bootloader can be found here.
Topic closed for me.
I messed it up myself with my modified build.prop settings:
By design adb root command works in development builds only (i.e. eng and userdebug which have ro.debuggable=1 by default). So to enable the adb root command the ro.debuggable=1 line must be in build.prop, which I have set to 0 for CTS reasons.
Unfortunately it seems my banking app is looking for this parm because when set to 1 the app is giving an error message on startup.
So no adb root for me as long as I want to use the banking app.
first off, huge shout out to @JengaMasterG for TWRP for these devices. Without him, this super simple method wouldn't be possible.
What You'll Need
- Android 11 most recent update
- TWRP: TWRP for Surface Duo (credits to @JengaMasterG )
- Unlocked Bootloader
- ADB/Fastboot: ADB/Fastboot Install (what i use)
- Magisk
video
YT Tutorial
Bootloader Unlock
1.) Enable Developer Options via tapping Build Number over and over in the About Device part of settings
2.) Enable USB Debugging and OEM Unlock
3.) Plug device into the computer, and type the following command in cmd.exe, hit enter
Code:
adb devices
4.) You may get a pop up on screen requesting permission, always allow it
5.) Type the following and hit enter
Code:
adb reboot bootloader
6.) Once in the bootloader, your device might not be recognized right away and will need the driver manually installed via Device manager (see video for that)
7.) Once device is recognized, type the following command
Code:
fastboot flashing unlock
8.) Allow the unlocking of the Bootloader on device screen. this will erase everything
9.) Allow the device to fully boot up, enable USB Debugging again and continue the tutorial!
Instructions
1.) Rename Magisk-vxx.x.apk to Magisk.zip
2.) Enable USB Debugging
3.) Type the following to make sure your computer sees the device (in cmd.exe)
Code:
adb devices
4.) You may get a pop up on your device's screen asking for adb permission, check the always allow and hit ok
5.) Type the follow command to reboot to bootloader (in cmd.exe)
Code:
adb reboot bootloader
6.) Once you're in the booloader and its unlocked, download the TWRP image from above
7.) Use the following fastboot command to boot into TWRP
Code:
fastboot boot twrp.img
8.) Once TWRP boots, keep your device plugged in via usb and type the following command into cmd.exe and hit enter
Code:
adb shell twrp sideload
9.) Once in sideload, you can type the following with magisk.zip and root your device!
Code:
adb sideload magisk.zip
10.) Use the following command to reboot and you're done!
Code:
adb reboot
congrats! you're rooted!
LETS GOOOO!! HEROOO!! Super easy and working on the latest December 2022 update! Felt way safer as well, not so much concern over twrp as we only booted into it, and then I just used the standard magisk and it worked excellent without worrying about all types of patches and versions aside from the latest twrp for android 12 from @JengaMasterG!
Thank you! I think the renaming the magisk file from apk to zip was probably what I was doing wrong trying to follow the other methods, on top of driver errors, that were solved by uninstalling all the drivers for the duo on my surface pro, which revealed a native 'Surface Fastboot' driver. Combine that with the 15 second ADB and it's .bat ready to go command line interface, idk... it wen't so smooth and worked perfectly.
Now I can try to see if I can improve my experience with some go to methods.. I really want to enable immersive mode and hopefully increase overall volume, if possible (many devices this can be done with engineeringmode, idk yet but hopefully it does have one and hopefully I can also calibrate the gyroscope)... obviously adblock without vpn is on the menu.... can utilize the full autoruns app to stop apps from starting up at boot like in windows... and then get into some other customizations.
cqqx2 said:
LETS GOOOO!! HEROOO!! Super easy and working on the latest December 2022 update! Felt way safer as well, not so much concern over twrp as we only booted into it, and then I just used the standard magisk and it worked excellent without worrying about all types of patches and versions aside from the latest twrp for android 12 from @JengaMasterG!
Thank you! I think the renaming the magisk file from apk to zip was probably what I was doing wrong trying to follow the other methods, on top of driver errors, that were solved by uninstalling all the drivers for the duo on my surface pro, which revealed a native 'Surface Fastboot' driver. Combine that with the 15 second ADB and it's .bat ready to go command line interface, idk... it wen't so smooth and worked perfectly.
Now I can try to see if I can improve my experience with some go to methods.. I really want to enable immersive mode and hopefully increase overall volume, if possible (many devices this can be done with engineeringmode, idk yet but hopefully it does have one and hopefully I can also calibrate the gyroscope)... obviously adblock without vpn is on the menu.... can utilize the full autoruns app to stop apps from starting up at boot like in windows... and then get into some other customizations.
Click to expand...
Click to collapse
Hello! I'm rooted, but I can only read and can't write. I am Android version 122022.821.13 of Att.
So I can't delete the apk inside the system directory
linlin2az said:
Hello! I'm rooted, but I can only read and can't write. I am Android version 122022.821.13 of Att.
So I can't delete the apk inside the system directory
Click to expand...
Click to collapse
Newer Android versions, especially stock ROM, generally doesn't let you write to the system partition. Only ROMs can do that, unless you can find a way to change the partition permissions. Root alone will not allow it, no matter what you do. I used to know of a TWRP script to fix that and make the system writable, but it doesn't work on andorid 11/12/13 anyway