When inspecting mount points, you'll notice numerous records associated with Halium and other LXC containers. Halium serves as the hardware abstraction layer which enables Ubuntu Touch to function with an Android-based kernel. Essentially, it's an LXC container that runs Android services and facilitates communication with hardware. A chroot can be used to directly access the Android rootfs provided by the vendor, although that is very much 'advanced' use.
This tool provides a user-friendly interface where you can simply enter the name of the package you want to install. Once the installation is complete, the launcher icon for the newly installed application is seamlessly added alongside other launchers in the main menu of Ubuntu Touch. You can see how this looks in the following video.
The main challenge is that most applications were not designed for small screens or tested on them. Fortunately, Ubuntu Touch has a solution to this through its automatically invoked convergence mode. When you connect a large display via USB-C (or where supported by means of casting), the Lomiri UI automatically switches to a familiar desktop interface. Convergence Mode is used to mean Screen Casting and Desktop Mode. While this is common usage, it is not completely accurate, it is much more complex one code adaptability to usage scenario (mobile, tablet or desktop). In fact it means that applications follow the shell (graphical user interface) and can immediately be used in windowed mode, allowing you to resize and move windows, and to perform other actions typically associated with desktop UIs. Remarkably, the phone's screen simultaneously transforms into a touch-pad.
Ubuntu Touch enables Android applications using Waydroid, which runs these applications in an LXC container, with user interface rendering provided by Mesa, with minimal overhead. Depending on the device, it may use the vendor-provided rootfs or, for devices like the PinePhone, the LineageOS image.
Various points to consider related to running Android apps using Waydroid:
* Work without any issue: Some apps run seamlessly.
* Fail because they rely on Google Services: Apps relying on Google Play Services, like those using OAuth2 or Google Maps, may encounter issues due to licensing restrictions which block installation on non-Android devices.
* Face problems because they check for bootloader and rootfs consistency: Certain apps, particularly banking applications, check for filesystem consistency and bootloader status, which can pose compatibility challenges.
* Cannot run since they lack a hardware component: Some apps may have unique hardware requirements or rely on hardware features not fully implemented in Waydroid.
While Waydroid does enable some Android app compatibility, there are a few drawbacks. Beyond the extra CPU usage for managing containers, issues can arise from the interaction of two operating systems, especially during device suspend and wake-up. Non-native apps like WhatsApp can have a greater impact on battery life compared to native apps.
Waydroid is essentially a workaround and needs to be manually installed into the OS. While many things do work, it's still an experimental feature, and some applications will not function as expected.
Native apps on Ubuntu Touch are created using Qt and QML, and they get installed through something called Click packages. These packages are created using a handy tool known as Clickable. It is basically a Python script that bundles together all the necessary tools for app building and development. It includes commands for compiling your app, installing it to your device, running and debugging it, and finally, uploading it to the OpenStore. This process relies on dpkg and Docker containers. Inside these containers, an environment is created with all the needed dependencies in the correct versions. You can easily select your desired target architecture, either x86 or arm64.
To set up the development environment, you start by adding the correct Personal Package Archive (PPA) and running the apt install clickable command. After that, you initialize the environment with the clickable setup command. To create a new project, you use the clickable create command, and when you're ready to run and debug your project, you simply use clickable desktop . During the first run, a Docker container is automatically downloaded, which handles the compilation and execution of your project.
The resulting file from this process, the Click package, is somewhat like a *.deb package, but has some limitations. Notably, it doesn't allow external dependencies. Instead, it relies on the UBports framework exclusively. However, if your app must have additional dependencies, you can bundle them into the Click package. These dependencies should be loaded during startup using the LD_LIBRARY_PATH environment variable.
The files from these packages are installed in a directory located at /opt/click.ubuntu.com/hello-world/1.0.0, where "hello-world/1.0.0" represents the app's name and version. This directory is not included in the PATH environment variable. To start the application, a *.desktop file is used, which launches it from that directory. The script's path is relative to this directory (for example, ./run.sh). Any user data created by the application is stored in the Home directory. just like with most applications. If you want to inspect the contents of a *.click package, you can do so by renaming it to *.deb and using tools like Midnight Commander.
At first glance, you might think that these applications run within a container, overlays, or similar setup. In fact, the required libraries are used directly from the Ubuntu Touch operating system itself. There's no need for an additional separation layer because Ubuntu Touch employs a read-only filesystem and AppArmor to manage security between applications.
Ubuntu Touch uses AppArmor categories to control access to all basic APIs, making sure that applications run safely.
Various points to consider related to running Android apps using Waydroid:
* Work without any issue: Some apps run seamlessly.
* Fail because they rely on Google Services: Apps relying on Google Play Services, like those using OAuth2 or Google Maps, may encounter issues due to licensing restrictions which block installation on non-Android devices.
* Face problems because they check for bootloader and rootfs consistency: Certain apps, particularly banking applications, check for filesystem consistency and bootloader status, which can pose compatibility challenges.
* Cannot run since they lack a hardware component: Some apps may have unique hardware requirements or rely on hardware features not fully implemented in Waydroid.
While Waydroid does enable some Android app compatibility, there are a few drawbacks. Beyond the extra CPU usage for managing containers, issues can arise from the interaction of two operating systems, especially during device suspend and wake-up. Non-native apps like WhatsApp can have a greater impact on battery life compared to native apps.
Waydroid is essentially a workaround and needs to be manually installed into the OS. While many things do work, it's still an experimental feature, and some applications will not function as expected.
To set up the development environment, you start by adding the correct Personal Package Archive (PPA) and running the apt install clickable command. After that, you initialize the environment with the clickable setup command. To create a new project, you use the clickable create command, and when you're ready to run and debug your project, you simply use clickable desktop . During the first run, a Docker container is automatically downloaded, which handles the compilation and execution of your project.
The resulting file from this process, the Click package, is somewhat like a *.deb package, but has some limitations. Notably, it doesn't allow external dependencies. Instead, it relies on the UBports framework exclusively. However, if your app must have additional dependencies, you can bundle them into the Click package. These dependencies should be loaded during startup using the LD_LIBRARY_PATH environment variable.
The files from these packages are installed in a directory located at /opt/click.ubuntu.com/hello-world/1.0.0, where "hello-world/1.0.0" represents the app's name and version. This directory is not included in the PATH environment variable. To start the application, a *.desktop file is used, which launches it from that directory. The script's path is relative to this directory (for example, ./run.sh). Any user data created by the application is stored in the Home directory. just like with most applications. If you want to inspect the contents of a *.click package, you can do so by renaming it to *.deb and using tools like Midnight Commander.
At first glance, you might think that these applications run within a container, overlays, or similar setup. In fact, the required libraries are used directly from the Ubuntu Touch operating system itself. There's no need for an additional separation layer because Ubuntu Touch employs a read-only filesystem and AppArmor to manage security between applications.
Ubuntu Touch uses AppArmor categories to control access to all basic APIs, making sure that applications run safely.