With Titanium Backup, when you backup your apps and other files it creates a folder full of files that only it can read. When I flashed Jasmine, I copied those files to my computer and then flashed, then redownloaded Titanium Backup and moved those files as well as the license back into the correct folders. Is this the correct way to use TB, or is there a route that I am missing? It worked fine, just not sure if it is the recommended way of use or not.
More or less.
The folder is usually in the /sdcard area which is NOT wiped by custom recovery (default) "factory reset", so I'm not sure there is any reason to back it up and restore it. If you are using the default wiping method in TWRP, the (internal, psuedo-) /sdcard folder is not wiped.
But there's no harm in a PC backup. A backup that goes unused can just be deleted some time down the road; disk space is cheap & it's there in a disaster. The same can not be said for not making backups.
Warning: since you are newish to this stuff this behavior is VERY different in stock recoveries - the stock recovery version of "factory reset" wipes out EVERYTHING. In that case it would be mandatory that you backup the entire /sdcard if you want to save things. It's a little bit unfortunate that Android named this type of procedure "Factory Reset" instead of something more accurate, which would be something like "User Data Wipe", as it leads new rooters to erroneously conclude that random modifications to the /system and boot partitions can be un-done using something called "factory reset". NOT TRUE AT ALL; IT'S JUST FOR WIPING USER DATA.
Different apps use different strategies for "Pro" version licensing. If they stick with the Google Play ("market") best-practice recommendations, there shouldn't be any need to manipulate license files, so long as the app is downloaded from the Play Store with the same google login that was used to originally purchase the app. But I can't say for sure if that's the mechanism with TiBu.
I use TiBu kind of sparingly - typically only for market apps I am interested in, and even in those cases I usually download the app from the market and restore only the data from TiBu (to avoid missing market registration bugs, etc). Folks on small data plans might have different ideas about it because of data usage issues (and timeliness of restore procedures). I don't use TiBu for things like backup of data stores for launcher apps, ROM frameworks (e.g. "Settings"). There probably is some degree of compatibility from ROM to ROM with those items, but it is certainly not guaranteed. (Things like word dictionaries & dialer blacklists fall into this category - it would be nice if they were guaranteed to be compatible, but there is no way to know in advance. You sort of have to experimentally determine whether you have broken anything.)
Alternatively, you could keep a copy of the TiBu .apk file in your SD card somewhere. That would allow you to do whatever restores you like without connecting to the Google Play market. Just copy it to /data/app using TWRP after flashing/wiping and then on first boot it will be ready to do your restores.*
* in TWRP via Advanced -> Terminal
This requires getting comfortable with a minimum number of Unix command line commands, e.g. "cd", "cp", "ls", "pwd", etc.
I did download it from the store, but had previously read that the license would need to be moved in a thread not on this website. When I redownloaded it from the store, it automatically added the license back, so I ended up not needing it.
I only use TB to backup things like my offline games I want my scores saved, or apps that it logs me back into when it loads it back (Facebook, Reddit, Messenger, Twitch, Twitter, etc).
What I was looking to do was just keep the files for the backups of those apps on my SD card (or whatever is the recommended method), rather than stored to the phones internal memory since it gets wiped during the reset.
Your internal /sdcard should not be getting wiped by TWRP's default wipe method (which is used for installing ROMs for instance). You would have to go into the Advanced Wipe submenu for that to happen. A stock recovery "factory reset" would nuke the "internal" /sdcard though.
That said, there is nothing wrong with having backups off the device - especially for people that remain on a locked bootloader and do not have a (independent boot) custom recovery.
TiBu has a place in its settings where you can choose to place it's backups on the external sdcard if you want to do that. Then they would be safe from any type of factory reset, and could be retrieved if the phone suddenly died.
Related
I don't know if I'm the only one having this issue, but I'd figure I'd lay out my findings for everyone to see if we can get to the bottom of it. Since the EB01 leak was released, I've noticed that after a while my installed apps will not remember their preferences anymore, think everytime is the first run, etc...
First time I flashed EB01 was using ROM Manager and an old "green" version of CWM. After the first instance of these issues cropping up, I went back DI01 using a FULL Odin restore (rom, kernel, radio, novinand, etc, w/ re-partitioning), then flashed to an EB01+CWM+Root package using Odin instead of CWM. Again, after a day or two, apps started forgetting their preferences. I then got a new phone as a warranty replacement, went from EA28 to EB01 using Odin: still having the same issues.
The only thing I noticed out of place (I'm no developer) in a logcat trace is:
Code:
Line 745: E/ApplicationContext(31797): Couldn't rename file /dbdata/databases/com.speedsoftware.rootexplorer/shared_prefs/com.speedsoftware.rootexplorer_preferences.xml to backup file /dbdata/databases/com.speedsoftware.rootexplorer/shared_prefs/com.speedsoftware.rootexplorer_preferences.xml.bak
Line 745: E/ApplicationContext(31797): Couldn't rename file /dbdata/databases/com.speedsoftware.rootexplorer/shared_prefs/com.speedsoftware.rootexplorer_preferences.xml to backup file /dbdata/databases/com.speedsoftware.rootexplorer/shared_prefs/com.speedsoftware.rootexplorer_preferences.xml.bak
Line 745: E/ApplicationContext(31797): Couldn't rename file /dbdata/databases/com.speedsoftware.rootexplorer/shared_prefs/com.speedsoftware.rootexplorer_preferences.xml to backup file /dbdata/databases/com.speedsoftware.rootexplorer/shared_prefs/com.speedsoftware.rootexplorer_preferences.xml.bak
Line 745: E/ApplicationContext(31797): Couldn't rename file /dbdata/databases/com.speedsoftware.rootexplorer/shared_prefs/com.speedsoftware.rootexplorer_preferences.xml to backup file /dbdata/databases/com.speedsoftware.rootexplorer/shared_prefs/com.speedsoftware.rootexplorer_preferences.xml.bak
Just a few other things I've noticed
*System application do not seem to be affected
*/dbdata/databases/ is full if entries for apps that are no longer installed. I don't know if that is normal or if they are supposed to be cleared out when an app is removed.
*deleting the entry in /dbdata/databases/ for a particular app seems to force it re-create the entry, allowing it save it's preferences.....until they change again.
*reading from dbdata seems to work fine, just writing isn't working.
*only certain apps seem to act up. The first ones to show signs of issues are usually Tapatalk, Root Explorer, & Titanium Backup. Apps like Dropbox and Facebook don't seem to be affected this time around.
I question weather this a corruption due to the installation method (outdated CWM) or a bug in EB01 itself and only folks who add/delete apps frequently like myself are more prone to notice it.
Thoughts?
First, this shouldn't be posted here. This has nothing to do with Development, so it should have gone in the General forum.
Next, have you tried to do a factory reset after the issue pops up and try again? I realize that you did the full Odin wipe, but did you try wiping data anyway? Also, are you on Voodoo or no-voodoo?
1. Apologies, I figured since this was an issue with software under development and is likely a code issue, that it belongs here more than anywhere.
2. Yes, many wipes of data & cache partitions, restores to DI01, etc. The full restore & re-formatting was a last resort. Plus, it's doing the same thing with an entirely new device.
3. Non-voodoo
What I would suggest is reset your phone and reset your data restoring, AKA clearing it from google's servers the best way to do that is reflash a froyo rom, wipe all the cache's and then when it asks you to login with your google account skip that step and then login using Settings->Accounts & Sync add your google account And then in Settings->Privacy Uncheck Backup my data and Automatic Restore. There is a chance there is a app or a setting being pulled from google that could be screwing it up, you could also try formating your SD card.
You mentioned Titanium Backup. It has an "Auto-sync TB settings" is supposed to auto restore it's settings from the SD card after a wipe. Maybe you have a setting in there that is causing an auto-restore to happen of the data from some of your apps.
And definitely check to make sure that you don't have Automatic Restore checked in Settings->Privacy. The best way to do this is just like jazzyjames mentioned. After a wipe, don't log into Google on the first boot, but first go in and uncheck the auto restore. Then you can log into your Google account.
It happens to those who use voodoo, but it was worse with 2.2 for some reason.
I fixed it using and all in one odin 2.2 version. It'll repartition the file system and restore your dbdata.
Done problem solved...
I found the Google Auto-Restore was enabled, so I disabled it to clear everything and did a factory wipe and re-did everything with pretty much every automated backup or sync service turned off.
We'll see how things go.
Note: To skip the following lengthy background information, skip down to the numbered steps below.
Package disablers from a Vietnamese developer "Kunkunsoft" have popped up in the Play Store under various names as this poor (and clearly very bright) guy plays "whack-a-mole" with Google and Samsung. Neither company is happy about Kunkunsoft's "Swiss Army Knife" ability to efficiently disable individual services associated with system apps and to thus selectively limit telemetry while maintaining app functionality, especially without root. The routine is that a newly-named Kunkunsoft package disabler appears in the Play Store, sometimes with a plugin listed with a covert developer name that is not Kunkunsoft, becomes popular, and the developer is harrassed by the big guns until they finally force him to modify his app/plugin to delete the capability of disabling individual services and/or they take his app down. Its a sad situation.
The last no-root incarnation of the Kunkunsoft app ("BK Disabler for Samsung" with "BK Plugin v2") disappeared about 6 weeks or so ago. It is now replaced by "Service Disabler" which requires root. I am writing this "how-to" mainly for any users of BK Disabler for Samsung (no root) who may disable some boot-critical system package or service like I did and be stuck with the spectre of data and cofiguration loss. I spent way too much time trying to figure out how Kunkunksoft disables packages and services without root, in order to try to recover my phone by undoing his magic from a custom recovery. To his credit the dev responded to my email for assistance. However, he merely insisted that I would need to factory reset and lose my data and would provide no clue about how his app operates.
After much trial and tribulation I figured out how the app works and why it cannot be undone. BK Disabler implements its services control magic without root by skillfully exploiting a subset of Samsung's home-grown security system, Knox. Specifically, the app operates as a Samsung Enterprise Mobile Device Management ("MDM") manager. Normally an MDM manager sits on a corporate server and allows IT personnnel to create and distribute device policies to Samsung phones. But BK Disabler is an Android app that is also an MDM manager, both running on the phone and controlling the phone! Pretty clever, huh? More specifically, BK Disabler creates a protected Knox MDM container, turns on Kiosk-mode in the phone, and allows only apps/services that have not been disabled to run in that Kiosk environment! This is all done in real time, so the user is unaware that every time he/she disables or re-enables an app or service, BK Disabler actually goes into MDM management mode and modifies the Knox Kiosk mode container! As you can see, the dev is very clever and engages in substantial recursive thinking to pull this off! He also had to purchase a Knox MDM Management license from Samsung. That is why the app is called "BK Disabler for Samsung." It only works on Samsung devices because Samsung, in an effort to capture the corporate market, has placed this powerful control mechanism in the hands of the corporate world, giving corporations the power to implement controls that are otherwise unavailable without root. You can also see why it would likely be near-impossible to undo BK Disabler's freezes from a recovery environment. You would need to break into Ft. Knox... (I was actually surprised to find that I could read an SqLite database containing signed lists of the packages that I had disabled. I thought about editing the unencrypted database but finally gave up after realizing that it was a Knox MDM setup. The disabled system apps/services preventing boot were protected in a Knox container and boot would have failed before my edited database could have been read by BK Disabler, if at all.
With that way-too-lengthy background in place, this is the way to recover should you become too aggressive with BK Disabler for Samsung or any other package disabler for that matter:
Notes:
(a) I tested the method described only on my ancient Samsung Galaxy S5 running "Marshmallow" (Android 6.0.1). The BK Disabler (Samsung) app will only install on Samsung models which include the older Samsung Knox security system and Enterprise MDM included in the stock ROMs. That said, this recovery procedure is generalized to recover data from any phone that is flashable using Odin, which can accept a flash a version of TWRP applicable to the phone and which can be rooted.
(b) Its a good idea to have the back cover of the phone loose because you will need to pull the battery during this procedure. If you have a phone without a removable battery, I'm not sure how you can turn the phone off following an Odin flash, as I have no experience with a phone without a removable battery. Turning the phone off after flashing TWRP is necessary to prevent TWRP from being removed by an automatic boot to the OS after the TWRP flash. The first boot following a TWRP flash must be to recovery and not to system in order to make TWRP "stick."
(1) Note that flashing TWRP in this step will set the warranty bit on Samsung phones, which allegedly voids the Samsung warranty. Whether or not doing so actually legally voids the warranty varies according to consumer protection and contract laws of various jurisdictions. Boot into download mode (hold volume down and home button while pressing power button.) Using Odin (I used v3.13.1), flash TWRP 3.2.1-0 KLTE. Make sure that Odin recognizes your phone. It will show up in the upper-left window "ID:COM." Press the middle tab and unselect "automatic reboot." The reason is that your initial boot following the flash must be into recovery; otherwise TWRP will be deleted by the normal system boot process. TWRP fixes this problem when you first boot into TWRP recovery. Press the "PDA" button and navigate to the TWRP flash file. After the TWRP flash loads into Odin ("ready"), press start. You will see a message in the upper left window that the flash completed successfully. Pull the battery to turn the phone off. Re-insert battery.
(2) Boot into recovery (hold volume up and the home button while pressing the power button); you will see the TWRP recovery screen. TWRP recovery is a work of art!
(3) TWRP recovery will mount both the internal and external SD cards as MTP devices, allowing you to see all of your user folders and files on both SD cards in Windows Explorer.
Note: FYI for noobs, the "internal SD card" is a portion of internal flash memory within the Android Linux /data partition that is allocated for user storage. The "external SD card" is an actual microSD card plugged into the slot above the SIM card and just above the top edge of the battery. Generally speaking, when Android refers to "SD card" it is referring to the internal SD card and not to a microSD card that you plug into the phone above the battery.
(4) In Windows Explorer, copy and paste all folders from both internal and external SD cards to a safe place on your desktop PC, laptop, etc. Note that you do not even need TWRP to perform this operation for the external SD card because you can take the microSD card out of the phone and transfer the files from an external microSD card reader.
(5) Now we will create a nandroid backup of the entire system, all Android Linux partitions. The reason that we copied the SD card data using Windows Explorer is that a TWRP nandroid backup does NOT include either internal or external SD card data. All bits of all other partitions are included in the TWRP nandroid backup. The TWRP folks consider us to be smart enough to copy our photos, videos documents, etc. from both internal and external SD cards using Windows Explorer. However that still leaves lots of our data, like our contacts, calendars, text messages, emails, phone call logs, etc. buried in the nandroid backup.
(6) In TWRP, select the external SD card as the backup destination (if you don't have an external SD card, go buy one before doing anything else. Format it to fat32 in a USB card reader plugged into a Windows system (separate from the phone). Then insert the microSD card into the phone above the SIM card.
(7) In TWRP, select all partitions to back up, with the external SD card selected as the destination to write the nandroid backup to.
(8) Swipe the indicated TWRP screen area to the right (as indicated by the arrows) to start the backup. It will take awhile to create a nandroid of 6-8 GB.
(9) Make sure that you have a good nandroid backup created. If you want to be extra cautious, reboot into TWRP and restore the nandroid backup that you just created. TWRP should indicate if it was able to successfully restore the nandroid backup. Note that we are not going to use the TWRP restore function in this recovery process; we just want to make sure that the nandroid backup is good.
(10) TWRP will create an entire directory structure on the external SD card, top-level being "TWRP." Copy this entire directory stucture to a safe place on your PC.
(11) Now take a deep breath and, using the TWRP wipe function, wipe all partitions except EFS. TWRP has a screen showing all partitons to be wiped, with check marks beside all of them. Uncheck the EFS partition. That partition should not have been affected by BK Disabler and every write into EFS is somewhat risky. (Keeping in mind that restoring the nandroid backup or re-flashing to stock will both re-write the EFS partition; but those functions presumably know what they are doing.)
Also note: Wiping the /data partition by itself is equivalent to a factory data reset and should delete all of the BK Disabler Enterprise MDM/Kiosk-mode setup (as well as all of your non-system apps, data, settings, etc.) However, we are going to make sure that the phone is in completely factory stock pristine shape by re-flashing the stock ROM. Doing so will flash all partitions except /data, which we just wiped.
(12) Download the factory stock firmware from Sammobile that corresponds to your phone model, your version of Android and your carrier. It will download as a .zip file and will unzip to a file name reflecting your stock image and ending in _HOME.tar.md5. Don't change the file name or further decompress. Open Odin, press the "PDA" button and navigate to the _HOME.tar.md5 image. The other three file slots are left blank. Odin knows to extract all partitions from the image file in "PDA." By default, Odin is set to reboot the phone normally when the flash completes. Press the middle tab and uncheck that so that you can observe that the flashing operation terminated normally and completely. Do not select any other option. DO NOT select "repartition." Make sure that Odin recognizes your phone in the upper left box "ID:COM." Press "Start" and you will see the Odin log file populate on the Odin screen and you will see a flash progress bar on the phone. You will see a green "success" notification at the upper left of the Odin screen when the flashing operation completes successfully. Pull the battery to power the phone off and then re-insert battery.
(13) Next we will boot normally into the newly-flashed system. Before powering on, though, give this some thought. You will be faced with the "new phone" setup dialog and so should know your Google email address and password, name you want to use for the phone, etc. Also keep in mind that while you are fiddling with the setup, Google is busy getting your location, defaulting all of the settings to its best advantage, etc. And your carrier is busy downloading OTA Android and security updates to your phone. E.g., the big boys are infecting your phone as fast as they can and any controls that you previously set in place (e.g., via settings, freezing apps, firewall settings, etc.) to hold off the hoardes are no longer in place. It might be a good idea to put the phone into airplane mode immediately, pull the SIM card, turn off your wireless router, or whatever, to slow things down while you go through the new phone setup and adjust some of your settings. Just a thought...
(14) Now root your phone using your favorite rooting method. (This is necessary because the next (recovery) step uses the Titanium Backup app, which requires root.) For example, download Chainfire's SuperSu v2.82-SR5 zip file from here: https://download.chainfire.eu/1220/SuperSU/SR5-SuperSU-v2.82-SR5-20171001224502.zip Do not unzip. Move the SuperSu zip file to the internal or external SD card (to the top directory or any other directory is fine.) Use the Install function from within TWRP to navigate to the SuperSu zip file, highlight the zip file and swipe the TWRP action strip to install SuperSu. Now boot the phone normall (into the Android system) and you will be greeted by the SuperSu app. You may be given a choice whether to install SuperSu as "systemless" or to install it in the system partition. I prefer "systemless" because flashing a ROM (which overwrites the /system partition) does not wipe out root if SuperSu is installed as "systemless."
(15) Now download Titanium backup from the Play Store (paid Pro edition to be able to complete these steps). Also download and install any apps from which you need to recover data that are not system apps. (For example, if you use the stock messaging app, no need to download any other app to recover messages. However, if you use a non-stock messaging app, download and install that app now.)
(16) Now plug phone into PC USB and transfer the entire TWRP nandroid directory structure from whereever you copied it to on your PC to the internal SD card (Titanium will not recognize the nandroid file on the external SD card and will likely not recognize the nandroid file by itself without the TWRP directory structure).
(17) Now the amazing magical coordination between the TWRP team and the Titanium dev will become clear. Fire up Titanium and hit "Menu..." "Import/Export..." "Extract from Nandroid backup." Give Titanium awile to look into the Nandroid backup file and analyze it. When finished, Titanium will present all the apps and app data that it could find in a list for you to select from via checkmarks. Note that at the top of the screen you can select to restore apps only, data only, or apps + data. Also, the Titanium legend (font colors and icons) is quite extensive. You can study it under "Menu..." "Help/Licensing." Suffice it to say, though, the legend will indicate that few if any apps are available to restore. Why? Because, remember, the apps were hid away in a secure Knox container by the BK Disabler MDM app! So, logically TWRP was not able to include the apps in the nandroid backup. That's ok, because system apps were restored via re-flashing the stock ROM and you downloaded other apps that you needed to recover data for from the Play Store. I believe that its best just to choose "restore data" to avoid any problems with Titanium attempting to find apps in the nandroid when they don't exist there. However, if that is unsuccessful you could try restoring "apps + data." I would suggest restoring one app's data at a time. After each such restore, start up the app to make sure that its data is restored, then restore the next, etc.
(18) I was able to successfully recover all data, including contacts, calendar, SMS/MMS, phone log, K-9 email, etc. That said, going forward I will not go even one week without doing a full Titanium backup of all apps + data and less frequent TWRP nandroid backups, copying each to safe backup folders on my Windows PC. Of course, you could just enable Google Cloud sync. After all, why make Google work to get your data, why not just hand it to them?!
(19) Also, I am not too bitter about the Kunkunsoft BK Disabler for Samsung time-wasting experience. I did it to avoid burning time with the whole "rooting" scenario. But in the end I wasted much more time than would have been the case by just "doing it right" with TWRP and Titanium in the first place. I might even consider using Kunkunsoft's new whack-a-mole Play Store pop-up "Service Disabler," because Titanium does not freeze an app's individual services. But I would only do that if I can confirm that Service Disabler does not come anywhere near the "Samsung Knox Enterprise MDM/Kiosk Mode" area. What a nightmare!!
Update... I just read on a Kunkunsoft blog that his latest "no root" disabler "Package Disabler (All Android)" uses Google's Android SELinux "Device Owner" Enterprise Management "Device Policy Controller" functionality. This is the same old bad-boy unrecoverable "lock yourself out of your device" scenario as described above except even worse because it is probably even more secure than Knox and applies to all SELinux Android on any device after Kit-kat 4.4 or so. Basically the app takes over your phone as though it were a company-owned and managed phone. I would not touch it with a ten-foot pole and suggest that you just root your phone to avoid problems. I plan to contact Kunkunsoft to ask how his root version, "Service Disabler" works. If it works via Package Manager, like Titanium, then I will use it to re-acquire the ability to disable individual services. Otherwise I will just live without that luxury.
Hi,
First post, so be gentle. I searched the forum and found quite a few posts about a boot looping S5 but most referring to custom ROMs - my phone started doing this on its own. Running marshmallow 6.0.1. Its almost 3 years old, and up until now has never caused problems. It was charging when this first happened, and it could have updated (I have no way of knowing what update though).
First thing I tried was a new battery, I charged it up with the phone off, but it still wouldn't boot.
The problem:
-It either hangs on the startup splash screen ("Samsung GALAXY S5") and can only be turned off by pulling the battery (sometimes), or.. it restarts on the same screen (mostly).
-If I leave it for 10 minutes without a battery, it goes further, getting to the point where it asks for the password, but then freezes at this point at restarts.
-I can get into recovery (vol up + home + power buttons) and have cleared the cache. It never hangs or freezes whilst in recovery.
-Whilst I had enabled developer options (used for debugging bluetooth problems once) I have NOT enabled USB debugging - so it seems ADB push/pull to recover user data won't work.
I don't really want to do a factory reset as google hasn't backed up everything, so I'm stuck. Does TWRP or clockworkmod go into the recovery partition (sparing user data)? Or do these only work after a factory reset? I have read a fair bit about Odin, Kies, and firmware updates, but as I don't know what the problem is, I have no idea where to start - I was hoping there are some kind of debug logs on the phone that could at least point to the cause, but of course I cannot access it. The fact it doesn't crash/hang/restart in recovery leads me to believe it isn't a hardware problem - but the fact this happened suddenly without me changing anything is suspicious. Ideas?
If you have an SD card inserted remove it - a corrupt SD can cause bootloops
If it boots without sd card transfer what you need from it to a pc either via USB card reader or via USB cable whilst in twrp
Once done format sd card & transfer files back - note only transfer back personal files eg pics music etc & not the android folder or any app data
If it still bootloops your only choice maybe a factory reset
You can flash twrp at any time - it will not erase userdata unless you goto the wipe section & do it yourself
You can create a backup & extract it on a pc but remember twrp backups do not backup personal files like pics music docs
You can however mount internal storage & transfer what ever files you want to pc
If all else fails flash stock firmware via odin
TheFixItMan said:
If you have an SD card inserted remove it - a corrupt SD can cause bootloops
If it boots without sd card transfer what you need from it to a pc either via USB card reader or via USB cable whilst in twrp
Once done format sd card & transfer files back - note only transfer back personal files eg pics music etc & not the android folder or any app data
Click to expand...
Click to collapse
Sadly, it stil does it without the SD - forgot to mention I tried that too.
TheFixItMan said:
You can flash twrp at any time - it will not erase userdata unless you goto the wipe section & do it yourself
You can create a backup & extract it on a pc but remember twrp backups do not backup personal files like pics music docs
You can however mount internal storage & transfer what ever files you want to pc
If all else fails flash stock firmware via odin
Click to expand...
Click to collapse
Ahh, this is what I was hoping. So twrp, goes onto the recovery partition? I did read (here: hxxps://twrp.me/faq/backupexclusions.html ), as you mentioned, that TWRP doesn't back up internal storage automagically. Even if done manually, as long as I can transfer the files to PC, I'll be happy. Thankfully, it's only one folder of photos that I google didn't back up, but I might as well grab everything.
I may post back with questions, thanks for the reply!
Right, I keep reading that "USB debugging" must be enabled when installing TWRP, or doing almost anything. But I don't have this enabled, and I can't enable it since I don't have access to the phones system. Is this required to install TWRP? I know it is required to use ADB which I believe is used to flash the TWRP. If this is the case, it looks like a dead end. I did find one link claiming to enable USB debugging from a recovery, but the instructions are incomplete, and it also mentions performing a factory reset first - which kind of defeats the point.
BuriedCode said:
Right, I keep reading that "USB debugging" must be enabled when installing TWRP, or doing almost anything. But I don't have this enabled, and I can't enable it since I don't have access to the phones system. Is this required to install TWRP? I know it is required to use ADB which I believe is used to flash the TWRP. If this is the case, it looks like a dead end. I did find one link claiming to enable USB debugging from a recovery, but the instructions are incomplete, and it also mentions performing a factory reset first - which kind of defeats the point.
Click to expand...
Click to collapse
On the g900f all you have to do is the following
Install Samsung USB drivers https://developer.samsung.com/galaxy/others/android-usb-driver-for-windows
Put phone into download mode (hold Vol down home & power button) & connect to pc
Push Vol up to start connection
Open odin https://forum.xda-developers.com/attachment.php?attachmentid=4431749&d=1519672710
Place twrp.tar in the AP section & flash
https://dl.twrp.me/klte/
As soon as the phone restarts enter recovery - hold Vol up home power button
If the phone starts to boot before entering recovery you will need to flash it again - once you have entered twrp once it will stick
Once again, thank you for the clear instructions. I Successfully got TWRP on my phone, and it appears on the PC so I could see the file structure in explorer (!). Progress.
I went to copy two photos as a test - MPT/USB transfers have always been unreliable for me anyway - and the phone froze. I only noticed when the touch screen became unresponsive and the clock wasn't updating. So this could well be the original problem - a hardware issue that causes the phone to freeze when it does anything remotely taxing. Or.. it could be the MPT transfer.
Either way, I had to pull the battery and it seems the TWRP didn't take as when I tried to boot into recovery, it had the stock recovery menu. So at least I'm not going backwards, nothing is broken.
Now I know how to get TWRP on there, and to boot back into recovery right away, and I know that it works. Next up is getting it on there and leaving it for 10 minutes to see if it crashes/freezes. If its OK, then I'll have to look for another way to pull files off. Can one use ADB with TWRP? If its enabled then I could use "pull" to get the files off and hopefully quicker (or at least more reliably) than ****ty MPT. Ideally I'd like to just pull everything off so I can decide what to add back later after a fresh reset.
Thank you once again for your advice!
Replying to my own post. It still can crash (screen has random colours on it and it freezes) but rarely whilst in TWRP. I was able to use adb and pull off all my camera photos that weren't backed up, and with the "-a" option, keep the file attributes.
Also solved the MPT problem - if anyone has the same issue or cares - using USB 3.0 sockets on my PC and only at the back rather than the sockets on the front (which are awful quality anyway). It's sitll onyl USB 2.0 but I guess the socket is higher quality.
Last question which I may make another thread for: How can I back up contacts, internet bookmarks, SMS and "memos" from a Samsung S5? I read that TWRP does not back these up, so I would need the location of the directory where these are stored. My google fu yielded somewhat vague answers from stackexchange, but no exact directories. If TWRP includes these in backup great, if not I would like to know if there is any kind of work around. MMS messages probably aren't that important, but contacts and memos really are. If I find any answers, I'll post back for others. Cheers!
Right, I realise people either know this, or don't care, but I did say I would post with anything I've found. I couldn't find the answers googling, so I was digging around in the file browser in TWRP.
- Almost everything in data/media - which isnt' backed up by TWRP - is exposed to MPT. I say almost everything, because some isn't, but I backed up the entire folder anyway with adb pull. This is the "internal SDcard" people mention in forums (internal memory partition, not an actual card). Simply copying from windows explorer grabs the files, but not with the correct directory structure. Best to use adb pull with the -a option to keep file attributes.
- Samsung memos, bookmarks (from the samsung internet browser), and contacts are not stored in /data/media. Rather these are in data/data. in the following places (absolute directories):
- memos: data/data/com.samsung.android.app.memo/databases/memo.db
- bookmarks: data/data/com.sec.android.app.sbrowser/databases/SBrowser.db
- contacts: data/data/com.android.providers.contacts/databases/contacts2.db
It seems TWRP does not back these up -I could be wrong though. Samsung's own utilities probably do but I have never used them. I don't know if google stores these either since I haven't used its backups to check.
I am still unclear of exactly what TWRO backup backs up. I understand that the /media folder is not included (downloads, photos, music etc..) but are app settings in data/data included?
BuriedCode said:
Right, I realise people either know this, or don't care, but I did say I would post with anything I've found. I couldn't find the answers googling, so I was digging around in the file browser in TWRP.
- Almost everything in data/media - which isnt' backed up by TWRP - is exposed to MPT. I say almost everything, because some isn't, but I backed up the entire folder anyway with adb pull. This is the "internal SDcard" people mention in forums (internal memory partition, not an actual card). Simply copying from windows explorer grabs the files, but not with the correct directory structure. Best to use adb pull with the -a option to keep file attributes.
- Samsung memos, bookmarks (from the samsung internet browser), and contacts are not stored in /data/media. Rather these are in data/data. in the following places (absolute directories):
- memos: data/data/com.samsung.android.app.memo/databases/memo.db
- bookmarks: data/data/com.sec.android.app.sbrowser/databases/SBrowser.db
- contacts: data/data/com.android.providers.contacts/databases/contacts2.db
It seems TWRP does not back these up -I could be wrong though. Samsung's own utilities probably do but I have never used them. I don't know if google stores these either since I haven't used its backups to check.
I am still unclear of exactly what TWRO backup backs up. I understand that the /media folder is not included (downloads, photos, music etc..) but are app settings in data/data included?
Click to expand...
Click to collapse
All app data is backed up in a twrp backup
If you were to restore a twrp backup your phone would be in exactly the same position as when the backup was created including app settings & data
The common partitions it will backup are system data cache & boot (kernel) - it can also backup (if included in the twrp.fstab) modem/efs & other partitions
The only things a twrp backup doesn't backup is personal files eg downloads music pictures documents etc
You can make a twrp backup & extract it on a pc - I'm sure there are guides which explain how to do this
TheFixItMan said:
All app data is backed up in a twrp backup
If you were to restore a twrp backup your phone would be in exactly the same position as when the backup was created including app settings & data
The common partitions it will backup are system data cache & boot (kernel) - it can also backup (if included in the twrp.fstab) modem/efs & other partitions
The only things a twrp backup doesn't backup is personal files eg downloads music pictures documents etc
You can make a twrp backup & extract it on a pc - I'm sure there are guides which explain how to do this
Click to expand...
Click to collapse
Excellent. Well I've manually (well, same directory structure) backed up pretty much everything I could think of anyway so even if the phone goes south, the media files are safe. I'll do a TWRP backup on my PC as well (just for easy restoring if I need to) I'm assuming this can only be done via adb? as the UI only gives options for internal or SDcard storage - which is another option.
I have some more questions as I am not sure how to proceed. Yes, everything is (or can be) backed up. But the phone still freezes which may or may not be a hardware issue. So I am stuck deciding:
1) looking for logs to attempt to diagnose the problem. Probably won't get me anywhere. logcat doesn't seem to work.
2) Just performing a factory reset from TWRP. Unsure exactly what this resets. Firmware? OS? wipes all apps?
3) Using Odin to flash stock firmware (I only have one large md5 file from updato.com for use with "AP"). Does this wipe apps and data? (I'm not including media files here).
In some forums people claim that user data (as in apps and app data) isn't wiped by using ODIN to update the firmware, others say it wipes absolutely everything. Whilst I have back ups I'd obviously prefer it to keep the apps and their data, assuming they aren't the cause of the problem. Apologies for so many questions, I probably don't need to know all the details, but I'm curious and cautious.
BuriedCode said:
Excellent. Well I've manually (well, same directory structure) backed up pretty much everything I could think of anyway so even if the phone goes south, the media files are safe. I'll do a TWRP backup on my PC as well (just for easy restoring if I need to) I'm assuming this can only be done via adb? as the UI only gives options for internal or SDcard storage - which is another option.
I have some more questions as I am not sure how to proceed. Yes, everything is (or can be) backed up. But the phone still freezes which may or may not be a hardware issue. So I am stuck deciding:
1) looking for logs to attempt to diagnose the problem. Probably won't get me anywhere. logcat doesn't seem to work.
2) Just performing a factory reset from TWRP. Unsure exactly what this resets. Firmware? OS? wipes all apps?
3) Using Odin to flash stock firmware (I only have one large md5 file from updato.com for use with "AP"). Does this wipe apps and data? (I'm not including media files here).
In some forums people claim that user data (as in apps and app data) isn't wiped by using ODIN to update the firmware, others say it wipes absolutely everything. Whilst I have back ups I'd obviously prefer it to keep the apps and their data, assuming they aren't the cause of the problem. Apologies for so many questions, I probably don't need to know all the details, but I'm curious and cautious.
Click to expand...
Click to collapse
Odin firmware images (unless custom made) do not wipe user data apps & settings however unless it's the same firmware as already on the phone it will most likely bootloop until you do a factory reset in stock recovery
This will erase all app data & settings but not internal storage unless the device was encrypted in which case all internal storage will be erased
For twrp if you want to flash a custom rom
If encrypted format data (option on right of wipe menu) This will erase all internal storage - then restart to recovery
Then once encryption removed or not encrypted to begin with
Wipe system (previous rom)
Wipe data (app data settings)
Wipe cache
Flash rom
Flash gapps
Flash root (optional)
Restart
So it looks like a firmware flash with ODIN is the way to go. As I've loaded on TWRP I can no longer see the firmware version that was on the stock recovery screen to check if I have the right image downloaded. Is there a way to see the firmware version from TWRP? I tried
Code:
adb shell getprop
Which had [ro.boot.bootloader]: [G900FXXU1CRH1] that I'm guessing is the firmware version, although the hit on sammobile doesn't mention the carrier (vodafone). If I search by region and carrier, I get a different version.
Update: Just tried to backup to a blank SD micro. It freezes and restarts 2% into it every time. Tried:
Code:
adb backup " -all -noshared -f "C:\phone backup.ab" "
And it said "now unlock your device to confirm action" but TWRP gave no such dialog. At this rate I can't actually do a proper backup of anything. Is there another way? I don't have enough space on internal storage. I guess I could try USB storage (USB memory stick with adapter).
BuriedCode said:
So it looks like a firmware flash with ODIN is the way to go. As I've loaded on TWRP I can no longer see the firmware version that was on the stock recovery screen to check if I have the right image downloaded. Is there a way to see the firmware version from TWRP? I tried
Code:
adb shell getprop
Which had [ro.boot.bootloader]: [G900FXXU1CRH1] that I'm guessing is the firmware version, although the hit on sammobile doesn't mention the carrier (vodafone). If I search by region and carrier, I get a different version.
Update: Just tried to backup to a blank SD micro. It freezes and restarts 2% into it every time. Tried:
Code:
adb backup " -all -noshared -f "C:\phone backup.ab" "
And it said "now unlock your device to confirm action" but TWRP gave no such dialog. At this rate I can't actually do a proper backup of anything. Is there another way? I don't have enough space on internal storage. I guess I could try USB storage (USB memory stick with adapter).
Click to expand...
Click to collapse
Just backup to internal storage or SD card & transfer to pc
Backup is stored in eg sdcard/twrp
The firmware you need is
https://www.sammobile.com/firmwares/galaxy-s5/SM-G900F/BTU/download/G900FXXU1CRH1/233034/
Free downloads on sammobile will be back on Monday or find an alternative site
TheFixItMan said:
Just backup to internal storage or SD card & transfer to pc
Backup is stored in eg sdcard/twrp
The firmware you need is
https://www.sammobile.com/firmwares/galaxy-s5/SM-G900F/BTU/download/G900FXXU1CRH1/233034/
Free downloads on sammobile will be back on Monday or find an alternative site
Click to expand...
Click to collapse
I can't backup to SD card because it freezes at 2%. And using "adb backup " -f "C:\mybackup.ab" --twrp boot system data" " asks me to unlock my device - but TWRP doesn't show anything. On top of all that, it seems sammobile is under maintainance so I cannot download that firmware file until Monday Probably a good thing as it gives me a couple of days to keep trying to back up. Right now it gets into TWRP from recovery boot about one in 6 times. I'm out of idea's.
You can probably tell the frustration is real. Right now, I cannot use adb or twrp to backup onto internal storage (no space), the SDcard (crashes 2% into it, even with a blank SD card). It doesn't seem to crash whilst in TWRP, and I managed to pull the media folder off use "adb pull" so it seems it doesn't crash when using ADB commands.
So my only option before attempting to flash firmware is to make a backup via adb. However, I cannot get this to work at all. "adb backup --twrp" prompts me to unlock my phone, but the phone just displays the TWRP menu still. "adb backup -f "c:\backADB.ab" -noshared --twrp system boot data" tells me "adb: unable to open file c:\backADB.ab". Using simply "adb backup" puts me in the backup menu in TWRP, but then I can only change storage to internal or SDcard.
So either we can't yet backup to PC via adb and the TWRP documentation is out of date, or bugged. I'm on windows so I don't know if that makes it impossible - I just want to be able to get a backup on my PC's harddrive(s). Am I missing something with ADB?
Edit: it seems to now attempt to back up with "adb backup -f "c:\mybackup" --twrp system boot data" however.. this starts to back up and crashes at... 2%.
Just flashed the linked firmware with Odin after managing to get my apps backed up with my samsung account (the phone didn't crash for 15 minutes!). It cycled through "installing system update" restarting several times before hanging on the startup screen. I then pulled the battery, booted into stock recovery performed a factory reset (TWRP was gone). Now it is back in bootloop.
I installed TWRP again to use the file browser and my data has indeed been wiped (RIP). So what now? I could just let it boot loop and hope that it somehow gets back into android - it did that before, maybe one in 15 times. But I've done pretty much everything that has been recommended.
Rather than leave this thread hanging, I might as well post progress. After many *many* reboots interrupting the phone updating apps, it seems stable. It still occasionally crashes, but I can now make it crash and restart on demand by trying to install snapchat. It downloads it successfully and about a minute of "installing" the phone restarts, and reboots about 15 times before finally booting properly. I installed several other apps, none of which restarted the phone.
So, I'm going to get a new phone, and it seems that most things are backed up (please note, samsung doesn't back up contacts, shealth data, or splanner data despite claiming they do so). But I am curious as to what this problem could be. I have no experience debugging phone problems, and I realize it could be many things, but is there a way of checking the phones RAM (unlikely) or internal memory (flash, = more likely) for corruption? I may run a stress test to check if its power, CPU, or hover heating. If it passes that then it has to be memory usage.
Update: Today it only lasts a few minutes before it restarts. This is without any app updates - although I cannot be sure because I don't know whats going on in the background. This happens with, or without the SD card, and with both the new and old battery. I don't know where to start debugging. Any pointers?
Hi, after rooting my phone with Magisk and having installed TiBu I proceeded to backup all user app + system data then I installed System app remover and removed some system apps that supposedly were "safe" to remove (briefing) but after a reboot I end up in a bootloop. I had to wipe everything and start from scratch (install ROM + Magisk)
On my first try I did not restore my data using Google + Samsung backup. I tried to restore my apps + system data using TiBu but after several hours of waiting to restore, it did not progress and stuck at 0%
On my second try I restored my data using google+samsung backup. After everything was set and ready I used TiBu's "Restore missing apps + all system data". This time TiBU did progress and completed the restore. After a reboot I start to notice that most of my apps/system settings customization are not even there... To name a few:
I had Full screen gestures instead of the navigation buttons. TiBu did not restore this
I had several accounts that TiBu did not restore (google, outlook, twitter, steam, blizzard, twitter and the list keeps going)
Simple things like Gboard was not even restored as default input method
Settings like one hand mode, edge lightning, quick panel layout, adaptive brightness, screen resolution (the list keeps going) were not restored the way I had them
TL;DR: TiBu did little to nothing despite having the pro version and the appropriate backup
My device:
Galaxy S10+ (Exynos SM-G975F)
Android 10 (G975FXXU3BSKO_G975FOWO3BSKO_ARO) patched with Magisk v20.2-11b7076a (20109)
I feel like I wasted my money..... worst spent 6+ dollars of my life
TiBu is a powerful tool if you know how to use it, in a majority of the cases restoring any complete system backup is always a bad idea. If you ever want to restore system data, you need to use nandroid backup or selected apps in TiBu. When you restore user apps (missing apps in your case) all their data is restored and restored to the level of functionality they had before backing up.
For full-screen gestures, it's likely some mismatch between existing settings and restored system settings.
As for the accounts, it was likely because of restoring the app itself, they would have been there even before you backed them up.
Again, for system settings, you can't rely on TiBu in One UI, restoring system settings barely works in stock android.
My workflow is like this, If I am just tinkering with the system but my phone is stable, I do a nandroid backup (backup in recovery) and try out the mod/feature if it suits me, I continue with it, if not I restore back.
If I know I want to format, I generally need to do this when I've messed up in the system and need to start over. I install all I need in TWRP, setup the system only restoring call and SMS backup from Samsung Cloud, restore missing apps and go through the phone settings and set them up again. This ensures no ****ups from the previous install come back and now that I end up doing it regularly, I can do all this under 30 mins.
firesword14 said:
TiBu is a powerful tool if you know how to use it, in a majority of the cases restoring any complete system backup is always a bad idea. If you ever want to restore system data, you need to use nandroid backup or selected apps in TiBu. When you restore user apps (missing apps in your case) all their data is restored and restored to the level of functionality they had before backing up.
For full-screen gestures, it's likely some mismatch between existing settings and restored system settings.
As for the accounts, it was likely because of restoring the app itself, they would have been there even before you backed them up.
Again, for system settings, you can't rely on TiBu in One UI, restoring system settings barely works in stock android.
My workflow is like this, If I am just tinkering with the system but my phone is stable, I do a nandroid backup (backup in recovery) and try out the mod/feature if it suits me, I continue with it, if not I restore back.
If I know I want to format, I generally need to do this when I've messed up in the system and need to start over. I install all I need in TWRP, setup the system only restoring call and SMS backup from Samsung Cloud, restore missing apps and go through the phone settings and set them up again. This ensures no ****ups from the previous install come back and now that I end up doing it regularly, I can do all this under 30 mins.
Click to expand...
Click to collapse
Thank you for taking your time to reply this thread, I am clearly new at this and I am barely scratching the surface. Gonna try and search more info about this "nandroid backup" (not even know what this is and how it works) you mention and see how it works. As for "TRWP" I read something about it but per the offical site: "Long story short, TWRP support for Android 10 is going to take a while." and that is why I did not pay attention to this app
Hi guys,
I need an advice on a backup program or app that allows me to full backup my device without root.
I would like to backup the image of the phone because I have to full wipe it.
Some tips?
Any kind of image backup (presumably with TWRP) only works with an unlocked bootloader....as you don't have root I assume you also have your bootloader locked.
What you can do is use a tool like Swift Backup (or the standard Google backup/restore mechanism) which will backup and restore some of the data on you phone including installed apps, but no app data itself. Many apps allow for export/import of their data, so this may be a solution - but requires a bit of footwork to go through all the apps and do export/import of data manually. For me this approach (using the standard Google/Android mechanism) has worked quite nicely the times I had a non-rooted phone.
You can try with ADB backup/restore (maybe with help of an app called Helium Backup that creates a UI for the commandline-interaction of the ADB commands), but you need to connect the phone to a PC for this to work. From my experience ADB backup is a little quirky, not always backing up and restoring all data depending on some unclear characteristics of the apps concerned (and on top many apps don't allow data backup via ADB at all!). For me reliability in the backup/restore mechanism is crucial, so I've quit using ADB backup at all
Thanks!!!