Développer pour AndroidI – Le systeme d’exploitation

Android c’est quoi ?• OS / open source / noyau linux / Licence Apache

• MID (Mobile Internet Device), tablette, portable …

• Notebook, minipc, ultraportable, desktop phone …

• TV, voitures, réveil …

Concurrence

• IOS (iphone, ipad)

• Symbian OS (Nokia)

• Window Mobile (Microsoft)

• Web OS (Palm)

• BlackBerry OS (RIM)

• Bada (Samsung)

Historique

Versions• Android 1.0, 1.1, 1.5 (cupcake)

• 1.6 (donut)

• 2.0 (éclair), 2.1 (éclair)

• 2.2 (froyo/frozen yoghourt)

• 2.3 (gingerbread)

• 3.0 (honeycomb)

• 4.0 (ice cream sandwich)

• 4.1 (jelly bean), 4.2 et 4.3 (jelly bean)

• 4.4 (kitkat)

Points forts• Constructeurs :

• Linux Open Source • Coût de licence nul

• Adaptabilité (Motorola Motoblur, HTC HTC Sense , Sony Ericsson

Xpéria X10)

• Développeurs : • Langage Java• Modularité, partage• Kit de développement gratuit• SDK complet• Android Market

• Utilisateurs :• Fonctionnel, intuitif et évolutif• Multitâches• Applications nouvelles• Nombreuses applications par défaut

Parts

du marché

Structure Android

• Noyau Linux (et des pilotes)

• Bibliothèques logicielles (SSL, SQLite, OpenGL ES, etc...)

• Machine virtuelle: Dalvik Virtual Machine et des bibliothèques

• Applications (navigateur, gestion contact, application de téléphonie...)

Structure

Linux Kernel• Noyau standard Linux 2.6.24, pourquoi? :

– Gestion de la mémoire et des processus éprouvée

– Modèle de sécurité basé sur les permissions

– Modèle de fonctionnement autours de drivers (pilote)

– Support de librairies partagées

– Est déjà open source

• Ce n’est pas linux :

– Remplacement de la bibliothèque GNU glibc par BIONIC libc

– Environnement d’exécution (Dalvik) customisé.

– L’Open binder remplacé par un binder propre à android

– Retrait de gestionnaire d’interface Window x => SurfaceFlinger

– Les API ne respectent pas forcement la norme POSIX

Linux Kernel le patch • Alarm : timers pour déclenchement d’event (veille, réveil …)

• Ashmem : (android shared memory) partage de mémoire entre

processus

• Low memory killer

• Logger

• Binder

• Power management

• …

Communication interprocessus• Une application = un processus

• Partage de données

• Enjeu de sécurité

• La gestion IPC n’est pas laissé aux dev

• Binder = IPC android

• Utilisation des ashmem

• Performance par rapport à une recopie ou à une

sérialisation

• Concurrence d’accès => le Binder synchronise les

appels

Communication interprocessus1. L'application A récupère une référence vers le

Service B à l'aide du Context Manager *

2. La méthode foo() du service B est appelée par

l'application A

3. Le binder intercepte l’appel

4. Un thread libre dans le thread pool, exécute la

méthode sur le service B

* Le context manager permet de récupérer une référence vers un objet

java (le service) par son nom (assimilable à un DNS ou au registry

dans RMI). Tous les objets qu’on souhaite partager doivent être

enregistré au préalable dans le context manager

Gestion de l’alimentation• Mobilité = batterie

• Batterie = capacité limitée

• Economie de l’utilisation de l’alimentation

• Verrouillage automatique de l’écran

• Arrêt automatique des applications

• Mise en veille automatique

• Les wake Lock :

PowerManager pm = (PowerManager) getSystemService(Context.POWER_SERVICE);

PowerManager.WakeLock wakeLock = pm.newWakeLock(pm.SCREEN_DIM_WAKE_LOCK, "My

wakelook");

// This will make the screen and power stay on

// This will release the wakelook after 1000 ms

wakeLock.acquire(1000);

// Alternative you can request and / or release the wakelook via:

// wakeLock.acquire(); wakeLock.release();

Structure

Les librairies

• Licence indépendante du noyau linux

• Natives en C/C++

• Assurent les fonctionnalités de bas niveau :

Les librairies• Bionic Libc :

– plus légère (chargée avec chaque processus)

– moins gourmande (cpu des mobiles plus faible)

– Compatible avec les processeurs ARM omniprésente sur les

tablettes et téléphones (faible consommation, simple

architecture) par rapport aux X86

Les librairies• WebKit :

– Moteur de rendu web

– Utilisé par un navigateur web

– Développé par KDE project, Apple, Nokia, Google et d'autres

– Supporte le CSS, Javascript, DOM, AJAX.

– Deux librairies GPL: WebCore et JavascriptCore

Les librairies• MediaFramework:

– basée sur OpenCore de PacketVideo

– Supporte des standards audio/vidéo/images.

– Supporte les plugin codec hardware et software

Les librairies• SQLite:

– SGBD léger, open source

– Transactionnel

– Relationnel (sql)

– Persistance des données android (sms, contacts ..)

– Source des contentProvider

Les librairies• Surface flinger:

– Construit le rendu graphique à afficher

– Combine les surfaces provenant de différentes applications

(surfacemanager)

– Supporte le 2D/ 3D, OpenGL ES, l’accélération matériel, l’API

Khronos

– Double buffering

Les librairies• Audio flinger:

– Traite les flux audio

– Routage vers les périphériques de sortie : haut parleur,

Bluetooth, casque

HAL• Fournit les interfaces que doivent implémenter les

drivers kernel

• Faciliter le portage des librairies sur différents matériels

• Les fabricants ne sont pas obligé de mettre leurs interface sous

licence GPL

Android runtime

• VM Dalvik :– VM moins volumineuse et plus rapide

– Utilise un ByteCode plus léger = fichier .dex à la place des fichiers .class et .jar

– Tout les services android et les ressources materielles sont mis à disposition à

traver Dalvik

– Toute application sera exécuté dans la machine Dalvik

• Librairies Java :– java.io

– java.lang (sauf java.lang.management)

– support

– java.math

– java.net

– java.nio

– java.sql

– java.text

– java.util

– javax.crypto

– javax.net

– javax.sound

– javax.xml.parsers

– org.w3c.dom

– …

Framework

• Ensemble de service communiquant avec les applications

• Utilisables directement pendant le développement sous android

• Un service est une application qui n'a aucune interaction avec

l'utilisateur et qui tourne en arrière plan pendant un temps indéfini

Framework

Core Plateform Services :

• Activity Manager : gère le cycle de vie des applications et maintient une "pile de

navigation" (navigation backstack) permettant d'aller d'une application à une autre et

de revenir à la précédente quand la dernière application ouverte est fermée.

• Package Manager : utiliser par l'Activity Manager pour charger les informations

provenant des fichiers .apk (android packaga file)

• Window Manager : juste au dessus du Surface Flinger (lien), il gère les fenêtres des

applications --> quelle fenêtre doit être afficher devant une autre à l'écran.

• Resouce Manage : gère tous ce qui n'est pas du code, toutes les ressources -->

images, fichier audio, etc.

• Content Provider : gère le partage de données entre applications, comme par

exemple la base de données de contact, qui peut être consultée par d'autres

applications que l'application Contact. Les Données peuvent partager à travers une

base de données (SQLite), des fichiers, le réseau, etc.

• View System : fournit tous les composants graphiques : listes, grille, text box, buttons

et même un navigateur web embarqué.

FrameworkHardware Service :

• Telephony Service : permet d'accéder aux interfaces "téléphonique" (gsm, 3G, etc.)

• Location Service : permet d'accéder au GPS.

• Bluetooth Service : permet d'accéder à l'interface bluetooth.

• WiFi Service : permet d'accéder à l'interface Wifi.

• USB Service : permet d'accéder aux interfaces USB.

• Sensor Service : permet d'accéder aux détecteurs (détecteurs de luminosité, etc.)

LocationManager lm = (LocationManager)

Context.getSystemService(Context.LOCATION_SERVICE);

Startup :

• bootLoader charge le kernel et lance le processus init

• Lancement des daemons :

– USB daemon (usbd)

– Android Debug Bridge (adbd)

– Debugger Daemon (debuggerd); Il permet de gérer les requêtes

de debug de processus (dump memory, etc.)

– Radio Interface Layer Daemon (rild)

Startup :

• init lance le processus zygote :

– initialise une instance de Dalvik VM

– Pré charge les classes et écoute sur une socket pour créer des Dalvik VM

– Fork sur demande pour créer des instances de Dalvik VM pour chaque

application

– Les VM créées partagent des zones mémoire communes ce qui permet de

minimiser la mémoire utilisées

– Chaque VM créer par zygote est un fork d'une VM "mère", ce qui permet

d'accélérer le démarrage d'une application.

• Init lance le processus runtime qui va lancer le Service Manager ( "DNS"

permettant d'enregistrer et de récupérer des références vers des

services) et enregistre ce Service Manager comme le Context Manager

par défaut

Startup :

• Une fois tous cela de fait, le processus runtime, envoie une requête au processus zygote lui demandant de lancer le System Service. Zygote va forker une nouvelle instance de Dalvik VM pour le processus System Service et démarrer le service.

• Le System service va lancer à son tour l'Audio Flinger et le surface Flinger qui vont ensuite s'enregistrer auprès du Service Manager

Startup :

• Le System Manager lance ensuite les services d'Android. Ces services une fois lancés vont s'enregistrer au près du Service Manager (en bleu), qui fait office de proxy avec le Service Manager (en vert) faisant partie des librairies C/C++.

Startup :

• Le System est prêt. Des applications utilisateur peuvent être lancées

Startup :

• Le System est prêt. Des applications utilisateur peuvent être lancées

À propos des applications

• Une application > un processus

• S’exécute dans une instance distincte Dalvik VM

• On peut uniquement démarrer une application non la fermer

• Le système arrêtera automatiquement le processus si nécessaire

• Conservation de l’état des activités après destruction

Interactions des couches

• 3 scenarios possible :

• Application => runtime => librairie

• Application => runtime => service natif => librairie

• Application => runtime => Daemon natif => librairie

À voir :

• Anatomy and Physiology of an Android : https://www.youtube.com/watch?v=G-36noTCaiA#t=2101

• DEX File format :http://www.retrodev.com/android/dexformat.html

Mercinaydnabil@gmail.com