# Aros/Platforms/Installing on Android

* Navbar for the Aros wikibook
* Aros User
* Aros User Docs
* Aros User FAQs
* Aros User Applications
* Aros User DOS Shell
* Aros/User/AmigaLegacy
* Aros Dev Docs
* Aros Developer Docs
* Porting Software from AmigaOS/SDL
* For Zune Beginners
* Zune .MUI Classes
* For SDL Beginners
* Aros Developer BuildSystem
* Specific platforms
* Aros x86 Complete System HCL
* Aros x86 Audio/Video Support
* Aros x86 Network Support
* Aros Intel AMD x86 Installing
* Aros Storage Support IDE SATA etc
* Aros Poseidon USB Support
* x86-64 Support
* Motorola 68k Amiga Support
* Linux and FreeBSD Support
* Windows Mingw and MacOSX Support
* Android Support
* Arm Raspberry Pi Support
* PPC Power Architecture
* misc
* Aros Public License

## Introduction

* 2011 Sonic Amiga's port of almost working Android-hosted AROS - display is 100% correct (you see background and correct alpha channel), and touchscreen input works. Just very slow. Java part is being optimized. Posted on: 2011/8/18 11:17
* 2012 development slows
* 2014 some further work done
Android-hosted port is a new, progressing development. It's not emulating a CPU. AROS is launched as a separate process on top of Linux kernel, leaving JVM aside. Java-side runs a simple X11-alike server, which AROS talks to and uses for the display. So it's ARM AROS. Android OS can be viewed as a subset of Linux, so functionality of this port is the same as of generic UNIX-hosted port.
This is Google Android-hosted port of AROS. Android is a subset of Linux system, so many functionality of this port is the same as of a generic Linux-hosted port. Both ARM and i386 architectures are supported, however only ARM is tested.
A minimum required Android version is 2.2 (API level 8).
DOWNLOAD
* Last official build for android-arm or the [ i386] version
* Last AROS-20141011-android-arm-system.tar.bz2 unofficial build,
[ Git repository], Aros sources and others here
Currently a number of small issues exist but they are in the process of being fixed.
An intensive development is needed to remove these limitations.
There is no way to activate a keyboard - i.e. no virtual keyboard, a fully working virtual keyboard, feeding input.device with keypresses. Or even HIDD subsystem (the most low-level stuff). This commodity needs some nice way to hide and show itself. And lack keys on keyboardless machines. Menu is already occupied by menu; Home is reserved for host OS, Back currently sends Lamiga+M (only Intuition doesn't support it yet - no time to fix). Well, Search on some machines like Nexus One. Would be nice to be able to add something to screen bar. This way more gadgets could be added like e.g. open menu or virtual keyboard, which would always be accessible. This is especially important considering future iOS port - Apple machines have no usable keys at all. Then, Zune could be extended to inter-operate with virtual keyboard and pop it up automatically when a string gadget is activated.
There is intentionally no support kludges that would make use of Android's own virtual keyboard. AROS is not an emulator, it's an operating system by itself, and it should contain own support for such things, independently on what it's running on. Remember that one day AROS will run natively on these devices.
The same reason prevents AROS from supporting autorotating screen. AROS user interface libraries currently has no concept of screen rotation, and it's unclear how it can be implemented (however it's not impossible).
the right mouse button has been disabled
Note that trackball found on NexusOne phone is of a very poor quality. It is supported by AROS as a mouse, however the cursor speed will be very slow, even if you turn on the acceleration. This is a property of the trackball itself and it can't be fixed by software. Android OS uses it to emulate keypad, not as a mouse. Perhaps AROS should do this too, this is subject to further development.
A lack of arm ported software, should be a matter of re-compilation. Although i have no idea for their dependencies and support for android (if needed at all). Due to lack of developers it is also not a priority. Most of them work constantly on improving AROS itself, not on porting software.
http://photo.qip.ru/users/sonicamiga/3814258/94190382/full_image/

## Installation

In order to install AROS to your Android device, do the following:
* Extract the archive.
* Inside the archive you'll see an AROS directory. Copy its whole contents to the SD card (or whatever else removable media your device uses.)
* Install the supplied AROSBootstrap.apk in your device.
Please note that minimum required Android version is 2.2.
In order to install AROS on your Android device, you need:
There's nothing particular about this. Run 'AROS' application and enjoy. Note that AROS was initially developed as a desktop OS. Android-hosted port is the first completed port to run on mobile devices. Consequently, AROS lacks many features that could make it a mobile system. First of all, AROS lacks a virtual keyboard. Second, user interface is not optimized to be operated by fingers and/or keypad. If your device has a keyboard, AROS will support it, however this was not tested yet. 'Menu' key found on most of Android devices emulates right mouse button and 'Back' button emulates LAmiga+M sequence (screen switch).
For more comfortable use you can do the following:

## Configuration

Since Android OS has no command line, you can't watch debug output in real time without any external tools. However, you can redirect it to a file using bootstrap's own functionality. In order to to this you'll need to edit AROS/boot/AROSBootstrap.conf file and add 'logfile <file_pathname> option to it.
In a similar manner you may pass command line options using "arguments <your-options>" option in AROSBootstrap.conf.
It remembers orientation in which it was run. So, if you hold the device in landscape mode, you'll get landscape, until you shut down (reboot, both cold and warm, keeps the orientation). Have ideas on how to implement two orientations as two different screen modes, so that you'll be able to switch between them using Screenmode prefs, and also specify different programs (which support own screens) to use different orientations. But have no time right now, finishing up with generic software screen drag implementation (will work on Android too). Will get back to Android-hosted display when done. No support device rotation on running AROS at the moment, because AmigaOS previously had no clue about rotating displays. Consequently, software can't rotate on the fly. It's not totally impossible, just some Zune/Intuition extensions need to be developed from scratch. No one has ever ran Amiga-family OS on a mobile device before.
However, it's actually possible to run AROS in both landscape and portrait orientation. Both orientations are available as different display modes in ScreenMode preferences program.
Please report about your keyboard experience. Some keys can be missing (especially LAmiga/RAmiga) so keycode table is typed blindly, according just to documentation. So all your suggestions about improving keys mapping are welcome.

## Support

Android OS currently supports i386 and ARM processors. AROS can be built for both these architectures, however currently only ARM build is in production. i386 version was not tested as there was no test environment available.
The vast majority of modern ARM devices have ARMv6 or better processor with VFP floating-point unit. This configuration is currently the minimum requirement to run AROS. However, some Android devices were available on the market, whose processors are below this requirements typically up to around the year 2011. Known non-working processors are:
* Qualcomm MSM7225 (ARMv6 but no VFP at all)
* VIA 8650 (ARMv5)
This is a list of test results on various hardware and Android OS versions:
| Device name | CPU core | Android OS version | Linux kernel version | AROS Test build | Test results |
| Ainol NOVO7 Aurora 2 | 1.5 GHz ARM Cortex A9 Dual Core Amlogic AML8726-M6 | 4.0.3 (ICS) | | | Black screen, system halts during bootup |
| Archos 70 | 1 GHz ARM Cortex A8 (TI OMAP3630) | 2.2.1 (Froyo) | | | Working fine. CacheClearU is known to trigger host system reset (hardware-specific glitch) |
| Google Nexus One (HTC Passion) | 1 GHz ARM Cortex A8 (Qualcomm Scorpion) | 2.3.4 Build GRj22 | 2.6.35.7 59463-g52630a3 | | Working fine |
| HTC Desire | 1 GHz Qualcomm Snapdragon (QSD8250) | 2.2 (Froyo) | 2.6.32.15 | | Working fine |
| HTC Evo Shift 4G | 800 MHz Qualcomm Snapdragon S1 (MSM7630) | 2.2 (Froyo) | 2.6.32.17 gee557fd | | Working fine |
| HTC Sensation | 2011 1,2 GHz Qualcomm Scorpion S3 Dual Core | 2.3.3 (Gingerbread, HTC Sense 3.0) | | | Error in C:Mount during DEVS:DOSDrivers processing |
| HTC Wildfire A3333 | 525 MHz Qualcomm Snapdragon S1 (MSM7225) | 2.2.1 (Froyo) | 2.6.32.21 g8f75634 htc-kernel | | "Illegal instruction" crash. The processor is below AROS minimal requirements. |
| HTC One XL | 1,5 GHz Qualcomm Snapdragon S4 Dual Core (MSM8960) | 4.1.1 (Jelly Bean, Viper XL 3.2.3) | 3.4.10 g240d4d5 root@abm033#1 SMP PREEMPT | | Working fine |
| LG Optimus Black | 1 GHz ARM Cortex A8 (TI OMAP3630) | 2.2.2 (Froyo) | 2.6.32.9 | | Working fine |
| LG Optimus One (P500) | 600 MHz Qualcomm ARM1136EJ-S | 2.2.2 (Froyo) | | | Working fine |
| LG Optimus Speed | 1 GHz ARM Cortex A9 Dual Core (AP20H) | 2.2.2 (Froyo) | 2.6.32.9 dirty | | Black screen, system halts during bootup |
| RoverPad 3W T71D | 1 GHz ARM Cortex A8 (Allwinner Boxchip A10) | 4.0.3 (ICS) | 3.0.8+ (inet_hxj @InetSoftware) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) # 106 PREEMPT | | Working fine |
| Samsung Galaxy S | 1 GHz ARM Cortex A8 (TI OMAP3630) | 2.3.3 (Gingerbread) | 2.6.35.7 | | Working fine |
| Samsung Galaxy Tab 2 | 1 GHz ARM Cortex A9 Dual Core (TI OMAP4430) | 4.0.3 (ICS) | 3.0.8 | | Working (but apparently not entirely crash free) |
| Samsung Nexus S | 1 GHz ARM Cortex A8 (TI OMAP3630) | 2.3.4 Build GRj22 | 2.6.35-7 ge382d80 | | Working fine |
| Sony Tablet S | 1 GHz ARM Cortex A9 Dual Core (AP20H) | 3.2 (Honeycomb) | 2.6.36.3 | | Working fine |
| Sony Ericsson XPeria X10 Mini Pro | 600 MHz Qualcomm Snapdragon S1 (MSM7227) | 2.1 (Eclair) | | | Working fine, keyboard needs specific keymap |
| | VIA 8650 | 2.2 (Froyo) | | | "Illegal instruction" crash. The processor is below AROS minimal requirements. |
| Motorola Droid Turbo | Snapdragon 805 Quad Core 2.65Ghz | 6.0.1 | | AROS-20141011 | Working - but crash prone No SD card slot on device, installed to internal storage |
Status of bugfixing:
* LG (and possibly other dual-core devices): The problem has not been confirmed on all dual-core devices. In October 2011, a bug has been discovered in icon generation tool, used in AROS build process, which caused trashing icon tool types. Corrupted icons caused system-wide memory trashing, which could be a reason for this problem. Icon generator was fixed, but there were no test reports.
* HTC Sensation: installation problem (MacOS X created accompanying dot-underscope files when the system was copied to phone's flash. The issue has been reproduced and addressed since 09.11.2011, but there is no confirmation (yet).

## Compiling / Build

In order to compile Android-hosted AROS you need:
One note: MinGW project does not offer netpbm package on their web site. It can be found in another project, GNUWin32. GNUWin32 ports perfectly cooperate with MinGW ones.
Note that Android-targetted gcc can't be used for building AROS binaries even with wrapper scripts. Android ABI is not 100% compatible to AROS one.
Configure script needs the following additional parameters to set up Android-hosted build:
This parameter currently can't be omitted at all. There is some default for it, however it is unlikely to fit your machine, since the SDK does not suggest any specific default location by itself.
If you omit this, AROS build system will expect to use standalone toolchain installed in your $PATH.
If you are not using a standalone Android toolchain generated from the NDK, you must specify it. Otherwise AROS won't be able to locate a gcc inside it. NDKs r5 and r6 are both supplied with version 4.4.3. If this ever changes, you can easily check which gcc version is contained in your NDK. Just look into "toolchains" subdirectory.
It specifies platform version to use within the SDK. Current minimum SDK API level is 12. Please don't confuse it with minimum API version required to run AROS, these are different. Java code uses some methods declared only starting from v12 API, however it works correctly if they are missing. High SDK version is required just to compile this code. You can easily look up what platform versions are supported by your SDK by examining its 'platforms' subdirectory.
This is different from SDK because: a) SDK doesn't include all levels included in the NDK; and b) AROS display driver needs some includes from API level 9 (despite AROS runs on level 8). This parameters defaults to 9 and will be needed if older API levels are dropped from the NDK at some point.
Android documentation says that APKs must be signed in order for the system to allow installing them. AROS build system is set up to sign the built application with "AROS" key located in $HOME/.android/AROS.keystore. If you are setting up the build for the first time, you need to create this key. In order to do this you need to use "keytool" utility supplied with the JDK:
Unfortunately, a certificate must have validity period. In this example we set it to more than 1000 years (for simplicity we count every year for 366 days). The longer the time, the better. AROS is not going to die! :)
After this command keytool will ask for your personal data. It's recommended to fill them in correctly, this can help to identify origins of the build. When the keytool asks you for key password, use 'aros.org'. This password is specified in build.properties file of the Java project, this allows ant to operate fully automatically and not to ask you for the password every time. This is especially useful for automated (e. g. nightly) builds.
Remember that AROS is an open project! It doesn't honor any conspiracy. Everyone is allowed to make builds and publish them. This key exists only because Android mandates it. It's neither meant to be used for some private authentication, nor serves for enforcing some limitations on the end user. These are reasons why key password is stored open in the SVN tree. It's possible to adjust the build system to use arbitrary system-specific key and password, but this is not done for simplicity.
Configure parameters for building android-hosted port (softfp)
hardfp
In the future can build pelya's SDL-lib based android-port of AROS with audio, internet and additional control for show/hide android keyboard and customisation for right mouse click
part of code causes an error and must be removed from sources for successful compilation
AROS-20150908-source/arch/all-linux/kernel/cpu_arm.h:41:8: error: redefinition of ‘struct ucontext’
Dopus5 works fine via windows-hosted AROS ABIv0. Problem only with Android-hosted AROS
ABIv1 broken for android. It requested for x11 and glx on build.

## Reference

Android is a very hostile environment to native code. All Android applications are running inside a Java VM. It uses UNIX signals for own purposes, conflicting with AROS multitasking. This makes it impossible to run AROS directly in application's context. It was proved during early port development. There's no way to shut down Java environment.
In order to work around this limitation, AROS runs in its own process asynchronously. Communication with Android OS is implemented using client-server architecture. Before running AROS via fork, bootstrap creates two pipes (see Kick method implementation). These pipes are used as communication channels to and from display server, written in Java. AROS display driver sends action commands to the server, and gets input events from it. This is the only way for AROS to communicate with Android APIs other than Linux kernel and C libraries on top of it. It's unknown whether it's possible to call Android GL API from within AROS under these conditions.
Because of this, please, keep communication with Java at a minimum. In order to prevent from de-synchronization all commands are processed by display server in the same order as in which they arrived. In order to satisty this, Java display server thread forwards all commands to main user interface thread, where they are processed and replied. Such an architecture very negatively impacts on the overall AROS performance, especially when a command needs a reply, and it's a good practice to stay away from it. It's impossible to remove a separate display server thread because Java API lacks asynchronous I/O facilities which could be used together with Android user interface processing.
Fortunately Android's lower layers (kernel and C libraries) do not suffer from any limitations, and at least basic system services (file access, time, signals, etc) can be freely used by AROS. If someone wants to try his hands on, for example, accelerometer support for AROS, the primary way to go would be direct interfacing with the device using /dev directory.
If you work with code using communication pipes, remember the general rule: pipe error on any side should cause immediate process exit. The pipe can be broken if one of processes exit. In this case, if the user interface exits, and AROS fails to notice this, you'll end up in blindly running AROS process without any control on it. It's impossible to even use kill command on non-rooted device, so the only way to get rid of such process (draining the battery and system resources) is to completely reboot the device. Please do everything possible to avoid this!
An alternate way to run hosted AROS on Android device would be total shutdown of Java environment and taking over the device. AROS would need a Linux framebuffer display and raw hardware input drivers. There is very old source code of these drivers which is slowly being reworked. The only drawback of such approach is that cellular phone will stop being serviced. AROS would need to take care of it itself then. Additionally, it would require a rooted device.

## Errors

Add the following to AROSBootstrap.conf file:
logfile AROS.log arguments sysdebug=all
then run. After a reboot you should get AROS.log file in your AROS directory.
Install ALogcat program to your machines, run it, then run AROS. When it all stops, ALogcat should display some log. Mail me that log. BTW, I need exact error messages, "something like that" simply won't help me.
Improved software faulire requester. First, now it correctly displays buttons on small screens. Second, after you press 'More', there'll be 'Log' button. Press it and the whole crashlog will be dumped to debug output.
For Java part AROS build system creates a complete Eclipse project. It's located in $(TOP)/bin/linux-$(CPU)-android/gen/arch/all-android/bootstrap/app. You can import it into Eclipse workspace and work with it as usually. On UNIX systems the project will contain symlinks to original directories, so files modified in Eclipse will stay in their original place. Unfortunately on Windows this is not possible, and directories will be copied instead (unless MinGW implements support for post-XP symlinks). So, if you modify something there, you'll have to copy your changes back to SVN tree. Theoretically it's possible to work around it by modifying Java build paths inside the project.
Debug output from AROS itself is copied to Android debug buffer. You can read it as usually, using 'logcat' command in Android shell. Also you can use 'logfile' option in AROSBootstrap.conf in order to save the output to a file, the same as in any other hosted port.
Androd NDK documentation describes a way to attach gdb to a process on the device. This was not tested with AROS, however is expected to work.
AROS is expected to run inside Android emulator, since it's full ARM machine emulator, not a hosted environment like for example iOS or Symbian simulators. Not tested because of: a) complicated process of SD card image creation; and b) overall slowness of the emulator even on very fast computers. It was much faster and easier to use the real hardware for the development.

### Run Logs

AROS-20120905-android-arm-system.tar.bz2 on my Galaxy S3 but I get program failed.
I tried to use the logfile-argument on the bootstrap.conf aswell and that says:
Is this a bad version or just incompatible with my new phone ? =)
This phone is running Android 4.0.4 if that matters (not rooted)
Android does not need to be rooted. When I last checked this version, it worked. But now I can't maintain this port because I have no devices capable of running Android.
From the log it looks like there's some problem in communication of AROS display driver with Android part. You may have an older version installed and did not update the bootstrap? Actually bootstrap and display driver (which is in the BSP) versions should match. If they differ, various things can happen.
Not only the bootstrap, but also a display server written in Java. And if I change something significant in the display driver, I need to update the server too.
Please used a OTG-cable and take the files from a USB-stick =)
Copying the archive content causes error messages because there are symlinks in the archive and FAT doesn't support them. Example: AROS/Development/lib/libm.a is a symlink to libarosm.a P.S. About these symlinks: simply ignore them, this is actually SDK, you don't need it just ro run AROS.
Would ZIP be a more appropriate format for this package? Using ZIP might get rid of the symlinks. ZIP will irreversibly clobber UTF8 file names of some locales
and here the other log from Alogcat