Mir servers fail to run on devices that ship with CAF's Android for MSM 7.1

[UniversalSuperBox]

This issue is part of the road to Halium, issue #404.

Due to a very interesting change by an engineer at Qualcomm, binaries which use hwcomposer are incompatible between AOSP 7.1 and CAF 7.1. This means that any Mir server that we have in the base image (Unity-system-compositor, Unity8 itself, the Mir demos) will fail to run on a device which uses' Qualcomm's libhwcomposer. In simpler words, our rootfs is broken on practically all devices with Android 7.1. The only exceptions are some devices from Google and Sony, which run AOSP wholesale.

We've tried to fix this problem in the past by building with https://github.com/ubports/android-headers/commit/1b0bea36ab181c5bc6907319ce7c286c10080d2d for all devices. This worked for every device... except for our Exynos Pro 5. Oh well, back to the drawing board.

From my perspective (based on hearsay and piecing together what the exact problem is), we could try the following solutions:

Second Mir platform

Create a second Mir platform, android-caf, which correctly handles the ABI changes. Find a way to determine whether to use android or android-caf at runtime.

Pros

• Cleanest solution, probably involves the least long-term work.
• If we're particularly clever, we might be able to get both platforms to come out of one build tree

Cons

• We aren't able to realize this until we upgrade to at least Mir 0.28, the first version with support for out-of-tree platforms.
• There is no obvious way to determine if a device is AOSP or CAF at this moment.

Separate rootfs

This is the solution that we were working with before. We simply built a second repository and rootfs using the 'caf' headers. The rootfs hasn't been built in about three months and there are some changes to pipelines in other repositories that break it.

Pros

• Involves the least short-term work
• We can finish it before we upgrade Mir

Cons

• Involves the most work long-term as we need to merge back all changes in the xenial branch to xenial-7.1-caf

[UniversalSuperBox]

We have a small update to this issue. Marius has created an additional Android platform for Mir that is built with the CAF headers. Installing this means... graphics work on CAF 7.1! However, there's a larger problem. Mir isn't able to detect if it needs to use the CAF or non-CAF Android platform. That particular problem will need to be fixed before we're able to close this issue. This does get us closer to our ideal situation, we just aren't there yet.

If you would like to try this on your Halium port using Qualcomm's Android for MSM 7.1, you can run the following commands as root on a read-write image:

echo "deb http://repo.ubports.com/ xenial_-_caf-mir-platform main" | sudo tee /etc/apt/sources.list.d/mirplatform.list
sudo apt update
sudo apt install mir-client-platform-android-caf5 mir-platform-graphics-android-caf10 mir-graphics-drivers-android-caf

[jtbrooks]

@UniversalSuperBox What happened to those packages? I can no longer find them in the pool.

[APokorny]

They are now pat of the xenial_-edge rootfs and can be found in the xenial-_edge

[UniversalSuperBox]

As stated before, this is already included in the edge rootfs.

I am adding this to the OTA-7 project since our goal is to merge the android-caf Mir graphics platform in this release. This will make it easier for porters to bring Ubuntu Touch to their device.

[doniks]

Just so I understand it correctly: We still don't know how to detect which one we should use right? At least for the halium port on Nexus 7 deb I had to rm graphics-android-caf.so.10 to make sure it uses the non-caf one.

[UniversalSuperBox]

Yes, the same issue occurs on flo currently. We need to have something available to correctly detect. The final product is ultimately up to @APokorny, but we could consider just saying "if Android <= 5.1, then use android.so.10."

[peat-psuwit]

On detection issue, I think we can set a property from Android makefile when TARGET_USES_QCOM_BSP is set. We can call this property ro.hybris.qti_bsp. Mir then can check this property to decide which platform to load.

Problems:

• Not sure which makefile should set it.
• Halium must agree to put it in. However, it shouldn't be too obtrusive, so this probably isn't a big problem.
• Does Mir already read Android property? If not, we might not want to introduce that.

[APokorny]

I currently use the build number property - do you see a need to force either of the two graphics platform modules via another switch? I.e. if there is are 7.1 or later hwc module that claim to be shipped by "CAF" but without the ABI changes @peat-psuwit ?

Additionally we could tell porters to just set a build time property to help platform selection.. - that would not require a halium makefile change then..

[UniversalSuperBox]

Right, if there's a real need to load another new platform we can grow that when required. Alternatively, that config can be provided through the device tarball.

[NeoTheThird]

Admin issue: Why is this open and in qa? Shouldn't it be either closed or moved to in progress? Do you need anything from QA?

[mariogrip]

Sorry, i just moved it in the project board, forgot to close it.

[amrithmmh]

I have the exact same problem. which rootfs image should i use? edge- rootfs?
https://pastebin.com/a5RMr5Fc