Android 13 and SailfishOS on Xperia 10 III

Go A12 (and then also the aforementioned A12 v2a blobs), which is the combination that’s been working for me flawlessly for 1,5 years, whereas A13 base was tested by me only a couple of months. And even thought I didn’t experience any issues with it myself, it was A13 base (and never A12) that several other people reported here and there as having occasional in-call echo with it.

And if you have A12 firmware readily available for direct flashing via Emma without all that additional hassle (in my case it took hours of manual A11→A12 updates via OTA, involving bootloader relocking and unlocking), then I wouldn’t hesitate a single second.

1 Like

Thanks, but perhaps you skipped over the remaining (long) story, since A12 + v2a is exactly what I continued to describe doing.

Any thoughts on this part?

Additional discovery today: in a pitch black dark room, green blobs seem to disappear if you specifically max out “Settings > Display brightness base level” slider. I say “seem to”, because maybe they become so faint, it’s near-invisible with naked eye? Regardless, anything below max === app Home view cards generate clearly visible green tinted blobs below app icon grids. On A12 base + v2a blobs.

Another “partition restore” note: ofono wasn’t able to complete mobile data connection with ERROR: GDBus.Error:org.ofono.Error.Failed: Operation failed until fortunately Resetting oFono Settings | Sailfish OS Documentation emptying /var/lib/ofono seems to have worked!

Thanks Unable to use mobile data on Sony Xperia 10 III 4.4.0.64 - #17 by jessica

I must confess that you’re right, I only read the last question :face_with_peeking_eye: Well, if you get some undesired effects on that combination, then, obviously, you might want to try something else… I really don’t know if it is device specific, or maybe my perception level is different, but I really do not get any display or echo problems on A12 + v2a, and that’s the reason why I recommend it. But maybe it’s true - like someone suggested some time ago - that two different display types/models were used in different 10 III batches. If so, and we have different displays, then your mileage may vary….

I can tell you my take since I tried all possible base and blobs combos.
Not only nothing helps ultimately, but the green hue/smearing whatever it’s called doesn’t even go away now with the brightness fix script (I think I left it with 12+12 as I gave up).
There’s definitely different points where the smudges appear and different scale depending on the base + blobs combo, but the only thing that works is 11+11+ brightness fix script.

1 Like

What-ho sailors! I just installed Sailfish OS on my Xperia 10 III with all the latest Xperia software and Android 13 updates installed on it. Didn’t revert back to earlier Android versions as was suggested by the official installation instructions.

It was smooth sailing from the start to finish, as I proceeded with the installation following the installation instructions on Windows 11. However, apparently the links to the Sony developer world pages are broken since Sony has closed the developer portal on 8th of May. The xperia x driver and software binaries can be found at https://opendevices.sony.net/. Here’s the direct links to the driver and blob I used: xperia-x-driver.zip and sw_binaries_for_xperia_android_11_4.19_v9a_lena.zip.

After flashing SFOS and booting first time, everything seems to be working so far. This is my first time flashing and using SFOS so proceed with these files at your own risk. :wink: I installed OP-mobiili, Volvo Cars and Olvid from Aurora Store to quickly test if they work out of the box, but OP complains about incompatible phone and Google Play services (there’s a workaround I haven’t tested yet) and attempt to sign in to Volvo Cars app with my Volvo ID returns with a “permission denied” error, after giving my credentials on redirected Jolla browser.

I will be replacing my Fairphone 6 /e/os with this SFOS Sony Xperia III as my daily driver, if I manage to get these apps working. Had to cancel J2 because of the size of the phone which I can’t use one handed (it’s my main gripe with FP6 too). Xperia III fits my hand far better in this regard. :blush:

6 Likes

Hello and welcome! At least OP works for sure. I don’t know if it need MicroG or not as I have MicroG enabled. But the command line workaround is needed for that. Hopefully you have smooth sailing :slight_smile:

1 Like

Thank you! Did have the MicroG enabled but didn’t do the CLI trick. Will try as soon as I can some time after finishing work today. :blush:

1 Like

I noticed this myself. AFAICS the links are exactly the same, only the domain has changed from developer.sony.com to opendevices.sony.net

4 Likes

Final update: tested Android 13 + matching Android 13 binary — same VREG_NG error, 100% reproducible

Following up on the suggestion to try Android 13 with the matching binary (thanks @tn71 and reference to @wetab73’s success story):

Setup: Android 13 (62.2.A.0.525) via Emma + Sailfish X 5.1.0.11 + SW_binaries_for_Xperia_Android_13_4.19_v2_lena.img (same binary version referenced in the successful report)

Result: Same failure pattern. Screen shows Sailfish logo, dims, and backlight responds to touch/power button — but no UI ever loads behind it. Pulled the full persistent journal this time and got a much clearer picture: every single panel power-on attempt triggers VREG_NG, with no exceptions:

14:38:32 panel power on → VREG_NG interrupt!
14:39:31 panel power off
14:44:24 panel power on → VREG_NG interrupt!   (after a power-button wake attempt)
14:44:58 panel power off
14:47:40 panel power on → VREG_NG interrupt!
14:48:14 panel power off
14:48:36 panel power on → VREG_NG interrupt!
14:49:10 panel power off
14:49:59 panel power on → VREG_NG interrupt!
14:50:33 panel power off

5 separate power-on attempts across a ~12 minute window, 5/5 VREG_NG faults. This appears fully deterministic, not intermittent.

Summary of everything ruled out at this point:

  • Wrong/corrupted binary (MD5-verified against md5.lst every time)

  • Android 11 vs 12 vs 13 firmware base

  • Matching vs mismatched binary/firmware Android version

  • Sailfish 5.0.0.77 vs 5.1.0.11

  • Filesystem/LVM corruption (e2fsck clean throughout)

Since the screen works perfectly under stock Android on this exact unit regardless of Android version, but fails 100% of the time under the hybris/Sailfish kernel across every combination tested, I’m now fairly confident this is either:

  1. A genuine marginal hardware fault on this specific panel’s power circuit, only exposed by the Sailfish kernel’s particular power-sequencing timing (and tolerated/avoided by Android’s different timing), or

  2. Something in the shared hybris panel driver code itself that’s incompatible with this panel revision/batch, independent of which AOSP base or binary blob version is used

Given the unit was purchased used, option 1 seems plausible. I’ll be pausing further testing here and looking into hardware repair options. Many thanks to everyone who contributed ideas — this was a genuinely difficult one to pin down, and the journal-log approach suggested earlier was key to getting concrete data instead of guesswork. Leaving this thread open in case anyone recognizes the exact fault pattern or has other ideas, but not expecting to actively continue testing for now.

2 Likes