Related
Can someone please help?
I'm trying to edit the system\etc\bluez\main.conf file using root explorer.
I can edit the line I want, save and exit but it then reboots the phone automatically and the original unedited file is back.
What am I doing wrong?
BTW the phone is rooted and this is why I want to edit the file...
http://forum.xda-developers.com/showthread.php?t=676175
neomagik said:
Can someone please help?
I'm trying to edit the system\etc\bluez\main.conf file using root explorer.
I can edit the line I want, save and exit but it then reboots the phone automatically and the original unedited file is back.
What am I doing wrong?
BTW the phone is rooted and this is why I want to edit the file...
http://forum.xda-developers.com/showthread.php?t=676175
Click to expand...
Click to collapse
As we don't have write access to /system on a normal booted desire, you have to do all your work in recovery-mode.
I can get into recovery mode ok but how do I edit the file I want from there?
The options I have are:
- Reboot system now
- USB-MS toggle
- Backup/Restore
- Flash zip from sdcard
- Wipe
- Partition sdcard
- Other
- Power off
Extract the file out of the rom, change it, than push it back to the rom.
You can do that from ADB shell while your phone is in recovery.
You can find commands how to backup files and push/delete them back to ROM on this forums, or you can search it on internet.
dont forget to mount /system
adb shell in a new terminal screen
then mount /system
I can't figure out what I'm doing wrong.
I've tried the method suggested by allla and ivicask ie, using adb commands in recovery mode and I get the same result as using root explorer, the file appears to have copied successfully it reboots but the original file is back again
I've also tried vastlopers method and after lots of reading found that the device needs to be booted normally to 'remount' however when I try to push the file now it says "Directory not empty"
It seems to me that this adb method is just a long winded alternative to root explorer, none of which get the desired result.
Please help?
Bump. Bump.
I've now tried adb file explorer but can't figure out how to install Busybox on my device.
I'm out of ideas. Someone must know how to edit/overwrite the main.conf file.
I'm being told elsewhere on this Forum that the Desire cannot yet be fully rooted for r/w access to the /system/ folder. Is this correct?
neomagik said:
I'm being told elsewhere on this Forum that the Desire cannot yet be fully rooted for r/w access to the /system/ folder. Is this correct?
Click to expand...
Click to collapse
Yes it is. It's also written in the root tutorial!
Like a dummy I tried to rename framework-res while using my nexus so I could replace it with an edited one (deb rooted, stock 4.4.4 rom, franco -17 kernel)
Now Im trying to ADB in to rename the original file so it will boot again.
I'm connected to the nexus in ADB but when I try to pull or rename the file I always get some sort of error.
I was able to adb push a framwork file I downloaded on my computer but it still wouldnt boot. Im assuming it was bad.
Any help is much appreciated!
thanks!
Rhatfield25 said:
Like a dummy I tried to rename framework-res while using my nexus so I could replace it with an edited one (deb rooted, stock 4.4.4 rom, franco -17 kernel)
Now Im trying to ADB in to rename the original file so it will boot again.
I'm connected to the nexus in ADB but when I try to pull or rename the file I always get some sort of error.
I was able to adb push a framwork file I downloaded on my computer but it still wouldnt boot. Im assuming it was bad.
Any help is much appreciated!
thanks!
Click to expand...
Click to collapse
The reason it would not boot with the one you pushed to the device is probably because you have to set permissions correctly after the push. Framework res should probably be set to rw-r--r--
Run this after the push, or if the file is still on the phone, run it now.
Code:
adb shell
su
chmod 644 /system/framework/framework-res.apk
SwoRNLeaDejZ said:
The reason it would not boot with the one you pushed to the device is probably because you have to set permissions correctly after the push. Framework res should probably be set to rw-r--r--
Run this after the push, or if the file is still on the phone, run it now.
Code:
adb shell
su
chmod 644 /system/framework/framework-res.apk
Click to expand...
Click to collapse
I will give it a shot the second I get home! Thank you so much for the help. So by default files pushed to the system do not have full read and write permissions?
Thanks again!
Rhatfield25 said:
I will give it a shot the second I get home! Thank you so much for the help. So by default files pushed to the system do not have full read and write permissions?
Thanks again!
Click to expand...
Click to collapse
Yes, most of the time, pushed files will copy with bad permissions. Every time I've ever edited a system APK, I've had to subsequently set permissions before it would act correctly. Might not be 100% your issue, but it's definitely worth a shot.
SwoRNLeaDejZ said:
Yes, most of the time, pushed files will copy with bad permissions. Every time I've ever edited a system APK, I've had to subsequently set permissions before it would act correctly. Might not be 100% your issue, but it's definitely worth a shot.
Click to expand...
Click to collapse
Well now Ive run into a new problem. When I SU to get root access it tells me that /sbin/sh isnt found.
I rooted the n7 with cf autoroot.
this would be a whole lot easier if twrp would mount the tablet so I could just upload and flash a zip to update it.
Well I was able to sideload the boot animation herehttp://forum.xda-developers.com/showthread.php?t=2591471 just to confirm that sideload was working. I rebooted and it worked but still will not get past the boot animation.
The framework file simply needs to be put in /system right? so the command would look like
abd sideload framework-res.apk /system
Is that right?
Rhatfield25 said:
Well now Ive run into a new problem. When I SU to get root access it tells me that /sbin/sh isnt found.
I rooted the n7 with cf autoroot.
this would be a whole lot easier if twrp would mount the tablet so I could just upload and flash a zip to update it.
Click to expand...
Click to collapse
What about trying to use the terminal emulator in twrp?
Rhatfield25 said:
Well I was able to sideload the boot animation herehttp://forum.xda-developers.com/showthread.php?t=2591471 just to confirm that sideload was working. I rebooted and it worked but still will not get past the boot animation.
The framework file simply needs to be put in /system right? so the command would look like
abd sideload framework-res.apk /system
Is that right?
Click to expand...
Click to collapse
You need to fix the framework file before you can boot. Try running the permission command without su first.
About the only reason I root my phone is to install AdAway. I'd prefer to not modify the system partition to help make OTA's easier to get and to allow Android Pay to work. AdAway has a flashable .zip file that preps the hosts file to use the systemless root structure that comes along with SuperSU. Unfortunately, that script depends on being able to access the /data partition inside of TWRP which isn't going to happen any time soon on the HTC 10. Fortunately, it is easy for us to manually replicate what the flashable .zip is trying to do.
This isn't a detailed how-to, but more of a set of guidelines. Don't blame me if your phone explodes.
Root the phone with the latest SuperSU.
Download the AdAway_systemless_hosts_v2.zip file from the Unofficial AdAway thread.
Extract the files from inside the zip. We are only interested in two files in the support folder.
Connect the phone to your PC and turn on file transfer mode.
Copy "hosts" and "0000adaway.script" that you just extracted to the internal storage of your phone.
Use a program file Root Explorer to move "hosts" into /su/etc and move "0000adaway.script" into /su/su.d (this probably could have been done with ADB push, but I got permission errors when I tried it that way and I'm impatient and lazy).
Chmod 0755 /su/su.d/0000adaway.script (I used a root shell on the phone via ADB)
Install AdAway (I used the link in the Unofficial AdAway thread.)
Reboot the phone.
Run AdAway like normal. By default it should use /system/etc/hosts which is what you want.
If something doesn't work, figure out why and fix it. I'm happy to answer questions to the best of my ability.
AdAway works without problems here, with simple press activate button.
starbase64 said:
AdAway works without problems here, with simple press activate button.
Click to expand...
Click to collapse
Yup
Sent from my HTC 10 using Tapatalk
starbase64 said:
AdAway works without problems here, with simple press activate button.
Click to expand...
Click to collapse
Yes, but it modifies the /system partition unless you do the trick in OP. If I'm correct, you will have problems with OTA updates and Google Pay if you let AdAway directly modify the hosts file on /system.
Now that TWRP can access /data, can we just flash the zip?
goodtimes50 said:
Now that TWRP can access /data, can we just flash the zip?
Click to expand...
Click to collapse
Yes, you can. I downloaded that zip and apk from the Unofficial AdAway thread linked above. Booted into TWRP, flashed the newest betaSuperSU2.74-2-forceencrypt (not related to this, just so I'd be on the latest version), then the AdAway_systemless_hosts_v2.zip, rebooted and installed the apk and let it run. Rebooted. Showing hosts location as /system32/etc/hosts as the OP says is a good thing, and both files mentioned are in their correct places per Root Browser. [emoji106]
Sent from my HTC 10 using XDA-Developers mobile app
Sorry that it doesn't completely match the thread here but I think my question could fit in here anyway.
Do I suggest correctly that with systemless root, systemless AdAway and the stock recovery OTAs should be fully usable? Since there's no other modification to /system then.
bmwbasti said:
Sorry that it doesn't completely match the thread here but I think my question could fit in here anyway.
Do I suggest correctly that with systemless root, systemless AdAway and the stock recovery OTAs should be fully usable? Since there's no other modification to /system then.
Click to expand...
Click to collapse
I believe that is correct. There hasn't been a new OTA for my phone yet so I can't verify. However, when I do the check for new software it tells me no new updates (as opposed to the message about the files system being corrupt). I believe Android Pay should also work. I have it installed and added a new card, but I haven't tested making a purchase yet.
Thanks for the guide.
My device is rooted, but I didn't found su folder in anywhere when I use Root Explorer with root access, does anyone tell me how to get su folder and make AdAway work?
Fix for AdAway.
matif525 said:
Thanks for the guide.
My device is rooted, but I didn't found su folder in anywhere when I use Root Explorer with root access, does anyone tell me how to get su folder and make AdAway work?
Click to expand...
Click to collapse
Your device may use su, & still not have an su folder (at all) that is used for hosts file (ie systemless root). Just do this..
Download... Terminal emulator.
https://play.google.com/store/apps/details?id=jackpal.androidterm
Open terminal
Then enter these commands.. "Quote"
su
mount -orw,remount /system
rm /system/etc/hosts
ln -s /data/data/hosts /system/etc/hosts
mount -orw,remount /system
Now open AdAway go to preferences and select option to " Target hosts file"
Select /data/data/hosts
Enjoy..
If you still have ads in apps do this!!!
githyanki said:
Open the 3 dot menu in adaway, chose log DNS request. Enable TCP dump.
Open the app with ads, when ad loads, go back to adaway, and open log.
Long press any entries and chose black list.
Profit
Click to expand...
Click to collapse
All credit where credit is due. I just shared what I read else where.
Read here for more details..
https://github.com/AdAway/AdAway/issues/770
&
http://forum.xda-developers.com/showthread.php?t=2190753&page=143#post68988079
There is a known issue in HTC devices involves S-off. If the above doesn't solve this for you message here I'll follow. Or pm me. I work wierd hours be patient.
Rom Maximus 3.0.0 ( Android 7 ).Any instruction don't works,adaway no blocked ads.
regarding su folder to move files to
FreydNot said:
About the only reason I root my phone is to install AdAway. I'd prefer to not modify the system partition to help make OTA's easier to get and to allow Android Pay to work. AdAway has a flashable .zip file that preps the hosts file to use the systemless root structure that comes along with SuperSU. Unfortunately, that script depends on being able to access the /data partition inside of TWRP which isn't going to happen any time soon on the HTC 10. Fortunately, it is easy for us to manually replicate what the flashable .zip is trying to do.
This isn't a detailed how-to, but more of a set of guidelines. Don't blame me if your phone explodes.
Root the phone with the latest SuperSU.
Download the AdAway_systemless_hosts_v2.zip file from the Unofficial AdAway thread.
Extract the files from inside the zip. We are only interested in two files in the support folder.
Connect the phone to your PC and turn on file transfer mode.
Copy "hosts" and "0000adaway.script" that you just extracted to the internal storage of your phone.
Use a program file Root Explorer to move "hosts" into /su/etc and move "0000adaway.script" into /su/su.d (this probably could have been done with ADB push, but I got permission errors when I tried it that way and I'm impatient and lazy).
Chmod 0755 /su/su.d/0000adaway.script (I used a root shell on the phone via ADB)
Install AdAway (I used the link in the Unofficial AdAway thread.)
Reboot the phone.
Run AdAway like normal. By default it should use /system/etc/hosts which is what you want.
If something doesn't work, figure out why and fix it. I'm happy to answer questions to the best of my ability.
Click to expand...
Click to collapse
Hi there, ive got a mate 8, not sure if this adblocker will work on it but i want to try it out anyway. Ive unzipped the file but which folder in su do i move the files to? screenshot of the folders i have in su
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?
Hey folks,
Last night I was editing a file located under "data/system/users/0/settings_ssaid.xml" and upon rebooting my phone, it's been stuck in a boot loop. I have an original copy saved in a different folder, but unable to access anything to replace it.
Is there any specific fastboot command I can run to swap the files (adb push, pull etc)? Only boot slot A is giving me an issue, and I was reading flashing system.img would be able to help, but I don't wanna do anything I'm unsure will wipe any of my data where I'd have to start over unless I've recovered some of that data first.
If I do have to flash any stock images, pls post the instructions for clarity.
Thanks in advance.
Assuming adb can actually access your device, while it's stuck in a boot loop (test this by running 'adb devices' and see if you receive a response)
You can run the following command to list all the files in your specific folder.
adb shell ls FILEPATH
Every file in your specific folder will be listed. You can then do the following to pull/push your file
adb pull FILEPATH
adb push FILENAME FILEPATH
Of course you need to place the file that you want to push in your ADB folder.
Mind though, that simply replacing your edited file with the backup might not solve your bootloop.
You can always look up available commands here
adb shell ls - Android ADB Shell Commands Manual
Morgrain said:
Assuming adb can actually access your device, while it's stuck in a boot loop (test this by running 'adb devices' and see if you receive a response)
Click to expand...
Click to collapse
Yes, I can access adb and my device while it's booting up, but once it reboots I lose connection. Unless I can interrupt the process I'd have to be very quick in my typing to copy files lol.
Even with the few seconds I have to type some commands to access the directory of the file I edited, I do get a permission denied error.
Would swapping to Slot B during boot allow me into the system, or even flashing the system.img file?
RetroTech07 said:
Yes, I can access adb and my device while it's booting up, but once it reboots I lose connection. Unless I can interrupt the process I'd have to be very quick in my typing to copy files lol.
Even with the few seconds I have to type some commands to access the directory of the file I edited, I do get a permission denied error.
Would swapping to Slot B during boot allow me into the system, or even flashing the system.img file?
Click to expand...
Click to collapse
No because your file is on /data.
The issue is that you can't push your file to /scard since (I guess) you can't even get beyond to the point where /sdcard is mounted.
So copying it from /sdcard will likely be too late in the boot process.
Pushing directly into /data does not work either as you would have to be root. In the old days you could run and in root mode but I'm not sure that is still possible.
Factory reset will work.
On devices with separate recovery partition it would be possible to change recovery to allow adb access to /data so then push old file via recovery... But I would not know how to do that on Pixel as recovery is s part of the boot partition.
So effectively, it's likely you're only solution is to do a full firmware flash along with wipe.
I would first try a full flash removing the -w to avoid the wipe. It may work.
TonikJDK said:
I would first try a full flash adding the -w to avoid the wipe. It may work.
Click to expand...
Click to collapse
Probably a typo, but I think you meant you need to "remove" the -w to avoid a wipe.
Lughnasadh said:
Probably a typo, but I think you meant you need to "remove" the -w to avoid a wipe.
Click to expand...
Click to collapse
Thank you! My post is fixed.
TonikJDK said:
I would first try a full flash removing the -w to avoid the wipe. It may work.
Click to expand...
Click to collapse
Ok, I'm rooted so to be sure I don't mess anything up, lol can you list the steps just as a precaution?
Obviously I'd be in fastboot / recovery mode, then perform a flash-all but remove the -w so as to not erase my data?
Once the system boots, all of my texts and setup should remain as is, or do I have to go and recover it?
Would I be able to install the OS again on the inactive slot to recover data, or does that not work that way?
RetroTech07 said:
Would I be able to install the OS again on the inactive slot to recover data, or does that not work that way?
Click to expand...
Click to collapse
Nope ... there is only 1 data partition, so even when you flash the OS to the inactive slot, it would still use the same data partition. Moreover, it is then likely to upgrade/convert some files on /data which might result in not being able to go to the previous version in the old slot.
RetroTech07 said:
Ok, I'm rooted so to be sure I don't mess anything up, lol can you list the steps just as a precaution?
Click to expand...
Click to collapse
See https://forum.xda-developers.com/t/...thout-wiping-data-and-retaining-root.4356065/
so, unfortunately doing a full flash without wiping data didn't work. I'm almost inclined to believe that if TWRP was available for the P6/P, that I could go and push the file I had saved back into the directory of where it was and save myself from this mess.
I'm kicking myself because I'm usually backing up my data before I modify any system files, but this one time I hadn't done so and I had Google's backup turned off at the time, so I'm gonna have to lose some text messages over the last few days with some folks I enjoy speaking to. I do have some saved from late last week, but nothing from the weekend up until now.
As you said you can access ADB while booting, why not push/remove/replace the file while booting, even if this takes multiple boots to perform all commands, it should work assuming you can also use SU, if you can't, none of the below will work.
Code:
adb push <backup file location> /sdcard
adb shell
su
rm data/system/users/0/settings_ssaid.xml
cp /sdcard/settings_ssaid.xml /data/system/users/0/
chmod 600 data/system/users/0/settings_ssaid.xml
I don't know why it's affecting your boot though, there's a .fallback file that the system should fall back to when the system notes that this file is corrupt.
If the above doesn't work, and you could try:
Code:
adb shell
su
rm data/system/users/0/settings_ssaid.xml
cp /data/system/users/0/settings_ssaid.xml.fallback /data/system/users/0/settings_ssaid.xml
If that doesn't work, try:
Code:
adb shell
su
rm data/system/users/0/settings_ssaid.xml
And reboot, but again, I don't know why you're bootlooping from this, that file shouldn't be integral to booting.
Also, if you need to back up your data, why not just boot to boot_b, if it's not causing you issues? You really shouldn't have to reset your device to fix one problem - you could do a /data & /sdcard pull while booted to boot_b, or just run something like Titanium & SMS backup/restore.
DanielF50 said:
As you said you can access ADB while booting, why not push/remove/replace the file while booting, even if this takes multiple boots to perform all commands, it should work assuming you can also use SU, if you can't, none of the below will work.
Code:
adb push <backup file location> /sdcard
adb shell
su
rm data/system/users/0/settings_ssaid.xml
cp /sdcard/settings_ssaid.xml /data/system/users/0/
chmod 600 data/system/users/0/settings_ssaid.xml
I don't know why it's affecting your boot though, there's a .fallback file that the system should fall back to when the system notes that this file is corrupt.
If the above doesn't work, and you could try:
Code:
adb shell
su
rm data/system/users/0/settings_ssaid.xml
cp /data/system/users/0/settings_ssaid.xml.fallback /data/system/users/0/settings_ssaid.xml
If that doesn't work, try:
Code:
adb shell
su
rm data/system/users/0/settings_ssaid.xml
And reboot, but again, I don't know why you're bootlooping from this, that file shouldn't be integral to booting.
Also, if you need to back up your data, why not just boot to boot_b, if it's not causing you issues? You really shouldn't have to reset your device to fix one problem - you could do a /data & /sdcard pull while booted to boot_b, or just run something like Titanium & SMS backup/restore.
Click to expand...
Click to collapse
I appreciate the help but I can't go back as I've already wiped everything minutes before you sent this. If I had the above commands sooner I would have loved to try, although I'm not really sure why this became an issue in the first place. I tried booting to slot B, using both patched and normal boot images but it wasn't working, unless I did something wrong.
All I remember is installing an app to edit UDID for individual apps that I've used in the past, but because it wasn't identifying root properly, to which I'm assuming is an Android 12 issue, I decided to follow instructions for manually editing such IDs in the file I edited in my OP.
After I rebooted, I remember the main system about to start and seeing the Google boot logo with a percentage # go all the way up to 90%, then that's where the boot loop started. My guess at this point is either the app or the file I edited caused an issue, because I did nothing else up until that point. What's odd, is that after I formatted the whole system and rebooted, I saw the same percentage appear on screen after installing the same app to see if that was the issue, but it booted fully just fine.
I was going to just keep fighting this and keep the phone the way it was until I could maybe fix everything, but figured there's nothing I could do at this point since trying a flash of everything failed. I was up until 5am last night and it's almost 4 am with me trying to fix this. I feel defeated and upset because I don't believe I had to wipe this in the first place, and could have likely saved all of my data. I didn't have Google's backup option turned on and hadn't backed up my text messages because I was dumb. I'm more upset with myself than the phone honestly.
RetroTech07 said:
I appreciate the help but I can't go back as I've already wiped everything minutes before you sent this. If I had the above commands sooner I would have loved to try, although I'm not really sure why this became an issue in the first place. I tried booting to slot B, using both patched and normal boot images but it wasn't working, unless I did something wrong.
All I remember is installing an app to edit UDID for individual apps that I've used in the past, but because it wasn't identifying root properly, to which I'm assuming is an Android 12 issue, I decided to follow instructions for manually editing such IDs in the file I edited in my OP.
After I rebooted, I remember the main system about to start and seeing the Google boot logo with a percentage # go all the way up to 90%, then that's where the boot loop started. My guess at this point is either the app or the file I edited caused an issue, because I did nothing else up until that point. What's odd, is that after I formatted the whole system and rebooted, I saw the same percentage appear on screen after installing the same app to see if that was the issue, but it booted fully just fine.
I was going to just keep fighting this and keep the phone the way it was until I could maybe fix everything, but figured there's nothing I could do at this point since trying a flash of everything failed. I was up until 5am last night and it's almost 4 am with me trying to fix this. I feel defeated and upset because I don't believe I had to wipe this in the first place, and could have likely saved all of my data. I didn't have Google's backup option turned on and hadn't backed up my text messages because I was dumb. I'm more upset with myself than the phone honestly.
Click to expand...
Click to collapse
Ah damn, I was too late!
The 90% thing sounds like the November Google Play services updated - mine updated yesterday and I got the same thing when I rebooted, maybe something between the two got corrupt.
Yeah, I get that, I've had more than my fair share of self inflicted (and not so self inflicted) problems that have lost me data but you live and you learn I suppose