Are you sure about this? I.e. have you tried after reflashing the Sony software binaries recommended by Jolla?
Such effects are expected when using Sony software binaries which are incompatible to SailfishOS. But I cannot tell for sure, because I do not own an Xperia 10 III.
Up to now, the identified differences an Android 11 base versus an Android 12 / 13 base makes are “tint on screen”, “caller echo” and <IIRC there was a third thing>.
Hence please first reflash the Sony software binaries to the version Jolla recommend and check your camera issue (and report the outcome here), before flashing an Android 12 or 13 onto your Xperia 10 III.
One week later and everything runs great.
No issues at all (color - echo), battery is good and the camera lag was probably a random thing that day.
Latest Android 13 with latest Android 12 binaries works great!
I have no clue about anything related to app support since I didn’t get my license transferred yet, but I don’t think there will be an issue there.
I’m not sure if I follow. You’re saying that since binaries don’t change anything, you’re going to flash A12 binaries back to A11? Aren’t you still confusing binaries with the underlying OS?
Anyway, I’ve been using Android 12 binaries with underlying Android 12 OS (62.1.A.0.675) for weeks and both native and Android camera applications (e.g. Open Camera) have been working perfectly fine.
After weeks of tests, I dare to say that there are no apparent compatibility issues between Android 12 binaries SW_binaries_for_Xperia_Android_12_4.19_v2a_lena and SFOS, at least when running on top of Android 12 OS version 62.1.A.0.675.
May I suggest to use compression, and as nitpicks a block-size of 4 MBytes (i.e. the LVM extent size chosen by Jolla) and to avoid overwriting extant backups:
See if zstd is available (it compresses better and faster):
Type zstd and hit the <Return>-key , which should output “Incorrect parameters, Usage : …”
If zstd is there, backup with Zstandard compression (the whole statement comprises a single command-line): set -C; dd if=/dev/sda79 bs=4M | zstd -o /mnt/backup-sda79_$(date -I).img.zst
If not, use gzip (xz is way too slow; again, the whole statement comprises a single command-line): set -C; dd if=/dev/sda79 bs=4M | gzip >/mnt/backup-sda79_$(date -I).img.gz
Restore can be achieved by:
With zstd (the whole statement comprises a single command-line): zstd -dc /mnt/backup-sda79_<date>.img.zst | dd of=/dev/sda79 bs=4M
With gzip (the whole statement comprises a single command-line): gzip -dc /mnt/backup-sda79_<date>.img.gz | dd of=/dev/sda79 bs=4M
P.S.: As @thigg correctly pointed out, only the LVM meta-data and the content of the root volume are compressible, the whole home volume is not due to its encryption. Hence one might as well perform the backup as @wetab73 suggested, because there are only a few Gigabytes to be saved by compression, at most.
I took a backup via ssh to my pc (takes 40 minutes, will post about that soon) and flashed android 13 and restored sfos afterwards. Havent tested calling, but i got still color banding when using nightish and lowest settings in a dark room. That should have been fixed, right?
because I thought the sda* partitions might contain the relevant drivers that cause the issues, i took a md5sum of them before and after, it is a bit too much to say something useful:
I provide the old md5sums I had and the diff:
diff:
I took the backup via ssh to my laptop. Maybe this is interesting for some:
Backup and restore both take about 1 hour each, most of it without interaction.
Flashing android and reinstalling sfos took about 1h for me as well (most of the trouble was reviving a windows pc).
If you want to be really failsafe,mount your homepartition wiht cryptsetup after backup to make sure everything worked (either ungzip before cryptsetup or use avfs
connect device in fastboot mode (volume up and plugin usb cable on a powerd off phone)
flash recovery from the sailfishos distribution you use for flashing:
launch sshd from the menu and connect to it by following the instructions (no password needed). You can exit again, if it works. I assume the ip 10.42.66.66 for the commands below.
Comments:
using pigz (parallel gzip) is actually completly pointless on the home partition. This device is still encrypted (not what i was expecting) thus compression wont help anything.
Root partition should compress relativley good because this seems to be plain.
root partition backup and restore took about 1min, home partition backup 40min and restore 51min. The gzip command for the homepartition can be replaced by cat but shouldnt be a bottleneck with default parameters
I’m not confusing binaries and OS, but I never flashed full A12 OS here, just A12 binaries. So this last experiment was “A12 binaries on top of A11 OS”.
“Binaries don’t change anything” I should’ve worded better: A12 binaries on top of A11 OS caused a camera functionality regression. Everything else seemed to have stayed equal to my A11 binaries experience, hence no reason to try fix the camera regression in some other way.
I flashed A11 binaries back: Android camera functionality was immediately restored.
Thanks for SFOS partitions backup/restore guide: I will do a full A12 base flash after I’m back from US road trip, avoiding large risks during travel.
You introduced the necessity to reinstall SailfishOS only to restore the LVM volume layout by backing up on LVM volume level. IMO this is pretty senseless, either backup on block device level (/dev/sda79 for the Xperia 10 III) or on filesystem level for regular backups using tar (but the latter is unsuitable for the purpose here, i.e. backing up the complete SailfishOS installation).
If one wants to backup to another device (instead of on SD-card), the easiest way is to pipe into or from scp (in order not to resort to ancient tools as rcp or netcat).
I.e. for backing up dd if=/dev/sda79 bs=4M | scp <user>@<host>:<directory>/backup-sda79_$(date -I).img
and for restoring scp <user>@<host>:<directory>/backup-sda79_$(date -I).img | dd of=/dev/sda79 bs=4M
P.S. / Edit: Oops, scp does not seem to be able to read from or write to a pipe.
So one may try this (also untested):
Backup on your PC by ssh root@10.42.66.66 "/usr/bin/cat /dev/sda79" > backup-sda79_$(date -I).img
and restore from your PC by ssh root@10.42.66.66 -T "/usr/bin/cat > /dev/sda79" < backup-sda79_<hit-tab-to-autocomplete>.img
You dont need to reinstall sfos before recovering from the backup?
i should have read that more carefully.
i was only playing around with home and root because i wanted to see what effect encryption has. Your approach is probably better
That’s the reason why I only mentioned uncompressed backup in my post. Compression (well, at least gzip that I’ve tried) is quite slower and doesn’t seem to be helping much.
I don’t remember having seen any banding since I started using Android 12 (along with Android 12 binaries), but I haven’t tested it with nightish. I’ll give it a try.
Well, I’ve only ever used A12 binaries together with Android 12 OS as base for SFOS (and that was actually the reason of using them - to have a matching pair), so I can’t tell how they behave on top of Android 11.
Anyway, as I wrote earlier, I actually haven’t noticed any improvements that would result from changing the binaries because all fixes (including the echo issue, banding/color tint and fingerprint sensor functionality) apparently come from upgrading the underlying Android OS to version 12 or 13, and not the binaries. So I guess it is OK to just stick with Jolla recommended A11 binaries, or in case of using Android 12 as base OS for SFOS one may also use A12 (v2a) binaries to have a matching pair that may POSSIBLY give some advantages (or not ) but in that specific combination (Android 12 62.1.A.0.675 as underlying OS, Android 12 v2a binaries) after weeks of tests don’t seem to be causing any issues.
You do need to reinstall SFOS prior to restoring the backup in the case that you wiped the existing SFOS installation (e.g. by reflashing Android using EMMA). Or in such case you need to at least manually flash the remaining partitions that SFOS uses, which are not in your /dev/sda79 backup (that only contains rootfs and home). Namely:
Good idea. One more thing worth including in such a wiki post is that after restoring the /dev/sda79 backup it is sometimes not possible to add new fingerprints without doing the following. The existing fingerprints work OK, but if one wants to add new ones it takes wiping them and the cache first, as suggested by @ric9khere:
and then it works as usual. I’ve tested it multiple times after each restore and it always works, so there’s nothing to be worried about, just an additional easy step to do after restore.
This is regardless of underlying Android OS version, binaries version, etc.
Uh, and this binaries experiment gets even weirder: color banding, or “paint blobs” is also gone now. Damn, turns out I should’ve taken photos of the device screen to document I’m not crazy
I’m looking at the exact same “Work” app launcher folder I screenshotted earlier at Android 13 and SailfishOS on xperia 10 III - #61 by lkraav and there’s zero weird color banding on screen, everything now looks exactly like in the screenshot - translucency, shadows are all perfect.
Maybe lighting conditions were different. This color banding issue only becomes apparent with very low screen brightness, so with an automatic display brightness it takes being in a dark place to see it.
Yes, confirmed! In a pitch black dark room, color banding is visible. OK I think now that’s all there is to know about it, thanks. Will test full A12 juggle next week.
Hello, picking up this thread on the “backup wiki” subject. I am not very fluent with linux bash but is it even possible to use dd on a “live” device? Will I not get corrupted data? Or am I missing something?
) but in that specific combination (Android 12 62.1.A.0.675 as underlying OS, Android 12 v2a binaries) after weeks of tests don’t seem to be causing any issues.