@kugiigi I was supposed to grab three suzu devices and accidently bought doras - so I had to adapt the port. Overall it is still not as polished, and it does not feel faster - yet. There is still something odd. Moving to arm64 made it snappier and removing the disfunct thermanager also helped. Still battery usage and overall performance should be better.

@Tellina Depends on what state your phone is in - when you do "fastboot devices" the blue led has to glow, otherwise it is not in fastboot mode, or the USB cable has issues, or the USB hub in your system has issues.

@jdavid_t said in Sony Xperia X Performance (dora/F8131 & F8132):

updates

What channel are you using?

$ system-image-cli --info

@malditobastardo camera/video and loss of wifi configuration will be fixed through ubports rootfs updates. The former could be manually fixed by using gst-droid. The latter is a kernel issue that makes temporary mac address changes of the wifi chip fail - but undetected by network manager. A newer version might fix that..

@MaxSo216 I made some attempts with xz1. Fixed issues in the sony kernel. But besides that it is more different than expected. It shows multiple flash devices. It will be possible but will require more time, that I do not have right now.

If you pick up a XZ and XZs I can help you complete a port. Both are tone too, and will be trivial to add.

Update 25.08.2020: New channels

The installer currently offers a lot of channels to be installed

• 16.04/community/anpok/devel
• 16.04/arm64/hybris/rc
• 16.04/arm64/hybris/devel
• 16.04/arm64/hybris/stable
• 16.04/arm64/edge

At the moment only 16.04/arm64/hybris/devel and 16.04/arm64/edge are supposed to work. The one in community is still armhf and should be removed one day. YMMV but on the last test of the installer it failed to identify the device. I manually selected dora. If you are stuck in some place there are ways to help the installer... just post here or pm...

Update 23.08.2020-25.08.2020: OTA update issue

There seems to be an issue with the OTA update since a few weeks. Symptoms: If you try to update the system it will download andreboot to recovery, within recovery nothing happens. You can only reboot. This seems to happen because there are two recovery directories in the fs, and download happens in one, while installation is meant to happen from the other.
I just verified that this is fixed with OTA-80, but to upgrade you need to adb shell into the recovery. And move the downloaded files into the other. Then run /sbin/recovery. Alternatively run the installer again

--

This is a port of Ubuntu Touch for the Sony Xperia X Performance (dora/F8131 & F8132).

This is the first port out of the sony tone platform series, which followed the loire platform. It is heavily based on the port for the loire platform. Hence it shares all of its features. Initial porting was done by sjlllls. (https://forum.xda-developers.com/xperia-x-performance/development/testing-ubuntu-touch-xperia-x-t3960133)

Sources:
Kernel (yes we share kernel with suzu and kugo, it might also be fine for yoshino):
https://github.com/fredldotme/device-kernel-loire

Device:
https://github.com/fredldotme/device-sony-common
https://github.com/fredldotme/device-sony-common-init
https://github.com/sjllls/device-sony-tone
https://github.com/sjllls/device-sony-dora

Halium:
https://github.com/Halium/halium-devices/blob/halium-7.1/manifests/sony_dora.xml

Status:

Working:

• Audio
• Calling
• SMS
• Wifi
• Wifi hotspot
• Bluetooth
• GPS
• Vibration
• Orientation sensor
• USB/MTP
• USB/ADB
• Video decoding
• Photo camera
• MicroSD support
• Flash light
• Anbox

Missing known issues:

• Video recording
• proper camera config: zoom, force flashlight
• audio playback is only crisp when screen is off
• LED
• Wifi configurations are not used for wifi device - user has to reenter the password
• Libertine
• Dora channel was moved and is now aarch64/arm64, if you have installed before, please switch to the new channel: system-image-cli --switch 16.04/arm64/edge -v

Install:

Make sure to upgrade your device to the latest stock Android 8.0 before continuing (search for a version like 41.3.A.

• Windows: https://developer.sony.com/develop/open-devices/get-started/flash-tool/
• Linux: http://www.flashtool.net/downloads_linux.php (run with GTK_IM_MODULE=ibus ./FlashTool) and https://xperifirm.com/tutorial/install-xperifirm-linux/

After upgrading boot android at least once so that the upgrade can complete.

OEM unlock your device: https://developer.sony.com/develop/open-devices/get-started/unlock-bootloader/

Boot your device into fastboot mode by shutting it down and keeping the Volume Up button pressed while plugging in a USB cable between your phone and PC. The LED should be on and blue.

In case of flashing issues please wipe system, data & cache partitions using TWRP

Flash the OEM binaries from: https://developer.sony.com/file/download/software-binaries-for-aosp-nougat-android-7-1-kernel-4-4-tone/ using fastboot flash oem SW_binaries_for_Xperia_AOSP_N_MR1_5.7_r1_v08_tone.img

If the above fails the baseband and bootloader upgrade did not work.

Run the upcoming UBports Installer (probably 0.4.19beta and onwards):

• Bring the device in fastboot mode as described by the installer
• It might fail to detect dora/X performance so manually select it that case
• Untick writing system partition via fastboot - this fails often - writing system partition via adb in recovery works better
• select 16.04/arm64/hybris/devel (in the future rc and stable might be populated too)
• if the installer fails after downloading the system image - retry
• if the installer fails again and does not reboot into the "recovery mode" showing the ubports robot, you can bypass the issue by manually flashing the recovery image using:
  $ fastboot flash boot .cache/ubports/dora/firmware/halium-unlocked-recovery_dora.img

This is meant to be a small report on some of the development efforts happening around the mir source code within the Ubports community.

Current Situation of mir usage
The upcoming xenial rootfs for ubports uses mir 0.24. The version of mir was released back in september 2016. In the process of enabling Ubuntu Touch on newer devices, the ubports team fixed a handful of problems in mir. To also support android 7 system images on qualcomm devices a more substantial change was done on mir 0.24. A second android platform driver was added, because the hardware composer abstraction for those devices use a different incompatible ABI.

The future
Meanwhile upstream mir moves on. There is a long list of fixes and improvements and a growing list of big changes.

It saw the addition of wayland as a supported client protocol and XDG-shell window management protocols. Ongoing improvement and the integration of the miral library. There is still ongoing work to support Nvidias EGLStreams proposal....

Obstacles
Of course we should move to the current version of mir to benefit from the ongoing support and improvements, but there are also problems ahead.
The mir team had to drop the android platform. The term platform in the context of mir means server and client side abstraction, in this case abstraction of graphics. The other platforms in mir are mesa+kms(graphics) mesa+x11 (graphics and input) eglstream+kms(graphics), nested(graphics and input) and evdev(input).

Resurrection and second death
Right after the android platform removal the ubports team resurrected the android graphics platform into a separate repository and proposed a few changes to upstream mir to support building and running a 3rd party platform outside of the source tree of mir. The repository can be found here. After that the source code of the android platform started to rot since ubports did not need to move to a newer version of mir (prior to switching to xenial). Now the platform source no longer builds against upstream mir. So the source died twice.

Finally with some free time on my hands I returned to the UBports effort and will pick up the lose ends around the android platform. Getting it to run and integrating the fixes should be simple task. But there are also interesting things ahead like supporting the new hardware composer interface in android 7 and later.

There are still further fixes necessary for halium-7 caf and non-caf devices. But there are a handful of CAF ports in flight.

I meant deb .. not flo

@doniks You might want to try the google_msm kernel in ubports. It already contains the apparmor and other backports:
https://github.com/ubports/android_kernel_google_msm/tree/ubp-5.1

but it does not contain a reasonable kernel config for flo.

You could also verify that the user space binaries and firmware files are being picked up get copied into the out/target/product/...../system directory.

If none of that gets you any further - use adb while in recovery and go to /data/system-data and examine the var/log files for clues..

@Mitu
Wayland
You do need a software package that acts as a compositor. Wayland is a protocol generator like protobuf + event loop. Mir was created because back then there was no framework to write a compositor. As a result every desktop shell project ended up writing their own solution for everything. None of them have a driver model (see how well the streams integration is coming along). The default EGL integration is bad for system-compositor / session compositor setups...

@sverzegnassi
Mir
On the mir on wayland topic - I do intend to maintain the android platform on mir, i.e. there is now: https://launchpad.net/mir-android-platform. Canonical has no plans on supporting the libhybris integration. So I plan to add HWC2 in the near future - at least soon enough for Ubports to switch to android 7.

Besides that I do think that integrating wayland xdg-shell clients is worth trying - but there are some interesting problems to solve around the trusted prompts and the drag & drop support through content hub.

Snap support and/or Snap based system

• Content Hub and content interfaces are orthogonal concepts - applications communicating via content hub just need access to its dbus interface afaikt
• content interfaces would be used when you want to share libraries between snaps - i.e. qt gtk and other big chunks.
• For an all snaps image I expect that we would still require more interfaces than those that are already inside snapd - for an all snaps image we would have to ship the android user space libraries loaded via hybris either in a separate or inside the gadget snap and then expose access to libhybris out to those snaps that would access it.

Btw there is now android boot loader support: https://github.com/snapcore/snapd/pull/3324