I’ve been using /e/OS for a while and been perfectly happy. Apparently, the automatic update process stopped working for me a while ago and I never really noticed. The last OTA Upgrade I received occured ages ago, and now the App Lounge stopped working as well, leaving me unable to update apps installed via it.
My build number is e_FP3-user 10 QQ3A.200805.001 eng.root.20221031.174702 dev-keys,dev-release. I have trouble figuring out the update process based on this state. How do I proceed? In particular, how do I ensure no data is lost? Is there a way to do a regular update or will I have to do a reinstallation?
To check whether the bootloader is really unlocked, you can just boot the phone into fastboot mode by keeping Volume - pressed while starting or rebooting the phone.
The device status will be given in red at the end of the list of status info there.
To reboot into the OS again from there, just keep the power button pressed for about 15 seconds (which should force a reboot in any situation).
That worked, the Device State is locked according to this. So I assume the bootloader isn’t unlocked? Then I’ll have to get my android tool installation working to achieve this, I suppose. How would I proceed once I ensured my bootloader is unlocked?
Okay, so I’ll have to unlock it. I’m wondering how I ever managed to install /e/OS with a locked bootloader in the first place, but I suppose it doesn’t matter for now.
I’ve been preparing to back up everything on the phone, I’d like to get some feedback as a sanity check whether I might have overlooked something. My current plan is to adb pull everything in /data/app, /data/data, /system/app, and /media, and then (selectively) put that data on the fresh installation before installing the corresponding app. Would that risk losing any relevant data?
For the new installation I think I’ll try and install something like TWRP that allows me to do proper backups of the system without jumping through Android’s hoops.
TWRP will only work with the bootloader kept unlocked, if you don’t mind the security implications of this.
Furthermore, how useful TWRP will be depends on what you define as “proper backups of the system”. If TWRP is able to decrypt the data partition holding the user data (which is not a given, it works currently with /e/OS based on Android 12 on the Fairphone 3/3+, it is kind of expected to not work with Android 13, but we’ll see), TWRP by default will not backup the storage area called “Internal Storage” (but this can be copied via USB).
I see, what I mean by ‘proper backups’ is file-system level backups. Since I’m not proficient with Android I’m worried by the indirect access it gives me to anything and the possbility of data loss.
Your comments on TWRP are very insightful, I wasn’t aware. What kind of backup would you recommend, in particular with Android 13+?
Also, is the list of locations ( /data/app, /data/data, /system/app, and /media) I mentioned in the previous post sufficient for a complete backup of the phone? Sorry for all the questions, I’m trying to make sure I’m not doing anything wrong by accident, as I mentioned I’m out of my depths with Android.
I didn’t approach backups from this angle yet, so perhaps anybody else can answer this, hopefully.
I deliberately left my bootloader unlocked to be able to use TWRP, and since TWRP on the Fairphone 3/3+ for now regained the ability to decrypt user data (there was a period in which this failed), I’m basically back to doing what I described here in my /e/OS beginnings …
Additionally (or alternatively depending on how TWRP behaves) I’m using MyPhoneExplorer to cover things like SMS, contacts and calendar (and I let it do the necessary Internal Storage copy for me, too).
In case TWRP can not decrypt user data the backup problem not covered by other means from my point of view would be /data with the exception of /data/media (= Internal Storage).
I planned to have a look at ADB for this, because Rooted debugging is available in /e/OS’s Developer options, which would give root to ADB (without having to root the whole OS), which would give ADB access to the whole filesystem including /data … but then TWRP regained decrypting ability and I didn’t need to look into this yet.
I’ll just see whether TWRP can decrypt user data or not and apply my comments above accordingly.
Without TWRP able to decrypt, or with a locked bootloader and thus without TWRP, I guess using ADB with Rooted debugging would look most promising to me.
Seedvault, which is included in /e/OS, might be worth a look from Android 13 on, too, as I seem to remember that from Android 13 on this would not be “Apps have to opt in to let themselves be backed up by Seedvault” anymore, but more universal … but I would need to read up on that again myself.
Regarding your list of locations, from my understanding, /data/app/ should contain all user installed app apks (including apps installed to work profile), /data/data/ contains the apps data from default profile (user 0), /system/app/ contains the system apps apks.
/data/data/ is interchangeable with /data/user/0/. Though, there is additional app data stored here: /data/user_de/0/ (mostly cache, and preferences). If you use a work profile (or Shelter/Island/Insular) you should also backup work profile related data: /data/user/10/ and /data/user_de/10/.
Does /media/ contain your internal storage data? In my case of a FP4 internal storage is located at /data/media/, but maybe that path differs from device to device. Internal storage of default profile (user 0) is located at /data/media/0/ (/storage/emulated/0/). Internal storage of work profile is located at /data/media/10/ (/storage/emulated/10/).
For better understanding I found this article on Android data storage paths which kind of reflects the current state of 2023: https://android.stackexchange.com/a/218507
From what I know, backing up the locations mentioned above should provide you with a complete backup in terms of all individual data on your phone (but not a bit-perfect or full block-level backup, which is not needed IMHO, anyway).
Wow, thanks for the detailed answers! I think this gives me enough insight to not feel completely oblivious trying to update my phone. I’ll try and backup via adb and for the future will see whether I’ll use the TWRP route, or go for the in-system way via restic or an app like seedvault.