If battery drain could be fixed, …
Nope, it cannot much as far as I can see. So, it is as it is now with the “fix” in terms of switching off power-hungry CPUs while you don’t use display applied in the tests as described above and in the corresponding issue. So, we don’t have much more to add with this.
I jumped directly from Android to AOSP 10/aarch64 SFOS port, so i don’t know AOSP9/arm32 benefits.
For me:
Only disturbing thing so far is glitch on screen while swiping or unlocking. Is there any temporary fix for it?
Probably not too hard for scripters to come up with something that would listen for certain kinds of usage and activate or deactivate certain cores based on that, or something …?
Maybe this guy could help - [HowTo] Enable A72 cores to make Xperia ~1.7x faster - together.jolla.com
If the LED behavior is a SFOS problem and not a port one then its fine. 
BTW - a new battery monitor app just showed up on Openrepos, and XZ2c os specifically mentioned in description. Doesn’t solve anything, but possibly helpful/interesting …
https://openrepos.net/content/lal883/usage
Re LED blinking: I have been asking on IRC (porters and regular SFOS channel) and have not got a reply regarding it. Thank you for providing it - will close our port issue as it is on SFOS then.
Re glitch: try whether this will work for you:
cd /sys/class/devfreq/soc:qcom,gpubw
echo 1720 > min_freq
Have to run it as root
I wrote already a small daemon for it, so we are good in this respect. There is also some extra module made by Spiiroin for MCE - will have to test that. So, there are ways to switch on/off CPU cores and they are in use already
Thanks a lot for the efforts and wonderful work you produce!
I have a feeling that aarch64 may be the way to go, be it AOSP9 or AOSP10 base, considering Flatpak arm32 support is being concluded. That would mean either option 2 or option 3. Not quite sure if aarch64 would make the Sailfish OS experience better otherwise compared to current arm32. Would be interesting to know that from an expert.
Always nice to have a usable camera in my opinion. And hopefully could figure out ways to tweak the system to draw less power and smooth out GPU glitches, like by using zgoverner or MCE module, eventually. In any case, although the idling power consumption is comparatively higher, more real life data may be what we could look at to identify the endurance rating. If that is decent, and having much effort already put into it, I do not see why not AOSP10/aarch64.
Interesting to note that LOS 18 uses 4.9 kernel, as mentioned on the XDA thread.
OEM Android10 on XZ3 is also using kernel 4.9, which I think it’s the same kernel version used in Android9. That also implies binaries (blobs) they use do not have to change much.
LOS is based on Stock - Android as given by Sony itself when it sells you the device. So, they use Stock BLOBs as well which are probably way better tuned and tested than BLOBs used for AOSP. As stock stayed on 4.9, LOS kernel is the same.
Re Flatpak/aarch64: as I don’t want to make any promises regarding Flatpak/AOSP10, assume that it is Flatpak vs Camera when comparing AOSP9 vs AOSP10. While I cannot be 100% sure, I hope that AOSP9/Flatpak/aarch64 is possible.
Re aarch64/arm32: don’t know how they stack up. I would expect on SFOS part the differences will be minimal over time (right now AOSP9/arm32 sounds to be more polished)
This worked for me, no more glitches.
Hi @rinigus,
Thank you for this port(s) and all the SFOS things you develop!
(I wish I went for an OLED tama device instead of trying to start a port:)
I just wanted to share that at least 3 or 4 issues are visible in another port I’m working on, so they might be AOSP or SFOS middleware related after all.
My port-in-progress is actually Lineage-17.1 (unofficial) based and exhibits these three:
(I’m curiuos if you used a specific video test page to single out the codec, but I definitely need to restart the browser for videos to ever resume)
This was my conclusion too.
I have something similar.
As for the fourth one, I believe I have seen lipstick glitches too, but not something that I worried about to file a bug.
So what I am trying to say is that some of these issues may not by Sony related after all.
HTH,
–
b100dian
Very interesting points actually:
I will start moving builds to OBS as we have it working now.
Re VP9: that was mainly found via journal or logcat, don’t remember now
Re camera flash: we have something way more interesting - you get a flash firing just before making picture. So, exposure is set assuming flash and the picture is taken without it. As a result, mostly black square is what you get as a photo 
Re overexposure: I don’t know where exposure is calculated. Would expect it to be in the BLOBs
Re lipstick: In our case it is probably due to some AOSP10/BLOBs bug. At least AOSP developers told that there are some issues with rendering of singlesurface (whatever that means). As we can resolve it by bumping GPU frequency, I think we are good now.
Re Sony related or not: hard to judge. AOSP/Sony is using QCOM BLOBs. Whether they have similar bugs on other devices, I don’t know
The beta release fixed the slow framerate issue. The phone feels nice.
Beta is prepared for release, not released yet. Wanted to test a bit before tagging it.
Hehehe. Saw the update on github and followed the alpha to beta OTA thinking we are good to go.
No harm done. The only think i noticed was that i didn’t have zgovernor installed and i got a “no such package” message. Everything else was on point.
At least we know that works.
Its good to know that OTA works. I presume that zgovernor issue was a response to uninstall request in the beginning of the instructions, right?
Yes. There was nothing to uninstall.
As there were no requests on keeping AOSP9 and all of those who have been testing AOSP10 based builds seem to be OK with it, I am going to conclude this discussion and we are switching to AOSP10 based port.
My own impression of AOSP10 based port are positive. Few days ago zgovernor has been updated and takes care of GPU scaling to ensure that the glitches are absent or very rare on XZ3 (as far as I know) and interaction with Lipstick is smooth. The power drain seems to be OK (handles similar amount of time as earlier for me), but I will leave it to others to compare.