Lab on Android

The purpose of this lab session is to enter into some internal features of the Android system. You can use the preinstalled Docker container on a Eurecom computer, or prepare one of the alternative environments below. This session is not graded, and so, you don't have to send me a report or source file, but you may do it if you wish.

If you know nothing about Android, don't panic! The lab is guided, and you will almost have no code to do in this lab: most of the time, you will just have to understand elements of Android by executing commands I provide. Sometimes, you will have to find commands in a documentation which link is provided. Thus, using Google in this lab shall not be necessary ;-)

Preparing for the lab: choose your setup

Choose one of the four options below, then follow its procedure from installation (if needed) to a running Android emulator.

1. Docker on a Eurecom computer: the recommended starting point at Eurecom; the container is already installed.
2. Android emulator on a Eurecom desktop: use this only if option 1 has failed, including the VNC alternative.
3. Docker on your personal computer: install the lab container yourself. Not supported on Apple Silicon Macs (M-series).
4. Android emulator on your personal computer: install it directly; use this option on Apple Silicon.

Why will you need to transfer files? Some later exercises use files that you download or create: an APK to unpack and modify in Reversing an Android application package (apk), or a compiled program to run in Native code execution in Android. The analysis and compilation tools need these files in their working directory; Android needs the app or program when you test it. With Docker, the computer, the container and the Android emulator have separate file systems. With a direct emulator, only the computer and Android are involved. Each option below explains the transfers you may need. Keep these instructions for the relevant exercises; no files need to be copied during initial setup.

Select your option to display its complete procedure. Commands in the selected procedure must be run in the terminal indicated above each block.

Option 1: use Docker on a Eurecom computer

Try this option first at Eurecom. Docker and the lab container are already installed; do not pull a new image or create another container.

Open a terminal on your assigned Eurecom Linux computer. If you are logged into its Linux desktop, open a terminal there.

From a Eurecom Windows session, start XLaunch, select Multiple windows, then start the xterm program using PuTTY. Enter your Eurecom credentials and the Linux computer assigned by your teacher (eurecom1 to eurecom44), then finish the wizard. Use the resulting remote Linux terminal for the commands below. Only one student should use each assigned Linux computer. Here, localhost refers to that Linux computer.
Connect to the container from the Eurecom Linux terminal (password: mypass):
```
ssh -X -p 5022 root@localhost
```
VNC alternative: if SSH fails or the emulator cannot open its graphical window through SSH, run one of these commands in a terminal on the Eurecom Linux computer:
```
vncviewer 127.0.0.1
```
Or, if that viewer is unavailable:
```
gvncviewer 127.0.0.1
```
In the VNC desktop, open a terminal. This terminal is inside the container.
Start Android in the container terminal:
```
emulator
```
Keep this terminal open and wait for Android to boot. If Android is already running, do not start a second instance.
Check that Android is ready. Open a second terminal inside the container (another SSH connection or another terminal in the VNC desktop), then run:
```
adb devices
adb shell getprop sys.boot_completed
```
The emulator must appear with status device, and the second command must return 1. If it says offline or the boot property is empty, wait and retry. Keep this second terminal for the lab's adb commands.

Files for later exercises: computer, container and Android

In this option, the APK analysis and compilation tools run inside the container, and Android runs in an emulator inside that container. A file downloaded on your Eurecom Linux computer must first reach the container so those tools can use it. When an exercise asks you to test an app or run a program in Android, use ADB for the second transfer. Use the following instructions when the exercise needs a file.

1. Copy a file from the computer into the container. For example, in Reversing an Android application package (apk), the Getting an Android app step downloads the Root Verifier APK. If downloading inside the container fails, download it on your Eurecom Linux computer instead. First create the exercise directory from a terminal inside the container:

mkdir -p /root/myapp

Then, from a terminal on the Eurecom Linux computer, in the directory containing the downloaded APK, run:

scp -P 5022 com.abcdjdj.rootverifier_12.apk root@localhost:/root/myapp/

Use password mypass. The APK is now in /root/myapp/ inside the container, ready for Unpack the app. For another file, replace the source filename and destination directory with those required by its exercise. Files downloaded or created directly inside the container are already available there.

2. Send a program or data file from the container into Android. For example, after compiling hello in Native code execution in Android, run this from a terminal inside the container, in the directory containing hello:

adb push ./hello /data/local/tmp/hello

The file is now in Android at /data/local/tmp/hello. Use the same command with the appropriate filename to copy other files. Run adb from the container terminal; if you are in adb shell, type exit first.

3. Install an APK in Android. When the APK exercise reaches Testing the app in the emulator, run this from a terminal inside the container, in the directory containing your signed APK:

adb install myfirstapp-signed.apk

adb install installs the application so you can launch it in Android. Copying an APK with scp or adb push only copies the file; it does not install the app.

Ready: continue at Lab starts here. If the container or emulator still fails after trying VNC, ask your teacher for help, then select option 2.

Option 2: install the emulator on a Eurecom desktop

Fallback only: use this procedure only if option 1 has failed, including its VNC alternative. All commands below run in a terminal on the Eurecom Linux desktop, outside Docker.

Check the prerequisites. You need Java (JDK 17 or later for these command-line tools), wget, unzip, and several GB of free disk space. If a tool is missing or Java is too old, ask your teacher to help select an installed JDK.
```
java -version
command -v wget unzip
df -h /home/Local_Data
```

Create a personal installation directory on the local disk. Run the installation steps once; if you already completed them, go to step 5.

mkdir -p "/home/Local_Data/$USER/android-lab"
cd "/home/Local_Data/$USER/android-lab"
export ANDROID_HOME="$PWD/Android/Sdk"
export ANDROID_SDK_ROOT="$ANDROID_HOME"
export ANDROID_AVD_HOME="$PWD/avd"
mkdir -p "$ANDROID_HOME/cmdline-tools" "$ANDROID_AVD_HOME"
wget -c https://dl.google.com/android/repository/commandlinetools-linux-13114758_latest.zip
unzip commandlinetools-linux-13114758_latest.zip -d "$ANDROID_HOME/cmdline-tools"
mv "$ANDROID_HOME/cmdline-tools/cmdline-tools" "$ANDROID_HOME/cmdline-tools/latest"
export PATH="$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools:$ANDROID_HOME/emulator:$PATH"

Install the SDK components and an Android 15 (API 35) x86_64 AOSP image. Read and accept the SDK licences when prompted. AOSP images support the root access needed for some exercises.
```
sdkmanager --sdk_root="$ANDROID_HOME" --licenses
sdkmanager --sdk_root="$ANDROID_HOME" "platform-tools" "emulator" "system-images;android-35;default;x86_64"
```

Create the virtual phone named myemu:

echo no | avdmanager create avd -n myemu -k "system-images;android-35;default;x86_64"

Start the emulator. Run the exports below in each new terminal, including when returning to the lab later on the same desktop. They point to the installation created above.

export ANDROID_HOME="/home/Local_Data/$USER/android-lab/Android/Sdk"
export ANDROID_SDK_ROOT="$ANDROID_HOME"
export ANDROID_AVD_HOME="/home/Local_Data/$USER/android-lab/avd"
export PATH="$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/platform-tools:$ANDROID_HOME/emulator:$PATH"
adb start-server
emulator -avd myemu -accel off -gpu swiftshader -no-snapshot -no-boot-anim

On Eurecom desktops, hardware acceleration is disabled with -accel off. Startup can therefore be slow. Keep this terminal open.

Check that Android is ready. Open a second Linux terminal, repeat the four export commands from step 5, then run:
```
adb devices
adb shell getprop sys.boot_completed
```
Wait until the emulator has status device and the boot property returns 1. For exercises requiring root, run these commands from this Linux terminal:
```
adb root
adb wait-for-device
adb shell id
```
The last command should show uid=0(root). Keep this terminal for the lab; no SSH or VNC connection is needed.

Files for later exercises: computer and Android

In this option, the APK analysis and compilation tools run on your Eurecom Linux desktop. Download or create exercise files in a working directory on that computer. For example, keep the Root Verifier APK in your myapp directory for Reversing an Android application package (apk). There is no container to copy files into. The Android emulator has its own file system: use ADB when an exercise asks you to put a file or install an app in Android. Use these instructions when you reach those exercises.

Copy a program or data file into Android. For example, after compiling hello in Native code execution in Android, open a Linux terminal on your Eurecom Linux desktop. With ADB configured as above, change to the directory containing hello and run:

adb push ./hello /data/local/tmp/hello

The file is now in Android at /data/local/tmp/hello. For other files, replace the source filename and destination path as needed. Run this command from your computer's terminal; if you are in adb shell, type exit first.

Install an APK in Android. When the APK exercise reaches Testing the app in the emulator, run this from your computer's terminal, in the directory containing your signed APK:

adb install myfirstapp-signed.apk

adb install installs the application so you can launch it in Android. Copying an APK with adb push only copies the file; it does not install the app.

Ready: continue at Lab starts here. In the lab, [Shell in container] means your Eurecom Linux terminal for this option.

Option 3: install Docker on your personal computer

For Intel/AMD x86_64 computers only. This lab container is not supported on Apple Silicon Macs (M1, M2, M3, etc.); select option 4 on those Macs.

Install and start Docker using the official instructions for your operating system. On Windows, use Docker Desktop with Linux containers; on an Intel Mac, use the Intel version of Docker Desktop. On Linux, install Docker Engine and complete its post-installation steps, then reopen your terminal if group membership changed.

In a terminal on your personal computer (PowerShell on Windows, Terminal on macOS, or a Linux terminal), check that both the Docker client and server respond:
```
docker version
```
Download the lab image and create the container from that same host terminal. Do this once:
```
docker pull cryptax/android-emu:2026.11
docker run --privileged -d -p 127.0.0.1:5022:22 -p 127.0.0.1:5900:5900 --name android-docker cryptax/android-emu:2026.11
```
On later visits, start the existing container instead of creating it again:
```
docker start android-docker
```
Check its state:
```
docker ps -a --filter name=android-docker
```
It should be running (Up). If it exits, inspect docker logs android-docker. To restart it, use docker restart android-docker; this also stops any running emulator, which you will need to start again. Do not remove the container to fix a connection problem: removing it deletes work stored inside.
Connect to the container's desktop with a VNC viewer installed on your personal computer. Connect to host 127.0.0.1, port 5900 (display :0). On Linux, for example:
```
vncviewer 127.0.0.1
```
Open a terminal in the VNC desktop. Alternatively, if your computer has an X server with X11 forwarding configured, connect from the host terminal using SSH (password: mypass):
```
ssh -X -p 5022 root@localhost
```
If SSH or the graphical display fails, use VNC. On Windows and macOS, VNC avoids the need to configure a separate X server.
Start Android in the container terminal:
```
emulator
```
Keep this terminal open and wait for Android to boot. If the emulator is already running, do not launch another instance.
Check that Android is ready. Open another terminal in the VNC desktop, or make a second SSH connection to the container, then run:
```
adb devices
adb shell getprop sys.boot_completed
```
Wait until the emulator has status device and the boot property returns 1. Run the lab's adb commands in this container terminal. If Docker runs inside a virtual machine, emulator acceleration may be unavailable and startup may be slow; if it cannot start, use option 4.

Files for later exercises: computer, container and Android

In this option, the APK analysis and compilation tools run inside the container, and Android runs in an emulator inside that container. A file downloaded on your personal computer must first reach the container so those tools can use it. When an exercise asks you to test an app or run a program in Android, use ADB for the second transfer. Use the following instructions when the exercise needs a file.

1. Copy a file from the computer into the container. For example, in Reversing an Android application package (apk), the Getting an Android app step downloads the Root Verifier APK. If downloading inside the container fails, download it on your personal computer instead. First create the exercise directory from a terminal inside the container:

mkdir -p /root/myapp

Then, from a terminal on the personal computer, in the directory containing the downloaded APK, run:

scp -P 5022 com.abcdjdj.rootverifier_12.apk root@localhost:/root/myapp/

adb push ./hello /data/local/tmp/hello

3. Install an APK in Android. When the APK exercise reaches Testing the app in the emulator, run this from a terminal inside the container, in the directory containing your signed APK:

adb install myfirstapp-signed.apk

adb install installs the application so you can launch it in Android. Copying an APK with scp or adb push only copies the file; it does not install the app.

To save your APK exercise work from the container onto your personal computer before deleting or replacing the container, run this from a host terminal:

docker cp android-docker:/root/myapp ./myapp-backup

Ready: continue at Lab starts here.

Option 4: install the emulator on your personal computer

This option runs Android directly on your computer. Use it on Apple Silicon Macs. All terminal commands run on your personal computer, outside Docker.

Install Android Studio following the instructions for your operating system. On macOS, choose the download matching your processor (Apple Silicon or Intel). Complete the setup wizard.
Install the SDK tools. From the welcome screen, open More Actions > SDK Manager (or open SDK Manager from an existing project). Note the Android SDK Location. In SDK Tools, select Android SDK Platform-Tools, Android Emulator, Android SDK Command-line Tools and Android SDK Build-Tools, then apply the changes and accept the licences.
Create a virtual phone. Open More Actions > Virtual Device Manager from the welcome screen, or View > Tool Windows > Device Manager from a project. Choose Create Virtual Device, select a phone profile, and download an Android 15 (API 35) AOSP system image. Show the other available images if necessary.
- Intel/AMD computer: choose an x86_64 image.
- Apple Silicon: choose an arm64-v8a image.
Choose an AOSP image without Google apps/services. Avoid Google Play images: they do not allow adb root, which some lab exercises require. Name the virtual device myemu, then finish. See the official virtual-device guide for the image choices.
Start Android with the play button next to myemu in Device Manager. Wait for the Android screen to appear. Leave the emulator running.

If it cannot start, check the hardware acceleration instructions for your OS (KVM on Linux, Windows Hypervisor Platform on Windows, Hypervisor.Framework on macOS). If the problem concerns graphics, edit the AVD and choose software graphics.

Make ADB available in your terminal. Use the SDK location noted in step 2 if it differs from these defaults. Repeat the commands for your OS in each new terminal.

Linux (Bash):

export ANDROID_HOME="$HOME/Android/Sdk"
export PATH="$ANDROID_HOME/platform-tools:$ANDROID_HOME/emulator:$PATH"

macOS (Terminal):

export ANDROID_HOME="$HOME/Library/Android/sdk"
export PATH="$ANDROID_HOME/platform-tools:$ANDROID_HOME/emulator:$PATH"

Windows (PowerShell):

$env:ANDROID_HOME = "$env:LOCALAPPDATA\Android\Sdk"
$env:Path = "$env:ANDROID_HOME\platform-tools;$env:ANDROID_HOME\emulator;$env:Path"

Check that Android is ready from that host terminal:
```
adb start-server
adb devices
adb shell getprop sys.boot_completed
```
Wait until the emulator has status device and the boot property returns 1. Check root access for the exercises that need it:
```
adb root
adb wait-for-device
adb shell id
```
The last command should show uid=0(root). If ADB says it cannot run as root in production builds, create an AOSP AVD instead of a Google Play AVD. No SSH or VNC connection is needed.

Files for later exercises: computer and Android

In this option, the APK analysis and compilation tools run on your personal computer. Download or create exercise files in a working directory on that computer. For example, keep the Root Verifier APK in your myapp directory for Reversing an Android application package (apk). There is no container to copy files into. The Android emulator has its own file system: use ADB when an exercise asks you to put a file or install an app in Android. Use these instructions when you reach those exercises.

Copy a program or data file into Android. For example, after compiling hello in Native code execution in Android, open a terminal (PowerShell on Windows, Terminal on macOS, or a Linux terminal) on your personal computer. With ADB configured as above, change to the directory containing hello and run:

adb push ./hello /data/local/tmp/hello

Install an APK in Android. When the APK exercise reaches Testing the app in the emulator, run this from your computer's terminal, in the directory containing your signed APK:

adb install myfirstapp-signed.apk

adb install installs the application so you can launch it in Android. Copying an APK with adb push only copies the file; it does not install the app.

Ready: continue at Lab starts here. For this option, [Shell in container] means a terminal on your personal computer. On later visits, start myemu in Device Manager and repeat steps 5 and 6.

Optional investigations for Docker users (options 1 and 3)

Once Android is running, find the kernel version and memory information in the container and compare them with the host. How do you explain the results? What is the difference between a container and a virtual machine?

Also find which command is really executed when you type emulator in the container.

Lab starts here

Before continuing, complete your selected setup: adb devices must show an emulator with status device, and adb shell getprop sys.boot_completed must return 1.

Where to run commands throughout the lab:

[Shell in container]: a Linux terminal inside Docker for options 1 and 3; a terminal on the Eurecom desktop or your personal computer for options 2 and 4. Run adb commands here.
[adb shell]: the shell inside Android, entered with adb shell. Type exit to return to the terminal that runs ADB.

With options 2 and 4, the later APK and compilation exercises also require their host tools (Java, apktool, smali and the NDK). Install them on your host as those exercises describe, using writable directories and the downloads for your OS; replace container-specific /opt/... paths with your local tool paths. Android versions may produce different output. On Apple Silicon, native programs must target arm64-v8a; the lab's x86 compilation commands require adaptation.

First investigations on Android

Shell on the phone. At first, we will not use the graphical emulator, but we will simply connect with adb to the emulator. ADB stands for "Android Debug Bridge". It is a facility to connect with a Command Line Interface to an Android system.

[Shell in container]$ adb shell

[adb shell]$ su

With the direct AOSP emulator (options 2 and 4), use adb root from your host terminal instead. If you are already in adb shell, type exit first, then run adb root, adb wait-for-device, and adb shell. Check id: uid=0(root) means you already have root access.

My first adb shell commands. Most adb shell commands are explained here. You are asked to:

List the current users of the system. Also, find out the maximum number of users for Android?

Find to a way to verify that the emulator supports the bluetooth feature.

What are the kernel debug messages? Are there any specific adb command to see the Android logs? Are there any error messages regarding the battery? Can you explain these errors?

Gathering more information on the system with dumpsys. First, list the services that can be investigated with dumpsys:

[adb shell]$ dumpsys -l

The load of the CPU can be monitored with dumpsys as follows:

[adb shell]$ dumpsys cpuinfo

Find how to get the battery characteristics with dumpsys. Explain what you observe.

Then, find a way to investigate the two following elements:

Time before the screen goes to off ("off timeout")

Widgets currently installed in the system (i.e. visible on the display), and the ones that could be installed on the screen.

A closer look at the GNU/Linux kernel of Android

Start scripts of Android. A few starting scripts executed when the system starts are located in /. The main one is called init. Basically, this script sets up I/O (e.g., USB, sor debug wwia adb), and sets the security features of SELinux, to ensure security elements are set asap when booting. It also calls other starting scripts.
Tracing script. One script which is called is init.environ.rc. Look at its content, and determine its role.

Tracing capabilities. Google provides a facility named atrace to monitor elements of the operating system. First, let us list the tracing capabilities of atrace:

[adb shell]$ atrace --list_categories

Analyzing events of the window manager. Activate the tracing for the window manager for 10 seconds. When the tracing is started, graphically log into the Android emulator by making a slide up from the lock with your mouse. Then, wait for the tracing to complete, and understand the trace. To do this, you will probably have to consult the manual of as follows:

[adb shell]$ atrace --help

Tracing interrupts. Trace the interrupt during 5 seconds while doing nothing in the (graphical) emulator. What is the most frequent interrupt? Redo the same but unlock the emulator screen while tracing, and click on an icon. Observe the difference i.e. find at least one interrupt that is part of the tracing only when an icon was clicked.

Monitoring actions. Similarly, find a tracing categorie that is empty when doing nothing in the (graphical) emulator, and that shows actions when cliking on a icon.

Using the emulator and the shell

Graphically log into the Android emulator. Then, come back to the shell, and type:

[adb shell]$ ps

Start the Chrome browser. Do ps again, and find the difference:

[adb shell]$ ps -A

Now, click on the "home" button (i.e. the "circle" icon) in the graphical interface on the right part of the emulator. The browser should disappear. Evaluate if the process is terminated e.g. by listing again the processes:

[adb shell]$ ps

[Shell in container] adb shell input keyevent 3

[Shell in container] adb shell input keyevent 4

Find an adb shell command to terminate the browser process. Before executing the terminaison action, open another "adb shell" and starts the monitoring of the kernel with logcat. Then, terminate the browser process with a command in the first shell, and then verify that the browser is really terminated.

Reversing an Android application package (apk)

Getting an Android app. From a shell in the docker machine (and not in the emulator), get the "root verifier" Android app to analyze as follows. The app is downloaded from the "F-Droid" market place.

[Shell in container]$ cd ~
[Shell in container]$ mkdir myapp
[Shell in container]$ cd  myapp
[Shell in container]$ wget https://f-droid.org/repo/com.abcdjdj.rootverifier_12.apk

Unpack the app

apktool

[Shell in container]$ wget https://bitbucket.org/iBotPeaches/apktool/downloads/apktool_2.6.0.jar
[Shell in container]$ mkdir /opt/apktool
[Shell in container]$ mv apktool_2.6.0.jar /opt/apktool/apktool.jar

[Shell in container]$ java -jar /opt/apktool/apktool.jar d com.abcdjdj.rootverifier_12.apk

com.abcdjdj.rootverifier_12.apk

The manifest of the application, including its certificate, and the main information
The resources. You should identify here the description of the graphical interface, as well as images used by the app
The assembly code of the app, in smali format (byte code). One file corresponds to the Main activity. Open this file, and add your email among the developer emails (you are now indeed part of the developers!) in the about section.

Creating a new Android app with your modifications. To do so, we now create a new valid apk package. We will use another directory in which we will put the new source code, and from which we will create the new apk. For this, you will also need the smali application, that you can find here: https://bitbucket.org/JesusFreke/smali/downloads/smali-2.5.2.jar. Install it in /opt.

[Shell in container]$ cd ~/myapp/
[Shell in container]$ mkdir myfirstapp

[Shell in container]$ unzip -d myfirstapp com.abcdjdj.rootverifier_12.apk

[Shell in container]$ cd myfirstapp
[Shell in container]$ mkdir smali
[Shell in container]$ java -jar /opt/smali.jar a ./smali/
[Shell in container]$ cp out.dex ../myfirstapp/classes.dex

out.dex

classes.dex

Generating a new apk.

[Shell in container]$ cd ../myfirstapp/
[Shell in container]$ rm -rf META-INF/
[Shell in container]$ zip -r myfirstapp.apk *

[Shell in container]$ unzip -l myfirstapp.apk

Optimizing the apk. This is also called "alignment".

    $ [Shell in container] /opt/android-sdk/build-tools/31.0.0/zipalign -v -p 4
    myfirstapp.apk myfirstapp-aligned.apk

Signing the application. What happens if you try and install this application on an emulator or a smartphone? Android will complain with INSTALL_PARSE_FAILED_NO_CERTIFICATES. That is because the app is not signed yet. We now need to sign the new package. We first delete the former package signature, and we create the apk:

  [Shell in container]$ keytool -genkeypair -keyalg RSA -keystore mykey.jks -keysize 2048 -validity
  10000 -alias test

mykey.ks

  [Shell in container]$ /opt/android-sdk/build-tools/31.0.0/apksigner sign --ks mykey.jks
  --in myfirstapp-aligned.apk --out myfirstapp-signed.apk --min-sdk-version 25

Testing the app in the emulator. We can now install the new app in the emulator:

[Shell in container]$ adb install myfirstapp-signed.apk

Testing the modification. Use the graphical emulator to log into the emulator, find the app, start it, and try to find the impact of your modification...

Getting system information from an Android application

Now, you will be less guided.

Get the sources of the app "AnotherMonitor" from FDroid.

Find in the source code how the application gets the memory and processor informations. Once you've found this, test with "adb shell" if the way the application gathers information on memory and cpu is likely to work.

Test the app from its apk (available on FDroid) in the emulator to verify if the app works.

Emulation of other system information

Get the sources of the app "CpuSpy" from https://github.com/bvalosek/cpuspy. Try to basically understand the code. This (short) doc could help you understand the code.

Where is the frequency value handled in the graphical interface? What happens if the considered core is in idle mode?

How is the kernel version found in the application? Can you do this "by hand" in adb shell to test if their way of doing works?

Where are the states of the processor stored in the android file system? Does this file exist in the emulator? So, do you think the application can work in the emulator?

Test the app in the emulator ... you could also test on your own (Android) device to see what happens... What can you conclude on the emulator?

(bonus work) Native code execution in Android (new way of doing)

At first, identify the processor architecture and Android API level of your emulator:
```
[Shell in container]$ adb shell getprop ro.product.cpu.abi
[Shell in container]$ adb shell getprop ro.build.version.sdk
    
```
The architecture should typically be x86_64, and the API level corresponds to the Android version running in the emulator.

Install the Android Native Development Kit (NDK) in the Docker container. The NDK provides a cross-compiler for building native Android executables.

Download and extract the NDK:

[Shell in container]$ cd /opt
[Shell in container]$ wget -c https://dl.google.com/android/repository/android-ndk-r30-linux.zip
[Shell in container]$ unzip android-ndk-r30-linux.zip

Configure the cross-compilation environment:

[Shell in container]$ export TOOLCHAIN=/opt/android-ndk-r30/toolchains/llvm/prebuilt/linux-x86_64/bin

The NDK includes the LLVM/Clang cross-compiler.

Create a file named hello.c in your home directory, containing the following C program:

#include <stdio.h>

int main(void) {
    printf("Hello world\n");
    return 0;
}

Cross-compile hello.c for Android.

First, retrieve the architecture and API level of the emulator:

[Shell in container]$ ABI=$(adb shell getprop ro.product.cpu.abi | tr -d '\r')
[Shell in container]$ API=$(adb shell getprop ro.build.version.sdk | tr -d '\r')

Select the compilation target:

[Shell in container]$ case "$ABI" in
  x86_64) TARGET=x86_64-linux-android ;;
  x86)    TARGET=i686-linux-android ;;
  *)      echo "Unsupported ABI: $ABI" ;;
esac

Compile the program:

[Shell in container]$ cd ~
[Shell in container]$ "$TOOLCHAIN/clang" --target="${TARGET}${API}" -fPIE -pie -o hello hello.c

The resulting hello executable is compiled for Android, not for the Linux system running in Docker. The compiler uses Android's Bionic C library instead of the GNU/Linux C library.

Execute the native program on Android.
First, transfer it to the emulator:
```
[Shell in container]$ adb push hello /data/local/tmp/hello
    
```
Make it executable and run it:
```
[Shell in container]$ adb shell chmod 755 /data/local/tmp/hello
[Shell in container]$ adb shell /data/local/tmp/hello
    
```
You should obtain:
```
Hello world
    
```
Note that the executable runs directly on Android, without requiring an APK or the Android application framework.

Enhance the code: the C program should now gather information about memory and processor usage, and print updated values every second in the terminal.
Hint: investigate the Linux pseudo-files /proc/meminfo and /proc/stat. You can use sleep(1) to wait between two measurements.
Cross-compile your modified program, transfer it to the Android emulator, and execute it again.

Thats'all folks!