There are two major players in the mobile world: Apple (iOS) and Google (Android).

Android is today the most used mobile OS in the world.

Nearly 70% of users in Western countries use this platform. In Africa or Asia, Apple’s pricing policy means that Android market shares are even stronger and continue to climb.

Doing mobile programming still has an interest. Access to IT (web or other) is increasingly done with mobiles and tablets.

Android has become the most used OS worldwide for all systems combined.

Mobility has transformed the devices we used. When you are on a desktop PC or a laptop you always have approximately the same components: CPU, graphics card, hard drive, photo card reader, input/output ports.

On a mobile you will have more components to help you in this context of mobility: GPS, camera, accelometer, pedometer…​ We have more and more sensors to interpret the context of use of the device

The price of a device depends on the number and quality of all these sensors. Today Android is present everywhere

And you have different versions of Android. One for each platform

Android was built on a Linux kernel. But Android is not completely Open Source. Only a little part is free of rights.

Android draws on the strengths of Linux to provide a stable and reliable OS: memory management, process management, security, etc.

And thanks to Android, Linux is the most used OS in the world :-)

Android offers a virtual machine to execute bytecode. This is not a classic JVM. Google engineers tried to work on bytecode with a smaller memory footprint.

In Android the compiler will create .dex files (Dalvik executable). Dalvik was the first compiler used on the platform. Like current JVMs, Dalvik transformed bytecode into machine language at runtime: Just In Time (JIT) compilation.

Today this virtual machine has been replaced by ART (Android Runtime). The transformation into machine language is done when the application is installed: AOT (ahead of time) compilation. As the bytecode is compiled into machine language earlier, applications launch faster and the CPU is less required during execution (and therefore preserves your battery).

I deliberately misused language by indicating that the bytecode was transformed into machine language. This is not really the case. If we really had machine language we would no longer need a VM.

In fact during installation the bytecode is transformed into an intermediate format: .oat files (ahead of time). The VM is necessary because it will manage memory allocations and freeing up space with the Garbage collector. Even if compilation is no longer Just In Time, optimizations are still made at runtime so that the code executes as quickly as possible.

You can find more information in the documentation.

In 2017 a big announcement was made at Google IO. The Kotlin language became the second reference language for developing applications. 2 years later 50% of developers use Kotlin and Google announced at Google I/O 2019 that the platform was becoming Kotlin-first. They recommend starting new developments in Kotlin.

Developing today on Android with the Java language is very painful, because you have a lot of tedious code to write.

Initially the recommended development studio was Eclipse but the more features were enriched, the longer the IDE took and became unusable. Google therefore worked in partnership with JetBrains (publisher of Webstorm, IntelliJ, Kotlin) to adapt their Open Source version and create Android Studio .

You will find inside this IDE all the functionalities necessary for development. You have utilities for

As Android is based on a Linux kernel, the platform benefits from security implemented at the kernel level.

When an application is installed, Android assigns it an user ID. Each application is launched in a separate process and uses its own ART virtual machine. Execution rights are specific to this application user. The application has no idea of ​​this ID. So an application cannot access the data of another application because everything is closed by this device. The same goes for native apps.

Each application is therefore isolated from the others and has its own CPU, memory, etc. resources.

On top of this "low level" security, Android has added a more "high level" level of security over time. Each external action that can be requested by your application must be declared in a manifest file. For example

A user can choose to leave the requested rights to the installation, but he can also choose to remove certain rights. Personally I limit the number of applications that can connect to the network, can use my contacts, my files, etc.

For several years, Google has released a new version of Android per year. Typically developers can start testing and providing feedback in the second and third quarters and the release is made available in the last quarter of a calendar year.

Each new version is associated with a letter (which increments with each version) and a dessert (chosen by the Android team). The dessert is often a french dessert. Since the beginning, the Android team has included several French people.

When you start a new development you must make a version choice. In fact you have to make two choices

Version usage statistics are published regularly on this dashboard, which compiles the data reported by Google Store (the official source of Android applications).

In the web world, you can use polyfills to use the latest features of the language in browsers that do not yet implement these features. In the Android world, Google also suggests using specific objects that manage this backward compatibility. The base class for developing a screen is android.app.Activity, but in practice we will always use androidx.appcompat.app.AppCompatActivity, which was developed to port the latest news to old Android releases. This is the same thing for all main objects.

After versions, the biggest difference between devices concerns screen quality and size.

As a reminder

Android offers a classification linked to the width of a screen.

As in the web world, you must adapt your UI either by using components and resizable layouts, or by using different layouts depending on the size (in Android you can use fragments)

Pixel density is the number of dots per inch (dot per inch ⇒ dpi). Density is important on a device. For example, if you display an image expressed in pixels on 2 screens of different density, you will not have the same rendering.

If we display the same images expressed with the dp unit (density-independent pixels) you will have the following result

The rule is to never express sizes in px in an application but always in dp (in the web world we will use the em unit). To express the size of the fonts, you will instead use the unit sp (scalable pixels) which has the advantage of increasing depending on the user accessibility settings.

You will be able to create different resources depending on the size. When you have a nice screen with good resolution and high density, you will expect quality images. These same images have no interest on screens that are not capable of displaying them.

We have focused on the 2 biggest differences between devices but we could go further because you also have a big difference in quality and performance in terms of the basic components of a mobile or tablet. You do not have the same components in entry-level devices and more luxurious ones

To provide a good user experience, you can apply a few simple rules

As your users can and most have limited resources try to