It worked fine before I reinstalled.
Which recommended binaries?
The ones recommended by Jolla (SW_binaries_for_Xperia_Android_11_4.19_v9a_lena.zip).
Hey @wetab73 , I just followed your guide and successfully backed up my system like this. Thank you!
Now, would you mind if I add your guide to sailfishos.wiki in order for it to be easier to find for other people?
3 Likes
Sure, please feel free to add it wherever it may help anyone.
3 Likes
I have a question regarding Android 13 here:
If VoLTE on Xperia 10 III doesn’t currently work with my provider, is there a chance for it to start working if I use a newer Android/Binaries?
Coincidentally, I completely reinstalled my daily driver (Sony Xperia 10 III) yesterday.
Encouraged by this thread I flashed Android 13 via Emma and flashed the latest Sailfish OS 4.6.0.13 alongside the recommended software binaries SW_binaries_for_Xperia_Android_11_4.19_v9a_lena with the jolla flash script. I basically followed the installation instructions by jolla with the exception of the Android 13 base.
Color banding is gone. EDIT: I think some other users also reported this. The greenish banding is way less intrusive but on low backlight in a dark environment it is still noticeable. If I recall correct, the resulting colors of the Android 11 base in combination with the workaround of JacekJagosz were more natural. [X10II] [X10III] Color banding in low light conditions - #24 by JacekJagosz
No echoing issue reported. I have the impession that the device responds quicker and performs better overall, but this might be due to the “fresh install”.
But that didn’t affect my personal experiences with VoLTE. I have a pretty old sim card (> 10 years) from o2 germany. Calling via VoLTE works fine although I don’t get a ring back sound. Receiving SMS works fine but sending SMS is impossible*. SMS get transfered instantly if i switch VoLTE off though.
So you can expect improvements but I’m affraid not on the VoLTE side.
*Due to the fresh installation of SFOS 4.6.0.13 VoLTE was enabled by default and at my first test run I was able to send one sms. May be my phone wasn’t registered in a 4G cell already, but I wasn’t able to send another SMS afterwards.
1 Like
Hard to tell. With binaries, you can simply flash various versions of them and see if it helps. Binaries can be reflashed anytime, without affecting SFOS installation in any way. Even if some version makes your phone non-bootable, you can just reflash it back to a working version. No harm will be done to SFOS.
As for the underlying Android, there’s more work to test various versions. A full image of rootfs and home partitions of SFOS (e.g. using dd) might help, as in such case you can always restore the OS to the imaged state.
1 Like
Try Android 12 based binaries (v2a as v3a doesn’t seem to work) and see if it further improves things. For months I’ve been using Android 12 base + Android 12 v2a binaries and it works perfectly fine.
3 Likes
That’s very bad news. Is there then even any way to fix VoLTE on Xperia 10 III besides changing provider?
I tried to flash the newer binaries, and it failed successfully:
$ fastboot flash oem_a SW_binaries_for_Xperia_Android_12_4.19_v3a_lena.img
Warning: skip copying oem_a image avb footer due to sparse image.
Sending 'oem_a' (355492 KB) OKAY [ 0.835s]
Writing 'oem_a' OKAY [ 0.001s]
Finished. Total time: 0.846s
No way it transferred 348MB in 0.8 seconds!
My device booted but without SIM card (and who know what else). So I flashed back the original:
$ fastboot flash oem_a SW_binaries_for_Xperia_Android_11_4.19_v9a_lena.img
Warning: skip copying oem_a image avb footer due to sparse image.
Sending 'oem_a' (343636 KB) OKAY [ 16.370s]
Writing 'oem_a' OKAY [ 0.001s]
Finished. Total time: 16.568s
Back to a working phone!
Why is that? I assumed I could just flash the oem_a partition, but it doesn’t seem to go through…
And yes, I know I should use Emma and go full Android for a boot or three. I just wanted to give this a try first.
Sometimes it fails this way, I’ve also had it a few times. Just repeat it.
But in case of Android 12 v3a binaries it doesn’t make much sense anyway, since they don’t seem to work correctly (mobile data and WiFi seem to be broken). Android 12 v2a is the last version of binaries working 100% fine for me.
Not really. You can flash the binaries to oem_a partition whenever you want, independently of anything else. It just sometimes fails this way, for no apparent reason. There’s absolutely no harm in re-doing it and on the second attempt it usually works just fine.
2 Likes
My rephone is unusable, due to a smashed screen. Sony Xperia 10V is not ready yet, so I decided to nuy a used 10 III, But now I have problems with flashing.
I tried to flash over different Android 13 versions with the SW binarys for Android 11.
Everytime I try I get the same error:
darkstar@Workstation:~/Downloads/Sailfish_OS-Jolla-4.6.0.13-xqbt52-1.0.1.11$ sudo /home/darkstar/Downloads/Sailfish_OS-Jolla-4.6.0.13-xqbt52-1.0.1.11/flash.sh
Flash utility v1.2
Detected Linux
Searching device to flash..
Found XQ-BT52, serial:HQ622R1880, baseband:62.2.A.0.525, bootloader:1322-1665_X_Boot_SM6350_LA2.0.2_T_205
Found matching device with serial HQ622R1880
Fastboot command: fastboot -s HQ622R1880
>> fastboot -s HQ622R1880 getvar secure
<< secure: no
>> fastboot -s HQ622R1880 flash:raw boot_a hybris-boot.img
Sending 'boot_a' (28240 KB) OKAY [ 0.887s]
Writing 'boot_a' OKAY [ 0.130s]
Finished. Total time: 1.029s
>> fastboot -s HQ622R1880 flash:raw boot_b hybris-boot.img
Sending 'boot_b' (28240 KB) OKAY [ 0.890s]
Writing 'boot_b' OKAY [ 0.142s]
Finished. Total time: 1.046s
>> fastboot -s HQ622R1880 flash dtbo_a dtbo.img
Sending 'dtbo_a' (238 KB) OKAY [ 0.014s]
Writing 'dtbo_a' OKAY [ 0.004s]
Finished. Total time: 0.028s
>> fastboot -s HQ622R1880 flash dtbo_b dtbo.img
Sending 'dtbo_b' (238 KB) OKAY [ 0.017s]
Writing 'dtbo_b' OKAY [ 0.006s]
Finished. Total time: 0.033s
>> fastboot -s HQ622R1880 flash userdata sailfish.img001
Warning: skip copying userdata image avb footer (userdata partition size: 112111374336, userdata image size: 140732374688672).
Sending sparse 'userdata' 1/3 (746980 KB) OKAY [ 18.962s]
Writing 'userdata' OKAY [ 14.303s]
Sending sparse 'userdata' 2/3 (779583 KB) OKAY [ 19.610s]
Writing 'userdata' OKAY [ 14.133s]
Sending sparse 'userdata' 3/3 (293646 KB) OKAY [ 7.339s]
Writing 'userdata' OKAY [ 7.952s]
Finished. Total time: 83.014s
>> fastboot -s HQ622R1880 flash oem_a ./SW_binaries_for_Xperia_Android_11_4.19_v9a_lena.img
Sending 'oem_a' (819200 KB) FAILED (remote: 'Requested download size is more than max allowed
')
fastboot: error: Command failed
Flashing failed (1)
I have no clue, what’s going wrong. Can anyone help me please. I need a device, which runs SF. I tried it with Android for three days now and it was a pain in the ass.
Edit: Got it to work, flashed the SW binaries now with the option
-S 256M
now the Android 12 vesion. That worked and SF is starting. Will have a look if everything works.
sudo fastboot flash oem /home/darkstar/Downloads/Sailfish_OS-Jolla-4.6.0.13-xqbt52-1.0.1.11/SW_binaries_for_Xperia_Android_12_4.19_v1c_lena.img -S 256M
Warning: skip copying oem image avb footer (oem partition size: 838860800, oem image size: 140726211807616).
Sending sparse 'oem' 1/2 (258632 KB) OKAY [ 6.896s]
Writing 'oem' OKAY [ 0.002s]
Sending sparse 'oem' 2/2 (66524 KB) OKAY [ 4.619s]
Writing 'oem' OKAY [ 0.001s]
Finished. Total time: 11.532s
1 Like
Just a warning. I tried to install latest 13 v4a binaries using this guide: [LENA][11][4.19] Echo cancellation is not enabled for voice calls · Issue #771 · sonyxperiadev/bug_tracker · GitHub and ended up with no sound after reboot as pulseaudio refused to start.
Luckily I was able to use the same guide for 11 v9a binaries resulting in restored sound after reboot.
The guide you used only copies a single file from Sony’s “software binaries for AOSP” in order to address the specific echo cancellation issue.
According to the experiences described in this thread here, this does not fix this issue and does not address the tint / colour-banding issue at all.
The proper way to re-flash the “software binaries” is well documented by Jolla.
When re-reading the discussion thread at GitHub, I have the impression you also have not yet understood the fundamental difference between the “Android base” and Sony’s “software binaries for AOSP”.
Furthermore, as @wetab73 already denoted a few times:
… when having had an “Android 12 or 13 base” installed before flashing SailfishOS onto an Xperia 10 III; Sony’s last Android 12 release for this device is 62.1.A.0.675, the last Android 13 release 62.2.A.0.533.
P.S.: How you backup the complete SailfishOS installation, re-flash Android (e.g. with Emma; either to Android 11 and then update via OTA to the last Android 12 release, i.e. 62.1.A.0.675, or flash Android 13 and update to its last release 62.2.A.0.533) and then restore the backed-up SailfishOS installation is described throughout this thread.
This seems to be the only known way to resolve both, the echo cancellation and the tint / colour-banding issue properly.
I see. Any difference between flashing it to partition a + b or just mounting the odm folder and copying over libaudcal.so as described here: [LENA][11][4.19] Echo cancellation is not enabled for voice calls · Issue #771 · sonyxperiadev/bug_tracker · GitHub ?
Indeed, Android 12 v2a binaries are the last version that’s fully working for me. I’ve tried the recently released Android 13 based v4a binaries but I couldn’t enable WLAN on them, so I didn’t even bother to try if everything else works.
You only flash the binaries to oem_a, not to b.
From my experience, it is SOLELY the underlying Android OS (version 12 and up) that makes the echo and display tint/banding issues go away. Binaries don’t seem to have any connection with it. No matter what version of binaries one uses, if the base Android OS is version 11 recommended by Jolla, echo and tint/banding still appear. Flashing Android 12 or 13, even with the old Android 11 v9a binaries, makes those issues disappear. So the fix must be in the base OS, not in the binary blobs.
2 Likes
Yes, sure, we both keep on saying the same with slightly different words. Technically I assume we both expect some firmware partition being updated to make the difference: Consequently there might be other ways to achieve that, if one successfully identifies this firmware partition and copies over its updated content from another Xperia 10 III. This is the approach @thigg was once aiming at, which may even be achievable under a running SailfishOS installation, though I would still prefer to do that when having a SailfishOS recovery image booted.
Hence my slightly softer language, because I have learnt to “never say never” rsp. not to say “this is the only way”.
1 Like
That’s right. And it seems to be one of the partitions that gets its contents when the base Android OS is flashed, and which then doesn’t get altered, neither by flashing SFOS nor Sony binaries.
Which on the 10 III rules out boot_a, boot_b, userdata, dtbo_a, dtbo_b and oem_a.
But the whole rest remains…
1 Like