S5 G900F Strange Bootloop after FolderMove-- PLEASE HELP - Galaxy S 5 Q&A, Help & Troubleshooting

My plan was to use FolderMove to move some apps to the SD card.
I rooted the phone with CF-Autoroot and confirmed that FolderMove need to fix /bin/sdcard and another file.
Now the phone is stuck in bootloop. Sometimes it gets into the system, i see the taskbar and then it reboots.
I'm trying to get access to the adb shell to overwrite the changed files from backup.
How can i get to a shell? My fav would be a temporarily recovery. But can't find any for the S5.
I'm not sure if the OEM unlock option and/or the reactivationlock is unlocked.
This options are always mentioned in every tutorial, so i am unsure if i just can flash twrp.
Does anyone have another idea how i can get back to a working phone, without losing the data?

I solved the problem
I found the post from and got the filenames + permissions
https://forum.xda-developers.com/showpost.php?p=71580971&postcount=4380
To rename the files without fastboot or adb - thanks samsung - i used the CF-Autoroot Recovery.
I modified the installscript and voila, everything is working.
Unfortionatly it took me a few hours to get around how to modify and sign the script and to recognice that the system partiton isn't r/w because of the systemless root

Related

[Q] bricked after trying to install crt animation

Used root explorer to replace framework.res but before I could change the permissions (was busy backing up the old framework.res) my phone acted all weird with more and more programs crashing ,then root explorer crashed right begore I could change the permissions and then my device went into bootloop
My question is: Is there any way to fix my phone without having to lose radio functionality?
I can get into the bootloader (with the blue light) and fastboot recognises my device but adb doesn't. But I'm afraid that I'll lose my radio when using the method for bricked xperia plays. I know what file the problem is with /system/framework/framework.res and that it's most likely the permissions. Also I got a backup of the original file on my SD card.
Got an unlocked bootloader, the device is rooted and it boots as long as it normally takes to get to the part where you have to slide to unlock. Got busybox installed.
just flash Bin4ry's system.img with fastboot this will restore the framework without loss.
http://forum.xda-developers.com/showthread.php?t=1043630
That fixed it, thanks.

Device Encryption and Root

Hi everyone,
it's my first post on the xda-developers forum, so if the kind of my posting mismatches any rules, please let me know!
I'm using this forum for quite long time now, but so far all of my questions were answered by search & read... Some weeks ago I had another question, for which I colun't find an explicit answer yet. So based on some hints from different sources (thanks to google!) I did some experiments aka try and error and would like to share my experience with you (to give something back to the comunity, who helped me a lot in the past) and see whether I finally found the answere to my question... So please let me know, whether it worked for you as well or whether you know a different / better way to solve this kind of problem.
As usual: Use this guide at your own risk!
Problem statement:
I wanted to have my SM-P900 (stock rom) both rooted and encrypted (using device encryption). I've already done this for GT-I9100 (Galaxy S II) and GT-I9192 (Galaxy S4 Duo) in the past and it worked like a charme. But for some reason I couldn't get it working on the SM-P900...
Trial log (for short version see below):
I have successfully rooted this device via the CF-Auto-Root method by Chainfire (many thanks for the greate job!). When I later tried to activate the device entcryption, it first looked like the process has started (I got a black screen with a green android manikin), but after some time (~1min) the device just re-started and booted in normal mode. I tried it several times with the same end of story - no success, no harm either.
After some time of googling I found a hint, that on KitKat devices Superuser should be temporarily de-activated in order to get the device encryption starting properly and activate it after the encryption process has finished. So I tried that and indeed, this time the encryption process started after the reboot. I let it finish and after a reboot it looked like I was where I wanted to be at. But then I realized that I wasn't able to activate the Superuser back (SuperSU said "Can't find the su binary... You need to restore it manually" or something similar). Damned! I thought "OK, let's try CF-Auto-Root again". The root process itself seemed to work, but after that the device just hang at boot... Soft-brick... :crying:
Taking a more deeper look at the script source of an Update-Super-SU package from Chainfire I realized that it also does some writes to the /data partition. Well, I guess this broke the partition, since it was encrypted... (If anyone has a better explanation for this, please let me know!)
So everything back to the start: I flashed the stock rom, did a factory reset and re-ran CF-Auto-Root... Now the device was operating properly and was rooted, but no encryption. Before starting another try of encryption, I wanted verify that the temoprary un-root wasn't broken by the encryption. So I did a temorary un-root (by removing the tick at the option "Activate Superuser" in SuperSu settings) and then activated it back right away. This worked fine. I rebooted (just to confirm everything is still working) and Superuser still worked as expected. Then (to try one more thing) I "de-activated" su again and rebooted. Trying to activate it back after the reboot, I realized that I now was at the same situation as just after the encryption, but without the encryption. I.e. the problem was not the encryption itself, but kind of a bug in SuperSU - it was not able to activate su back after a reboot (I'll try to check it via a bug report to Chainfire).
So I digged a bit deeper into this and realized that SuperSU was simply deleting the su binary in /system/xbin on de-activation and writing it back on activation. And it looked like it wasn't able to write it back after a reboot (probably because of missing permission).
Knowing that, I decided to go a step further: I flashed the TWRP (many thanks to the TeamWin guys!), booted into recovery, mounted /system and copied the su binary manually to /system/xbin. After a reboot I tried once again open SuperSU, but it still said, it couldn't find the su binary. Hmmm... There must be something more... Having another look at the script source of the Update-Super-SU package I found that at the end it was calling the su binary with the option "-install". So I booted back to recovery and tried that as well... Hurra!!! After a reboot SuperSU was finally starting and the root-apps were able to get su access... So this seemed to be the desired solution.
I deactivated su again, rebooted and started the encryption. It ran and finished successfully, as expected. After that I booted to recovery and installed su manually, as I've done it before... Reboot... finger crossed... Tadaa!!! System is back, encrypted and root is working! :good:
Solution approach:
Device is not rooted and not encypted (if already rooted, scip 2; if already encrypted, decrypt or do a factory-reset - don't try CF-Auto-Root on an encrypted device, it'll soft-brick)
Root the device (e.g. using Auto-Root-CF by Chainfire (it'll trigger the Knox-counter)
Temporarily un-root the device (when using SuperSU: go to Settings and remove the tick at the option "Activate Superuser")
Reboot
Activate the device encryption (the battery must be at least at 80% and the device must be plugged in the wall charger)
The device will restart after a short period of time and start the encryption (this will take some time, but you should see a progress bar indicating how far it is)
After the encryption is finished the device will reboot and ask for the password, just log in
If not yet done, flash a custom recovery where you have a console access or can use ADB as root (I used TWRP)
Boot into recovery
Mount /system (it's not mounted automatically, at least not in the version I used - TWRP 2.7.1.0).
Open the console or ADB shell
Copy the su binary (if you use SuperSU: cp /system/xbin/daemonsu /system/xbin/su)
Execute the installation (if you use SuperSU: /system/xbin/su --install)
Reboot
You should be done
Thank you for the info and the simple steps. I was considering something similar to what you wanted with your device.
bruzzy,
I've followed your steps and managed to re-enable SuperSU after encryption! (used twrp)
Thank you!!!!!
Hello Bruzzy,
Thanks so much for the awesome post!
I am just having difficulty with the final steps. I am a complete newbie in regards to rooting and using these android tools.
Everything else was quite clear in your post except for these final steps.
Could you please simply a bit more step by step how I proceed to do the final steps listed below?
[*]Mount /system (it's not mounted automatically, at least not in the version I used - TWRP 2.7.1.0).
[*]Open the console or ADB shell
[*]Copy the su binary (if you use SuperSU: cp /system/xbin/daemonsu /system/xbin/su)
[*]Execute the installation (if you use SuperSU: /system/xbin/su --install)
[*]Reboot
Thanks so much!
EndlessAdventurer
bruzzy said:
Hi everyone,
it's my first post on the xda-developers forum, so if the kind of my posting mismatches any rules, please let me know!
I'm using this forum for quite long time now, but so far all of my questions were answered by search & read... Some weeks ago I had another question, for which I colun't find an explicit answer yet. So based on some hints from different sources (thanks to google!) I did some experiments aka try and error and would like to share my experience with you (to give something back to the comunity, who helped me a lot in the past) and see whether I finally found the answere to my question... So please let me know, whether it worked for you as well or whether you know a different / better way to solve this kind of problem.
As usual: Use this guide at your own risk!
Problem statement:
I wanted to have my SM-P900 (stock rom) both rooted and encrypted (using device encryption). I've already done this for GT-I9100 (Galaxy S II) and GT-I9192 (Galaxy S4 Duo) in the past and it worked like a charme. But for some reason I couldn't get it working on the SM-P900...
Trial log (for short version see below):
I have successfully rooted this device via the CF-Auto-Root method by Chainfire (many thanks for the greate job!). When I later tried to activate the device entcryption, it first looked like the process has started (I got a black screen with a green android manikin), but after some time (~1min) the device just re-started and booted in normal mode. I tried it several times with the same end of story - no success, no harm either.
After some time of googling I found a hint, that on KitKat devices Superuser should be temporarily de-activated in order to get the device encryption starting properly and activate it after the encryption process has finished. So I tried that and indeed, this time the encryption process started after the reboot. I let it finish and after a reboot it looked like I was where I wanted to be at. But then I realized that I wasn't able to activate the Superuser back (SuperSU said "Can't find the su binary... You need to restore it manually" or something similar). Damned! I thought "OK, let's try CF-Auto-Root again". The root process itself seemed to work, but after that the device just hang at boot... Soft-brick... :crying:
Taking a more deeper look at the script source of an Update-Super-SU package from Chainfire I realized that it also does some writes to the /data partition. Well, I guess this broke the partition, since it was encrypted... (If anyone has a better explanation for this, please let me know!)
So everything back to the start: I flashed the stock rom, did a factory reset and re-ran CF-Auto-Root... Now the device was operating properly and was rooted, but no encryption. Before starting another try of encryption, I wanted verify that the temoprary un-root wasn't broken by the encryption. So I did a temorary un-root (by removing the tick at the option "Activate Superuser" in SuperSu settings) and then activated it back right away. This worked fine. I rebooted (just to confirm everything is still working) and Superuser still worked as expected. Then (to try one more thing) I "de-activated" su again and rebooted. Trying to activate it back after the reboot, I realized that I now was at the same situation as just after the encryption, but without the encryption. I.e. the problem was not the encryption itself, but kind of a bug in SuperSU - it was not able to activate su back after a reboot (I'll try to check it via a bug report to Chainfire).
So I digged a bit deeper into this and realized that SuperSU was simply deleting the su binary in /system/xbin on de-activation and writing it back on activation. And it looked like it wasn't able to write it back after a reboot (probably because of missing permission).
Knowing that, I decided to go a step further: I flashed the TWRP (many thanks to the TeamWin guys!), booted into recovery, mounted /system and copied the su binary manually to /system/xbin. After a reboot I tried once again open SuperSU, but it still said, it couldn't find the su binary. Hmmm... There must be something more... Having another look at the script source of the Update-Super-SU package I found that at the end it was calling the su binary with the option "-install". So I booted back to recovery and tried that as well... Hurra!!! After a reboot SuperSU was finally starting and the root-apps were able to get su access... So this seemed to be the desired solution.
I deactivated su again, rebooted and started the encryption. It ran and finished successfully, as expected. After that I booted to recovery and installed su manually, as I've done it before... Reboot... finger crossed... Tadaa!!! System is back, encrypted and root is working! :good:
Solution approach:
Device is not rooted and not encypted (if already rooted, scip 2; if already encrypted, decrypt or do a factory-reset - don't try CF-Auto-Root on an encrypted device, it'll soft-brick)
Root the device (e.g. using Auto-Root-CF by Chainfire (it'll trigger the Knox-counter)
Temporarily un-root the device (when using SuperSU: go to Settings and remove the tick at the option "Activate Superuser")
Reboot
Activate the device encryption (the battery must be at least at 80% and the device must be plugged in the wall charger)
The device will restart after a short period of time and start the encryption (this will take some time, but you should see a progress bar indicating how far it is)
After the encryption is finished the device will reboot and ask for the password, just log in
If not yet done, flash a custom recovery where you have a console access or can use ADB as root (I used TWRP)
Boot into recovery
Mount /system (it's not mounted automatically, at least not in the version I used - TWRP 2.7.1.0).
Open the console or ADB shell
Copy the su binary (if you use SuperSU: cp /system/xbin/daemonsu /system/xbin/su)
Execute the installation (if you use SuperSU: /system/xbin/su --install)
Reboot
You should be done
Click to expand...
Click to collapse
@EndlessAdventurer,
I'm sorry, but I don't know, what you mean with "more step by step". There are no more steps in between, the steps are as granular as possible. If you use TWRP, there is a menu "Mount" (go there and tick /system) - you should have seen it already (if not, have a look at the TWRP documentation). But you could also mount your system from the console or ADB shell.
If you don't know, what "mount", "console" or "ADB" is and are not able to use google to lern it yourself, then you should really not use this guide and even avoid rooting your device...
Beeing a newbie is not an excuse, it's completely up to you to spend some time and change this!
Please avoid quoting the whole post! If you want to reference some part of a post, pick only the relevant part and quote that.
Alternative Method
Hi,
I have used another method that also works. It worked with my Galaxy S4, Note 10.1 and now with Note Pro. Hope this can help:
1-Root your device and install/update SuperSu;
2-Convert SuperSu to system app (there is an option in SU config). Reboot.
-OBS: If your root method has already installed SuperSu as a system app, this step can be skipped;
3-As SuperSu is now a system app, it can be deactivated through Applications Management in settings. Deactivate it;
-OBS: does NOT use deactivate in SU own config;
4- Reboot in Safe Mode. This can be done pressing both Volume Up/Down while rebooting;
5-Start encryption the normal way and wait until it finishes. Enter your password and wait device boot normally;
6-Go to Applications Management in settings and activate SuperSu;
7-Reboot one more time and your system is encrypted with SuperSu working normally.
I was able to follow all of the posted solutions through but for some reason my phone insists on just booting back into Android instead of actually encrypting my phone. Any ideas?
I have a SM-G900T, TWRP, SuperSU
m33rkat said:
I was able to follow all of the posted solutions through but for some reason my phone insists on just booting back into Android instead of actually encrypting my phone. Any ideas?
I have a SM-G900T, TWRP, SuperSU
Click to expand...
Click to collapse
There is some more things that you can try with the solution I´ve posted:
1-Put original recovery instead of TWRP. I have never tried to encrypt with custom recovery;
2-When you boot in "Safe Mode", go to Application Management, running applications and stop as much processes as you can (do not stop google services).
OBS: To ensure that you have booted in Safe Mode, look at the bottom left corner of the screen an see if it shows “Safe Mode”.
rooting and encrpytion
The alternative method worked like charm....Thanks guys
NB:My tab got soft bricked after I did the factory reset and tried to root. I had to install a stock rom b4 proceeding with the guide.
Sorry to resurrect this thread but I just ran into this issue for the first time. (Thanks for posting this, btw, it's encrypting as we speak). A couple questions....what happens if we apply an OTA update after doing this? Will that cause any problems when we try to re-root it? I'm guessing after doing this CF Auto root won't be much of an option without soft bricking, right? I can always install custom recovery and fix root manually after an OTA. I'm just wondering what happens when (you know, some year) we eventually get 5.0. Thanks again!
To be on the safe side, I always unencrypt my device before a FW update with ODIN or Kies or OTA, because I root again after the update.
If you use OTA or Kies you can do the update with the device encrypted, BUT, as you are going to root again, when you install CFAutoroot your device won´t boot, because of the difference in kernel. This is the reason that I unencrypt before FW updates and proceed with encryption again after I check that everything is working as expected.
I may just fully unroot it temporarily, install the update, and then root after with custom recovery. We shall see. I suspect since we're still on 4.4.2 on the Note 10.1 2014 I got quite some time before I have to worry about it. LOL
P.S. I asked because 5.0 is going to turn encryption on by default, so decrypting may not be an option going forward.
After hours of trying to get encryption an root at the same time for my Galaxy Note 10.1 (2014), temporary disabling SuperSU just worked. Thanks! :good: (I even could skip the part with copying the su binary, probably chainfire has fixed the bug. Just tried enabling SuperSU did it perfectly.)
Hi there
I'm facing a similar problem like you on my Samsung Galaxy Tab S 10.5 LTE.
I have my device:
- rooted
- twrp recovery installed
- run custom ROM
However even when I disable SuperSU and reboot the device and then start encrypting. I only see the Android Logo and no progress. AFter a while (10 minutes or so), it reboots the tab and I end ab at screen lock login and devices is not encrypted. Any ideas?
Thank you for your great effort to help!
But, none of the methods, including the alternative from Nickfreedom did not help me...
I have a Sony Xperia Z1 with rooted Lollipop and SuperSU.
I tried to kill daemonsu with ADB before encrypting, I tried to disable the SuperSU app and I always booted into safe mode before starting encryption.
Nothing helped.
In previous times I had Xposed framework on my device, but as far as I can see, Xposed framework is no longer on my device, I installed a fresh, clean Sony ROM from scratch, I think this has erased Xposed.
Does anyone has a hint?
Thanks to everyone for the posts on this topic. I too have struggled to get my Sprint Note 4 to encrypt after rooting. I was able to encrypt with the stock unrooted ROM but I flashed the Noterized ROM and was not able to get encryption to work. I have verified the following:
1) Busybox is installed and is the latest version
2) SuperSU is deactivated. I tried this through terminal emulator and also the process defined in this thread within the SuperSU app itself. I also verified through Root Checker that SU was not active.
3) Tried in normal and safe mode with the same result
I am getting the Android screen for a few minutes and then the phone reboots. Each time I was hoping to see the encryption start but it just reboots the phone and never works. I am at a total loss for what could be causing this as the reason is beyond my capability. If anyone has ideas let me know because I am willing to try anything.
As a longshot I tried to flash back to stock ROM and encrypt which worked fine. I then tried to flash the Noterized ROM back on the phone and that didn't work. I froze on the Sprint yellow screen of death for over 6 hours.
Simplified steps for rooting &encrypting your device.
Thanks Bruzzy, I took your instructions and applied them to the Note 4. I also simplified them. I will make a universal instructions set for pretty much ALL DEVICES! Will let you guys know here when i take the time to do that.
Here is the SIMPLIFIED INSTRUCTIONS:
http://forum.xda-developers.com/not...sk-encryption-root-easy-steps-how-to-t3197425
bruzzy said:
Solution approach:
Device is not rooted and not encypted (if already rooted, scip 2; if already encrypted, decrypt or do a factory-reset - don't try CF-Auto-Root on an encrypted device, it'll soft-brick)
Root the device (e.g. using Auto-Root-CF by Chainfire (it'll trigger the Knox-counter)
Temporarily un-root the device (when using SuperSU: go to Settings and remove the tick at the option "Activate Superuser")
Reboot
Activate the device encryption (the battery must be at least at 80% and the device must be plugged in the wall charger)
The device will restart after a short period of time and start the encryption (this will take some time, but you should see a progress bar indicating how far it is)
After the encryption is finished the device will reboot and ask for the password, just log in
If not yet done, flash a custom recovery where you have a console access or can use ADB as root (I used TWRP)
Boot into recovery
Mount /system (it's not mounted automatically, at least not in the version I used - TWRP 2.7.1.0).
Open the console or ADB shell
Copy the su binary (if you use SuperSU: cp /system/xbin/daemonsu /system/xbin/su)
Execute the installation (if you use SuperSU: /system/xbin/su --install)
Reboot
You should be done
Click to expand...
Click to collapse
Did you solve your problem whit encryption on t805 ?
sjau said:
Hi there
I'm facing a similar problem like you on my Samsung Galaxy Tab S 10.5 LTE.
I have my device:
- rooted
- twrp recovery installed
- run custom ROM
However even when I disable SuperSU and reboot the device and then start encrypting. I only see the Android Logo and no progress. AFter a while (10 minutes or so), it reboots the tab and I end ab at screen lock login and devices is not encrypted. Any ideas?
Click to expand...
Click to collapse
Did you solve your problem whit encryption on t805 ?
I have the same problem on T800 on 5.0.2.
On 4.4 encryption whit CFroot works good, but on 5.0.2 its not work
Vitaly_G said:
Did you solve your problem whit encryption on t805 ?
I have the same problem on T800 on 5.0.2.
On 4.4 encryption whit CFroot works good, but on 5.0.2 its not work
Click to expand...
Click to collapse
Hi guys,
there is an alternative instruction from Nickfreedom in my original thread: http://forum.xda-developers.com/showpost.php?p=54679223&postcount=6
I used for several devices and it works like charme (and is much simpler)...
Hey guys this is probably a dumb question but what is the advantage of encryption and does it matter if the knox is tripped since these notes are out of warranty or is it due to resale? I found a cf autoroot link that supposedly wont trip knox which is the odin method since towelroot wont work.

[Q] Can someone help me resolve a root access issue?

I have a Advent Tegra Note 7
Upgraded to kitkat and OTA 2.4.1
Used Tomsgt supertool 2.4.1 tool to root, installed TWRP (and made a backup image of my freshly installed system)
I've since added some games and apps and spent a fair bit of time customizing the system, but when I attempt to run Titanium Backup it tells freezes when "asking for root rights" so I ran "root checker basic" from playstore, which tells me I don't appear to have proper root access..
Here's a break down of what I've done, I've tried to keep it conscise...
I have tried installing a SuperSU, SuperUser and SU Update fixer, Also reinstalling the SuperSU-v1.94.zip using both cwm and twrp... Still no proper root access.
Ideally I'd like to try some other things to get root access before reflashing and having to reinstall my apps and settings, can anyone help or suggest anything else I could do.? I can't think of anything I could of accidentally done to break root access, this is still quite a clean system just setup in the past two days.
P.S.When using the supertool impacter tool and scan for usb driver I get a "no such device" error, even though the device is listed in the previous screens.. also I suspect the correct drivers are there as ADB seems to work fine
they flashing SuperSU-v1.99r4.zip from http://download.chainfire.eu/447/SuperSU/. I haven't had issues with root via either method.
If that fails you can use the n7root.img which is downloadable here: https://github.com/linux-shield/shield-root/blob/master/root_tn7.img?raw=true then go into fastboot mode and then type fastboot boot root_tn7.img. DO NOT USE FASTBOOT FLASH BOOT with this image as it will make it bootloop, just use fastboot boot command.
SOLVED
Thanks for the pointers hacktrix2006.. I tried supersu-v1.99r4.zip also v2 no luck. Had a quick look for how to get into fastboot mode.. couldn't access it from the bootloader.. so decided to take a backup image and restore to stock kitkat 4.4.2 via tomsgt latest tool 2.4.1 including doing Wipe data. then reinstalled TWRP then applied root.... AND noticed a screen saying something like ROOT ACCESS MAY BE FAULTY.. WOULD YOU LIKE TO FIX THIS.. I also think there was a warning about "be careful this action is irreversable" - I suspect the previous time I hadn't understood this properly and selected NO !! Anyway this time I said yes and now have ROOT YAY!
Now I start a re setup of the system and installation of apps etc.. I guess it's often a bit smoother 2nd (or 3rd 4th etc) time around
OK thx again for the encouragement, plus now I have a little more experience to offer someone else who may be struggling in this area.
no problem!

[Q] Help! Just broke my services.odex and cant get into my phone.

I was trying to unlock my wifi tether by editing services.jar. I renamed both services.jar and services.odex by adding ".bak" I replaced services.jar with the recompiled one but didn't replace services.odex. now when my phone boots up I get "unfortunately verizon login has stopped" as well as a few others and I can't get in. What can I do to fix this? Its a verizon S5 with the march 31 kernel version.
Restore your backup. Or you could replace just the files you renamed with an ADB shell session and push the required files. Or "dirty' flash just the system files. Or write a full, stock firmware image with Odin.
Those would be some of the ways to recover. Lots of existing threads on this, with further elaboration if you need further guidance.
.
fffft said:
Restore your backup. Or you could replace just the files you renamed with an ADB shell session and push the required files. Or "dirty' flash just the system files. Or write a full, stock firmware image with Odin.
Those would be some of the ways to recover. Lots of existing threads on this, with further elaboration if you need further guidance.
.
Click to expand...
Click to collapse
I don't have a backup or custom recovery, I just used towelroot and thought it would be pretty safe to unlock the wifi tether. I think I forgot to turn on USB debuging so I think ADB is out of the question. Is there a way to "dirty flash" with Odin?
Edit: just did a reset with Odin, this fixed the problem. The phone was new so there wasn't much on it and I do keep my contacts and messages backed up so not much is lost except for the inconvenience of setting everything back up. I will definitely be more careful in the future.

[Q] What can I do with system dump?

Can I recover my dead SG5 with system dump via CWM?
What can I do with it?
It is far from clear what you want to know?
You didn't say what happened to your phone, why it is "dead" or exactly what you mean by dead. CWM is a custom recovery but you didn't even tell us if you had it instlaled and therefore presumably have backups. Or if you are hopeful that CWM will fix your unspecified problem. And system dump is a vague term usually referring to making a backup on the command line using the dd utility.
We need a lot more information if you need help with something. Such as what happened to your phone, whether it boots to recovery or download mode, loads an ADB shell and so forth.
.
fffft said:
It is far from clear what you want to know?
You didn't say what happened to your phone, why it is "dead" or exactly what you mean by dead. CWM is a custom recovery but you didn't even tell us if you had it instlaled and therefore presumably have backups. Or if you are hopeful that CWM will fix your unspecified problem. And system dump is a vague term usually referring to making a backup on the command line using the dd utility.
We need a lot more information if you need help with something. Such as what happened to your phone, whether it boots to recovery or download mode, loads an ADB shell and so forth.
.
Click to expand...
Click to collapse
[Q] Somebody give me SCL23's build.prop(original)
I changed build.prop
My android phone is SCL23
AKA Galaxy S5
I am Korean but now I live in Japan for work.
So I used GalaxyS5 for KDDI AU
Some application didn't work on my phone.
Even impossible to install
So I tried to root. Then changed model and vendor from GalaxyS5 to Galaxy S4
But it didn't work for using those apps
So I copy all of texts of build.prop of GalaxyS4.
Then my phone dead.
AU's logo is the only thing I can see.
Before did that
I had do googling and find SCL23's CWM with Chinese letters.
It works well.
Factory reset? YES
Boot? NO
Can not normal boot
Odin mode
I connected phone to PC.
Fail to install USB driver.
I think it cause of phone's hardware and build.prop is not same.
I have external SDCard.
Odin work via USB
And I can go into CWM recovery mode.
So I think if I can find .zip, able to flash, of SCL23's build.prop
I can copy it into extsdcard with friend's android
Then go into CWM and flash it.
I need SCL23's build prop
And somebody make it .zip please
I don't know how to make it.
Please help me.
And thank you for read this poor English
fffft said:
It is far from clear what you want to know?
You didn't say what happened to your phone, why it is "dead" or exactly what you mean by dead. CWM is a custom recovery but you didn't even tell us if you had it instlaled and therefore presumably have backups. Or if you are hopeful that CWM will fix your unspecified problem. And system dump is a vague term usually referring to making a backup on the command line using the dd utility.
We need a lot more information if you need help with something. Such as what happened to your phone, whether it boots to recovery or download mode, loads an ADB shell and so forth.
.
Click to expand...
Click to collapse
I wrote it few days ago.
Nobody replied to me.
So I thought many ways and did googling for recover.
I found link of system dump of SCL23.
So now I want to know about what can I do with it for my android phone's revive.
Please help me
If you have a system dump made while your phone was working properly, you can simply restore that to resolve your problems. It's not clear that that is the actual case though.
In the alternative, the apparent cause of your problems is a non-viable build.prop. You should be able to boot to CWM and then use a ADB shell under CWM to rename or delete /sideload the bad build.prop file and replace it with a good copy. If you didn't keep a good copy, you can download the stock firmware for your phone and use winrar to extract the proper stock build.prop for your phone.
More than likely, if you can boot to recovery mode, then you will be able to boot to download mode as well. So Odin use should be possible. You can use Kies to install a driver. But try CWM first.
.
fffft said:
If you have a system dump made while your phone was working properly, you can simply restore that to resolve your problems. It's not clear that that is the actual case though.
In the alternative, the apparent cause of your problems is a non-viable build.prop. You should be able to boot to CWM and then use a ADB shell under CWM to rename or delete /sideload the bad build.prop file and replace it with a good copy. If you didn't keep a good copy, you can download the stock firmware for your phone and use winrar to extract the proper stock build.prop for your phone.
More than likely, if you can boot to recovery mode, then you will be able to boot to download mode as well. So Odin use should be possible. You can use Kies to install a driver. But try CWM first.
.
Click to expand...
Click to collapse
I tried everything you told to me.
But very problem is install USB driver.
Kies failed to find and install USB driver. It worked well before I did it.
So I can not do anything with ADB commands because of USB driver.
But only Odin work to phone.
So I can install CWM. And I can go into CWM recovery mode.
Of course I can go to Download mode.
Can I do something with Linux?
Can I mount My Phone with Linux without install USB driver and then change build.prop.bak to build.prop?
I really appreciate to your reply.
Thanks to your kindness.
If your USB driver was properly installed before the problem, it will continue to work just fine, at least for CWM mode. Build.prop will not interfere with that. So just go to the CWM command line and use the ADB commands to push (replace) the build.prop file.
Are you certain that Odin doesn't recognize the phone in download mode. Ensure that you are entering download mode by removing the phone battery, replacing it, then pressing and holding in order, the volume down, then home, then power key until you see the screen light up. Odin should see the phone and it should not matter if the build.prop file is corrupt. Only the normal boot will be affected by that.
If you have problems connecting ADB or Odin, a far more likely suspect is a bad USB cable. Try a different cable or USB port. And ensure that you are entering download mode in the manner described above. When Odin recognizes your phone, you can write a stock firmware image to you phone to recover.
I haven't used CWM for quite a while (I much prefer TWRP), but it should offer you a command line. So as an alternative, use your PC to write a good copy of the build.prop file to your SD card. Then in CWM you could mount the external SD card, then copy the file from the card to your system directory. In this method, you wouldn't even require the USB driver.
You have lots of options and there are lots of ttutorials on using CWM, ADB and so forth if you need elaboration. You should certainly be able to resolve this issue even though it may be a pain in the neck or somewhat intimidating if it is unfamiliar territory. Nevertheless you can fix it if you are patient.
If the worst case,an alternative would be to pay a cellular repair shop to do the software repair for you. Entirely up to you which is the better approach.
.

Categories

Resources