Upload
nayd-nabil
View
211
Download
4
Embed Size (px)
Citation preview
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