I got my replacement for my broken 10 III and this time I tried the latest android 13 offered by Emma (forgot the name) and then I flashed SW_binaries_for_Xperia_Android_12_4.19_v2a_lena binaries.
Let’s see how it behaves this time since I suffered with color banding and echo before!
I’m running the latest SFOS on top of the latest Android 13 and binaries for Android 11, recommended by Jolla. No issues so far.
I tried Android 12 binaries as well, but I was having issues with the camera in Android apps so I reverted back.
@lkraav, do I understand correctly, that you originally flashed SailfishOS over an Android 11 base and used the unzipped SW_binaries_for_Xperia_Android_11_4.19_v9a_lena.zip for flashing, which resulted in well visible “tint” (»weird “paint blob” in any app launcher folder screen background«) and fingerprint sensor issues (»it intermittently wouldn’t easily [recognise the finger]«)?
Then only by flashing the unzipped SW_binaries_for_Xperia_Android_12_4.19_v2a_lena you resolved these issues (i.e. »“tint” is gone« and »fingerprint sensor quality improvements«)?
I.e. you did not reflash the device to Android 12 and reinstalled / restored SailfishOS, correct?
P.S: Caveat is, it may not be working this way. For any fresh installation (or after having backed up the whole SailfishOS partition (i.e. root & home volume) via dd and additionally all relevant data on file-system level) it is definitely advisable to update an Xperia 10 III to the last Android 12 release before flashing SailfishOS!
Fully independent of that, you can then choose and / or replace at any time a version of Sony’s software binaries as you like.
I.e. you did not reflash the device to Android 12 and reinstalled / restored SailfishOS, correct?
Correct: I skipped full Android 12 flash. Performed only fastboot flash oem_a.
Tint/Blob fixed is 100% confirmed, as it’s easy to tell.
Rest of problem fixes: it’s day 1, bit early to tell. But half-day later, I don’t see any regressions at least.
1 Like
I’ve noticed some missclicks and shutter lag in camera, but no color banding, no echo so far and fingerprint works fine.
Battery looks just as good if not better.
Too soon, but the setup looks promising.
2 Likes
Tint
Well, maybe I was roo quick to comment on «tint». My «tint» has always been what’s seen below:
It’s a weird paint blobbish thing generated by overlaying app switcher cards with launcher icons. That’s still here with A12 binaries flash.
But maybe it’s not at all what @wetab73 has been referring to as «tint»? EDIT and wow, just looked at this screenshot on laptop: no tint, blob, banding or whatever! Whereas it’s clearly visible on phone screen.
Regardless, end of day 2, everything is still working great otherwise. It probably makes sense to have A12 as your SFOS base.
PS did you see my App Support vs Location win from y-day (maybe OpenGApps-specific): GPS/Location not working for Android apps - #38 by lkraav
I don’t know if it’s the same but sometimes i do have some weird transparencies with previously opened apps, like i load a webpage on the browser, then close it and open fernschreiber, and i see the webpage all over sailfish elements, althought it’s hardly noticeable…
Wondering if it’s the same, especially since i’m on an xa2…
I see that it is still misunderstood. It is NOT the binaries what fixes the tint/banding and the echo issues. It is the UNDERLYING ANDROID 12 (or 13) OS, the one that you flash using EMMA, and then you flash SFOS on top of it. Binaries alone (i.e. what you flash to the oem_a partition) actually don’t seem to be doing anything regarding those specific issues.
So, once again, in order to get the display tint/banding and the echo issues fixed you need to flash Android OS using EMMA. You need either Android 12 (tested with 62.1.A.0.675, i.e. the last Android 12 update, I don’t know if earlier versions already had those fixes or not) or Android 13. But EMMA only offers Android 11 or Android 13, there is no Android 12 flashable image available via EMMA. So either you simply flash Android 13 via EMMA (tested by me and found fully working, actually I didn’t notice any differences vs. Android 12), or if you prefer Android 12 (as per Jolla recommendations) then the only way to get it is to flash Android 11 (version .109) via EMMA, then re-lock the bootloader in order to be able to get OTA updates inside Android, and then spend a few hours on installing one by one all consecutive (8 or so) Android 11 and then Android 12 OTA updates within Android itself, until you reach the 62.1.A.0.675 version. Then you need to unlock the bootloader again, and flash SFOS on top of it.
That’s the ONLY way to have the tint/banding and echo fixed, as those fixes are in the base Sony Android OS, not in the binaries.
P.S. You can’t illustrate the banding or tint issue on a screenshot. It is a technical issue of the display, it is not visible on a screenshot. You’d need to take a photo of the display.
But you DON’T have A12 as SFOS base. So far you only have A12 binaries, which don’t change anything regarding the display banding/tint and echo…
3 Likes
Sorry if this is already here somewhere, but i can backup my phones partitions, install android 13, install sfos and then restore my partitions?
thus no fresh sfos install?
1 Like
Yes, you can backup rootfs and home in recovery and then restore the same way. It gives a perfect 100% restore. The partition to backup (containing both rootfs and home) on the 10 III is /dev/sda79
6 Likes
But before restoring your backup, you need to start SFOS once. If you restore it directly after flashing, Sailfish will not boot.
4 Likes
That’s right. So the whole procedure is as follows:
- backup SFOS (/dev/sda79 partition containing rootfs and home)
- flash Android using EMMA
- boot Android once
- flash fresh SFOS and boot it once
- restore SFOS from backup.
7 Likes
I am sure that it is also in this thread, but due to so much information here I am a little bit lost:
how do I backup and restore the partition correctly ( with a Linux box)?
1 Like
You do it in recovery. So the procedure for the 10 III is as follows:
- flash hybris-recovery.img to both boot_a and boot_b slots:
fastboot flash boot_a hybris-recovery.img
fastboot flash boot_b hybris-recovery.img
fastboot reboot
-
go to recovery (by simply rebooting the device)
-
telnet to the device from your computer:
telnet 10.42.66.66
-
select option 3) (shell), then enter your security code
-
mount your microSD card (at least 105 GB of free space is needed for an uncompressed backup):
mount /dev/mmcblk0p1 /mnt
- do the backup:
dd if=/dev/sda79 of=/mnt/backup.img bs=1M
It may take 40+ minutes (or even more than one hour with a slower memory card). No progress is shown. If you would like to see progress, open another telnet connection and type:
watch -n5 'kill -USR1 $(pgrep ^dd$)'
This will show progress every 5 seconds.
- When backup is complete, unmount memory card:
umount /mnt
and then exit recovery mode.
Finally, flash the normal hybris-boot.img to both boot slots:
fastboot flash boot_a hybris-boot.img
fastboot flash boot_b hybris-boot.img
fastboot reboot
That’s all.
The backup can be restored the same way as you created it, i.e. by typing:
dd if=/mnt/backup.img of=/dev/sda79 bs=1M
13 Likes
Thanks for this comprehensive explanation!
2 Likes
Indeed, I never got “full Android flash required” from your previous posts, it always seemed like binaries only would do.
Well, couple of days ago I did end up discovering Android camera access is now broken with no clear way to revive it. Since binaries alone don’t change the game, I’m going to flash A12 binaries back to A11.
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.
4 Likes
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.
2 Likes
Thank you @wetab73 for the excellently written guide how to backup the complete SailfishOS installation (on an Xperia 10 III).
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
zstdis available (it compresses better and faster):
Typezstdand hit the <Return>-key , which should output “Incorrect parameters, Usage : …” - If
zstdis 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 (
xzis 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.
10 Likes