Jump to content

OS virtualization and emulation on Android

Add links
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Aceing Winter Snows Harsh Cold (talk | contribs) at 19:40, 20 November 2019 (Save edit of large amount, so that if something happens between now and next edit, the edits done in this edit are not lost.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Just like in computers, Android (operating system) devices have the ability to run virtual machines or emulate other operating systems. It does this either via desktop virtualization, platform virtualization, or emulation via compatibility layer.


Desktop vitualization

For General not just Android specific information on this topic see: Desktop virtualization

Platform virtualization

For General not just Android specific information on this topic see: Platform virtualization

Platform based virtualization allows more leverage to the developer as anything that relates to the guest operating system only afects the guest operating system, and not the host operating system. Due to this it is possible for the guest operating system to be rooted, where as the host operating system remains unrooted. Due to the natue of platform virtualization and the fact that it can virtualize an rooted guest OS, it has a greater advantage over emulators as they an run applications or utilize packages that require access to the underlying system itself.

Emulation

Types of emulations

Emulation of other Operating Systems

Emulation of other operating systems on Android require the usage of some form of compatibility layer, where the compatibility layer must utilize some form of technologies or APIs to run the OS inside of the app container. This does come with limitations as some emulators utilize PROOT which is a chroot like environment. Unlike terminal emulators that emulate the internal OS with/without any extension package support, can be able to install actuall ubuntu packages, as they do not rely too much on the Android system limitations. However not all packages and applications can run.

Terminal Emulation of Internal Operating System

Terminal emulation of the Android device itself is done via either an actual local loopback to the device, or an emulation that seems to be a local loopback. Most of these terminal emulation of the device itself utilize the native terminal Toybox library and functions that come with every android device. However due to the fact that the majority of the functions that are readily available without utilizing a compatibility layer, means that Toybox functions can only be utilized. In order for a user to add any other functions or libraries would require the user to root their own device and add the functions or libraries manually. Some of these terminal emulators allow users to enter toybox commands implicitly (ex. Draft:JuiceSSH), where those that don't require the usage of "toybox COMMAND".

With Enhancements via semi-emulation

Some terminal emulators like Draft:Termux allow users to add packages. This is done via semi-emulating a different environment via the usage of PRoot and Toybox in the backend. With the semi-emulating, some predifined proted packages can be used and installed without the need of rooting the device, as they do not utilze Android system files, and reside and run in the apps own data containers and directories. Because Toybox is used mostly in the backend, it depends on how the app was developed, for toybox to be accessed from the semi-emulated enhanced terminal.

Extensions

Many emulators of other OSes allow the usage of extensions. Other than the use of standard SSH, some emulators allow the use of technologies like VNC and XSDL. Via the use of these extensions, the user can have the emulated/virtualized OS running in an desktop like environment.

Limitations

The majority of limitations are seen in emulation based apps rather than the platform virtualization based apps, as the emulation apps must utilize a compatibility layer. Thus for libraries and packages to work as expected like in a real OS, the compatibility layer must work properly and must be able to provide the acurate information. However, this requires that the comapatibility layer or any predifined software it uses (ex. Docker) to have access many system related and device related information, which can either be done via utilization of Toybox, or via programing language libararies that Android apps can be made form like, Java, C#, and ect. Although starting from Android 8, many new security restrictions have been placed on apps, and due to these restrictions some API libraries/classes are no longer available or have been replaced by a more restrictive API libraries/classes.

One of the known limitations that were implemented was that apps can only natively access only their own app sandbox root directory or subdirectories on an SD card. Apps wanting to access files or folders outside that on the SD card, are required to use Android's own system file selector. Due to this guest OSes running on, emulation, platform virtualization, or compatibility apps are no longer allowed to access files outside of their own sandbox.

Majority of these limitations can be bypassed by rooting the Android device, however utilizing Linux via utilzing an emulator or virtualization app would be redundant at that point.

OS Internal Security Enhancements

More modern versions of Android have been seen having more internal system security enhancments, such that some system folders and files are no longer accessible or even viewable for that directories existance. Versions of Android before 9, allowed terminal apps to view Androids root "/" directory (although not allowing modifications or execution).

SELinux

Android utilizes SELinux, and due to this all, system configuration files are not editbable, as well as some are not even readable. Thus apps can only utilize Android API's to learn about the device or system's configuration or settings. However, not all information are avaible to apps, and due to this many OS complatibility layer or emulation apps are not able to run every package or application.

Some known applications or packages that are unable to run are the following  :

  • Udisks2 requires udev which does not work well in most compatibility layer environments, as stated in the sub-sub-section bellow.
  • Snort
  • Open vSwitch
  • mininet (requires open vSwitch to run)

Some commands that do not work due to SELinux  :

  • ip link show

ADB, Prroot, $HOME and $PREFIX usage

Because all Android apps run in an non-privlaged container space, thus the virtualization or emulation apps must utilize their own app space to do the virutalization or emulation. This can be done either by ADB, PRroot, or the usage of $HOME and $PREFIX, however majority of these three are utilized by emulation apps as platform virtualization apps usually use different methods. The usage of each is used for different purpouses. ADB is used for the emulation of an terminal like environment for the entire Android system, but usually as an unprivlaged user. $HOME and $PREFIX can be using $HOME as "~" and $PREFIX for . However, $HOME can not be set outside of the "/data/apps data space" directory on the android file system, nor can $PREFIX be moved to another place like the SD Card.

For emulators or compatibility layers to emulate or virtualize a Linux based OS on Android PRoot must be used. However when PRoot is used, the environment inside of Proot can act like a Chroot environment, and/or a seperate mounted environment. In this scenaro (especialy in the case of compatibility layer and emulator for Guest OSes, there are packages and applications that can not run as they were never designed to run inside a chroot like environment. Some of these well known promnent packages, applications, or commands are the following  :

Alternatives

Due to the issue of SeLinux and PRoot alternatives must be used, not all of the unusable packages or applications have alternatives, and the alternatives don't neccessarily have all the functions of the original packages or applications. Some of these alternatives include  :

Android itself being a modified Linux kernel

Because Android is a modified Linux kernel, not all configuration or system files exist or are the same in Android. Because of this emulation apps either need to provide either their own version of the configuration or system files in its application data space, use a pre-modified distibution of ported Linux libraries that do not requie the usage of the missing configuration or system files, or not support the usage of those packages. Some of these configuration and system files that are not in Android and are well known are  :

  • /etc/resolve.conf

See Also


References

Retrieved from "https://en.wikipedia.org/w/index.php?title=OS_virtualization_and_emulation_on_Android&oldid=927164984"