Flatpak is a meta-port in some sense. It doesn’t have to do much with Jolla as it was not setup by them. Hence there is nothing for Jolla to solve.
But let’s not deviate in terms of who has to solve Flatpak issues on AOSP10 - I tried and it didn’t work out - but keep it regarding Tama port.
The main cause of the issues boils down to the quality of the provided blobs which also adds a dependency to a particular kernel version.
Option 1 and 3 will use the same kernel (4.9) and blobs, the camera issue will remain the same, in option 3 apps will need to be from aarch64 right? no idea if there is any compatibility with containers.
In option2 there are some issues mainly high consumption while idling, but the rest of the stuff will be similar to SFOS aarch64.
I do not know much on LOS so it’s difficult to comment for this option, some devices will not make it to that port and the result is unknown.
What about an option 5 AOSP11/aarch64 (I know I show my ignorance now) but in longer term can be an option as SFOS will have to officially support newer devices, e.g. 10 iii. Again here we have to rely on the quality of the blobs, but work for this version is still on going?
Re option 3 (AOSP9/aarch64): yes, camera will be the same as for current AOSP9/arm32 port. Flatpak will most probably work. There could be surprises, but expectation is that it will be working. As for SFOS apps, it would be the same as for other aarch64 ports (xperia 10ii, for example)
Re AOSP11/aarch64: in principle, it is possible. Tama is supported and BLOBs are published for it. As for quality, I don’t know. If it is way better than AOSP10 or 9, would make sense to switch when SFOS will support it. Which could be spring 2022. However, I suspect Tama is not the main priority for AOSP11, it is probably newer devices, such as 10iii when it will get there.
If battery drain could be fixed, I would like to go forward with AOSP10, aarch64, (I don’t use Flatpak, and aarch64 apps are staedily being produced, plus I have pretty easily biilt the ones I want from available sources device).
LOS17 sounds interesting to me, being a widely-used and continually developed source, so maybe promising better function and stability overall, but I would hardly wish it on you to have to dive into all that, just bases on my experience with LOS Android. I don’t understand much technically, but it seems pretty complex, and I would get the sense that ot might be quite a project, like a whole new port from scratch or something. If you took it upon yourself, I would look forward to see what could come of it, and would be glad to test/donate, bit couldn’t be much more help than that. I messed around with Android for years, and remember Cyanogenmod fondly, but I haven’t touched LOS for a few years, and have found it to be relatively hard to modify.
Thanks again for your work.
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.