Développement embarqué mobile

Wided Souidène Mseddi

EniCar
2020- 2021
CONDITIONS PRÉALABLES

✗Utilisateur de base des distributions GNU /Linux.

- Lignes de commande (ls, cp, cat, grep, find, vi, etc.).

✗Architecture de systèmes avec Linux embarqué.

✗Connaissance de base de C, C ++ et Java.

Zoom sur Android embarqué

Introduction au système d'exploitation Android

HISTORIQUE

✗ 2003: Démarrage d'une startup appelée Android Inc. à Palo Alto /CA, axée sur le
développement d'un système d'exploitation ouvert pour les smartphones.

✗ 2005: Android Inc. acheté par Google.

✗ 2007: Open Handset Alliance est créé, un consortium d'entreprises s'intéressant au domaine mobile
(Google, Intel, IT, Qualcomm, Nvidia, Motorola, HTC, Samsung, etc.).

✗ 2008: la version 1.0 d'Android estsortie.

VERSIONS

✗Depuis, une ou deux nouvelles versions d'Android ont vu le jour

chaque année, où chaque version porte le nom d'un dessert par ordre
alphabétique!

An Version An Version
2010 2.2 (yogourt glacé) 2014 5 (sucette)
2010 2.3 (pain d'épice) 2015 6 (guimauve)
2011 3.0 /3.1 /3.2 (nid d'abeille) 2016 7 (Nougat)

2011 4.0 (Sandwich à la crème glacée) 2017 8 (Oreo)

2012 4.1 /4.2 /4.3 (Jelly Bean) 2018 9 (tarte)

2013 4.4 (KitKat) 2019 dix (?)

Ce coursestbasé sur la version9.0 Pie.

✗
CARACTÉRISTIQUES PRINCIPALES

✗ La base du système d'exploitation (AOSP) est l'opensource.

✗ Interface graphique avec une expérience très familière.

✗ Vaste écosystème d'applications (environ 2700000 applications en août /2019).

[Link]

✗Cadre complet pour le développement d'applications, avec

API, IDE (Android Studio), émulateur, outils de débogage etde test,
documentation, livres, vidéos, etc.
PRINCIPALES CARACTÉRISTIQUES (suite)

✗ Le langage de programmation de base (Java) est familier etrépandu.

✗Prise en charge complète des technologies Web.

✗Support matériel, y compris:

✗
Accélérateurs graphiques via OpenGL ES.
✗
Technologies de communication sans fil(Bluetooth, WiFi, NFC, GSM, CDMA, UMTS, LTE, etc.).

✗ Capteurs (accéléromètre, gyroscope, boussole, etc.).

ANDROID DANS LES SYSTÈMES EMBARQUÉS

Ces fonctionnalités et d'autres conduisent Android à être évaluéet

✗

utilisé comme système d'exploitation dans des applicationsdédiées.

PROJET ANDROID OPEN SOURCE

Android repose essentiellement sur deux projets majeurs:

✗

✗ Noyau Linux (modifié).

✗ Plateforme Android (AOSP).

✗ Avec chaque version, Google publie le code source du projet via le projet Open Source
Android (AOSP).

[Link]

✗ Seuls quelques appareils sont pris en charge

nativement par AOSP, y compris les derniers
appareils de référence Google (Pixel), les cartes
Linaro HiKey et les émulateurs pour diverses
architectures matérielles.
COMMUNAUTÉ ET COLLABORATION

✗ Plusieurs groupes de discussion sont disponibles pour communiquer avec les

développeurs du projet:

[Link]

✗ Tout le monde peut contribuer au projet grâce à l'outil de révision de code Gerrit, créé
par Google.
[Link]

✗ L'évolution du projet et les fonctionnalités qui seront disponibles dans une future version
d'Android sont contrôlées exclusivement par Google.
LICENCES

La grande majorité des composants logiciels sont sous licences

✗

Apache et BSD permissifs, donnant aux fabricants la liberté de décider de publier ou non le code
source modifié (les licences permissives ne nécessitent que l'attribution de la paternité).

Certains composants logiciels sont sous licences GPL/ LGPL

✗

(voir annuaire externe /dans AOSP).

Certaines applications Google sont fermées (Google Play, Gmail, Google Maps, YouTube, etc.).
✗

✗
Ces applications sont disponibles dans un package appelé Google Mobile Services
(GMS), et pour les obtenir, il est nécessaire de certifier l'appareil (ACP).
CERTIFICATION

✗Pour que l'appareil puisse avoir le label Android etutiliser les Applications Google, il est
nécessaire de le certifier via le programme de compatibilité Android (ACP):

✗ Document de définition de compatibilité (CDD): décrit les exigences logicielles et matérielles

nécessaires pour qu'un appareil soit considéré comme compatible avec Android.

✗ Compatibility Test Suite (CTS): outil qui fournitun ensemble de tests unitaires à effectuer sur
l'appareil pour garantir sa compatibilité avec Android.

✗Plus d'informations sur le site web du projet:

[Link]
VERSIONS ALTERNATIVES D'ANDROID

Il existe quelques variantes Android officielles fournies par Google:

✗

✗
Android TV.

✗ Android Auto.

✗ Android Wear.

✗ Choses Android.

Il existe également des versions alternatives d'Android développées par la communauté :

✗

✗ LineageOS (anciennement CyanogenMod).

✗ CopperheadOS.

✗ Replicant.
ARCHITECTURE DU SYSTÈME GNU / LINUX

Application Application

Système
GNU /Linux

Bibliothèque Bibliothèque

Bibliothèque C (glibc, eglibc, uclibc, etc.)

Noyau Linux

Bootloader

Matériel
 ARCHITECTURE DU SYSTÈME ANDROID

Application Application Application Application

Plate-forme
Android Framework (services etAPI)

Couche native (bibliothèques, démons et outils)

Noyau Linux

Bootloader

Matériel
Android embarqué

Code source
MACHINE DE DÉVELOPPEMENT

✗ Il est recommandé d'utiliser une machine 64 bits avec Ubuntu 14.04, car c'est la configuration utilisée ettestée par
Google, mais le système de construction (Build) doit fonctionner sur d'autres machines Linux ou MacOS
(installation native ou machine virtuelle).

✗ Une machine avec une bonne capacité de traitement, beaucoup de mémoire et d'espace disque (au
moins 200 Go pour une construction complète) est nécessaire.

✗ Prérequis logiciels: git, python, make, unzip, curl, etc.

✗ Plus d'informations sur la configuration de l'environnement de construction (Build) :

[Link]
REPOSITOIRES (depôts) AOSP ET GIT

✗AOSP est versionné par Google via Git.

✗Cependant, le projet est divisé en centaines de référentiels Git (si le projetétait

géré par un seul dépôt Git serait lent à télécharger et difficile à gérer!).

✗Les référentiels Git d'Android sont accessibles via le lien ci-dessous:

[Link]
 Embarqué Labworks

REPOSITOIRES AOSP ET GIT (suite)

 OUTIL REPO
✗Pour gérer les centaines de référentiels Git dans AOSP,
Google a créé un outil appelé repo.
[Link]

✗ repo peuvent être téléchargés à partir du site Web de Google comme suit:

$ curl [Link] ~ /bin /

repo

✗Via un fichier XML ( [Link]) qui décrit tous les référentiels qui
composent AOSP, l'outil repo est capable de télécharger et de gérer une
version spécifique d'Android.
[Link]

<? xml version ="1.0" encoding ="UTF-8"?>

<manifest>

<à distance name ="aosp"

fetch =".."
review ="[Link]
<par défaut revision ="refs /tags /android-9.0.0_r22" remote =
"aosp"
sync-j ="4" />

<project path ="build /make" name ="platform /build" groups ="pdk">

<copyfile src ="core /[Link]" dest ="Makefile"/>
<linkfile src ="[Link]" dest ="build /[Link]" /></project>

<project path ="bionic" name ="platform /bionic" groups ="pdk"/>

<project path ="bootable /recovery" name ="platform /bootable /recovery" groups ="pdk" /><project path ="compatibilite /cdd" name ="platform /compatibilite /cdd" groups =
"pdk" /><project path ="cts" name ="platform /cts" groups ="cts, pdk-cw-fs, pdk-fs" /><project path
="dalvik" name ="platform /dalvik" groups ="pdk- cw-fs, pdk-fs "/>

<project path ="developer /build" name ="platform /developer /build" groups ="developer" /><project path ="developer /demos" name ="platform
/developer /demos" groups ="developer" /><project path ="device /common" name ="device /common" groups ="pdk-cw-fs, pdk" /><project path ="device /generic /arm64"
name ="device /generic /arm64" groupes ="pdk" /><project path ="device /generic /car" name ="device /generic /car" groups ="pdk" />

...
TÉLÉCHARGER AOSP AVEC REPO

$ repo init -u [Link]

$ repo sync

[...] Ici, il clonera chacun des dépôts git!

TÉLÉCHARGEMENT D'AOSP AVEC REPO (suite)

✗Par défaut, le repo téléchargera la branche de développement (maître) de l'AOSP.

✗Nous pouvons télécharger une version spécifique d'Android indiquant le

branche ou étiquette avec le paramètre -B:

$ repo init-u [Link] \

-b android-9.0.0_r22

✗La liste des branches et balises existantes est disponible sur le projet:
[Link]
AUTRES CONTRÔLES REPO

✗
repo diff( diff sur tous les dépôts Git).

✗ repo status
( vérifie l'état de tous les dépôtsGit).
✗
repo start
( crée une nouvelle branche dans AOSP).

✗
repo branches
( affiche les branches existantes).

✗ repo forall ( exécute une commande sur tous les référentiels Git).

✗ Repo help ( affiche un menu completd'options).

REPO ET COLLABORATION

✗ Google a développé un outil appelé Gerrit pour faciliter la révision du code et le

processus de collaboration.
[Link]

✗ À travers les outils gitet repo, toutle monde peut contribuer au développement d'Android:

✗ Créez une nouvelle branche:

$ repo start<nom_branch>

✗ Engagez-vous dans les référentiels avec Git. Soumettez

✗ le code pour examen sur Gerrit:

$ repo import
REPOSITOIRES ANDROID

✗ AOSP est le référentiel Android officiel, mais offreun support

limité aux périphériques matériels.

Linaro fournitune arborescence alternative etmise à jour avec prise en charge d’un plus grand
✗

ensemble de périphériques matériels avec un focus ARM:

$ repo init-u git://[Link]/platform/[Link]

LineageOS (anciennement CyanogenMod) a des versions personnalisées

✗

axées sur les appareils grand public (smartphones ettablettes):

$ repo init-u [Link]

 REPOSITORIES ANDROID (suite)
✗ Les fabricants de systèmes sur puce (SoC) tels que NXP et Qualcomm
fournissent également à leurs clients une version modifiée d'AOSP pour
leurs processeurs:

[Link]
dev elopment-boards /[Link]-applications-processors:
IMXANDROID

✗La communauté pour une plate-forme matérielle donnée peut

maintenir une arborescence Android distincte:

[Link]
-410c/software
[Link]
de [Link]
REPOSITORIES ANDROID (suite)

La source: [Link]
RÉPERTOIRES: HARDWARE

✗ bootable/
image de partition de récupération.
✗ kernel/
fichiers de configuration et scripts de test du noyau.
✗ hardware /
définition de HAL et implémentation standard pour certains périphériques
matériels.
✗ device /

configurations et composants spécifiques au produit pris en charge par

AOSP.
RÉPERTOIRES: COUCHE NATIVE

✗ Bionic/ Bibliothèque C standard

d'Android.
✗ system/: applications et bibliothèques de
couches natives.
✗ external /: projets externes utilisés sur Android (openssl, webkit, libusb,etc.).

✗ libnativehelper /:bibliothèque pour l'interface JNI.

RÉPERTOIRES: CADRE ET APPLICATIONS

✗
dalvik /:code source de la machine virtuelle Dalvik.

✗ art /:code source de la machine virtuelle ART.

✗ libcore /:bibliothèque Java standard (Apache Harmony).

✗ framework /:code source du framework Android.

✗
✗ packages/: Applications Android.
RÉPERTOIRES: OUTILS

✗
sdk /:Outils SDK (Software Development Kit).

✗
pdk /:Outils PDK (Platform Development Kit).

✗
development /,test/,platform_testing /,developpers /,tools/:outils de
développement, de testetde débogage.

✗ cts /:Outils CTS (Compatibility Test Suite).

RÉPERTOIRES: BUILD etDOCUMENTATION

✗
BUILD /:Fichiers et scripts de constructionAndroid.

✗
prebuilts/:
/:binaires précompilés, y compris les chaînes d'outils.

✗ toolchain/:scripts de testetfichiers de support de la chaîne d'outils.

✗
compatibility /:code source du document de définition de compatibilité (CDD).
NAVIGUER DANS LE CODE SOURCE

✗ Comme il n'y a pas beaucoup de documentation sur AOSP, il est courant de devoir
parcourir le code source pour comprendre une certaine fonctionnalité Android.

✗ Pour cela, nous pouvons générer un fichier de projet AOSP et utiliser Android Studio pour
parcourir le code source Android.

$ développement de chat /outils /idegen /README

✗Une autre façon de parcourir le code source officiel d'Android consiste à

via le site Web AndroidXRef.

[Link]
RÉFÉRENCE CROISÉE ANDROID
RÉFÉRENCE CROISÉE ANDROID (suite)
LABORATOIRE

Code source Android

Android embarqué

Construire le système
CONSTRUIRE DES SYSTÈMES

✗Les systèmes de construction ont pour objectif principal

intégrer tous les composants logiciels d'un système Linux (toolchain, bootloader, noyau, système
de fichiers) pour construire l'image du système d'exploitation.

Sous Linux, les deux principaux projets de systèmes de construction sont les
✗

Buildroot et le projet Yocto.

✗Android a sa propre solution de système de construction!

SYSTÈME ANDROID BUILD

Dans le passé, le système de construction Android étaitpurement basé

✗

dans les makefiles traités par l'outil make.

À ce stade, les instructions de compilation pour chaque composant de

✗

les logiciels ont été définis dans des fichiers [Link].

Ce système de construction présentait plusieurs lacunes, notamment une faible

✗

performances dans les versions incrémentielles, eta été remplacé dans les dernières versions d'Android par le

système de construction Soong. [Link]

CONSTRUIRE UN SYSTÈME SOONG

✗ Dans le système de construction Soong, les règles de compilation des composants logiciels sont définies
dans les fichiers Blueprint ( [Link]), qui ont une syntaxe de type JSON.

✗ Les fichiers Blueprint sont traités par l'outil Blueprint, qui produit un fichier avec une extension. ninja avec
toutes les règles de traitement des composants logiciels Android.

[Link]

✗ Le fichier avec l'extension. ninja est traitépar l'outil Ninja, qui compilera tous les composants
logiciels et générera les images Android.

[Link]
CONSTRUIRE UN SYSTÈME SOONG (suite)

✗ Tous ne créent pas de fichiers ( [Link]) converti en fichiers Blueprint ([Link])

lors de la migration vers ce nouveau système de construction.

✗ Pour cette raison, un outil appelé kati est responsable de la conversion des fichiers
[Link] dans les fichiers. ninja.

[Link]

✗ La tendance est que peu à peu les fichiers [Link] sont convertis en [Link],
éliminant le besoin d'utiliser l'outil kati dans le système de construction Android.
CONSTRUIRE UN SYSTÈME SOONG (suite)

plan
[Link] . ninja

ninja Binaires et images

. ninja Android (disque virtuel,
système, données, etc.)

kati
[Link] . ninja
[Link]

La première étape de l'utilisation du système de construction consiste à exécuter le

✗

script de configuration d'environnement build /[Link]:

$ source build /[Link]

✗ Ce script modifiera la configuration du terminal actuel, définissant certaines commandes,

variables d'environnement etmacros qui seront utilisées pendant le processus de compilation.

✗ La commande la source est nécessaire pour garantir que les modifications sont appliquées au terminal
actuel de l'utilisateur.
[Link] (suite)

✗Voici quelques-unes des commandes créées par le [Link]:

✗
lunch: sélectionne le produit et la variante de construction pour la compilation.
✗
croot: retourne au répertoire racine AOSP.
✗
godir: allez dans le répertoire contenant le fichier spécifié.
✗ cgrep: fichiers grep. c, .cpp et. H. jgrep: fichiers grep. Java. porter secours: fichiers

✗ de ressources grep*. xml.

✗
mangrep: fichiers grep [Link].

hmm: affiche la liste complète des commandes disponibles.

✗
PRODUIT ET VARIANTE

Après avoir exécuté le script [Link], l'étape suivante consiste à configurer le

✗

produit et la variante de construction que vous souhaitez compiler.

✗Un produit définit les caractéristiques matérielles (architecture, périphériques, etc.) et des logiciels
(configuration, applications, etc.) qui seront utilisés pour générer l'image d'Android.

✗La variante de build indique le type de build que vous souhaitez faire:

✗ eng: développement build.

✗
utilisateur: construction de production.

✗ userdebug: construction de production avec accès racine.

CONFIGURATION DU PRODUIT

La configuration du produit et de la variante de construction est effectuée

✗

via des variables d'environnement:

✗ TARGET_PRODUCT: Nom du produit.

✗
TARGET_BUILD_VARIANT: construire une variante.

✗Ces variables peuvent être définies dans un fichier appelé [Link], qui

doit être stocké dans le répertoire racine AOSP (exemple dans build /
[Link]).

✗Cependant, la forme la plus courante de configuration de produit est

des commandes le déjeuner ou choosecombo.
lunch

$ lunch

Vous construisez sur Linux

Menu du déjeuner ... choisissez un combo:

1. aosp_arm-fra
2. aosp_arm64-fra
3. aosp_mips-fra
4. aosp_mips64-fra
5. aosp_x86-fra
6. aosp_x86_64-fra
7. aosp_car_arm-userdebug
8. aosp_car_arm64-userdebug
...

Lequel veux-tu? [aosp_arm-eng]

Lunch (suite)

✗ La commande le déjeuner affichera une liste d'options au format

<produit> -<variant> ( également appelé combo), et l'utilisateur doit sélectionner
l'une de ces options.

✗ Vous pouvez également exécuter la commande le déjeuner qui passe

le nom du combo directement:

$ lunch aosp_x86_64-fra

✗Lors de la sélection du combo, la commande le déjeuner créera les variables

requis pour la compilation:

$ env | grep "ANDROID \| TARGET"

CHOOSECOMBO

$ choosecombo
Les choix de type de construction sont:
1. release
2. debug

Lequel veux-tu? [1]

Quel produit aimeriez-vous? [aosp_x86_64]

Les choix de variantes sont:

1. utilisateur
2. userdebug
3. eng

Lequel veux-tu? [eng]

COMPILATION

Après avoir sélectionné le produit, compilez simplement avec la commande faire:

✗

$ make

✗La commande m a le même objectif etpeut être utilisépour

compilez Android à partir de n'importe quel répertoire AOSP:

M$

✗Le processus de construction peut prendre quelques heures, selon

de la machine de construction. Utilisez le paramètre -jpour paralléliser le processus de compilation:

$ m -j4
RÉPERTOIRE /

L'ensemble du processus de construction d'Android aura lieu le

✗

annuaire en dehors /.

✗Dans l'annuaire out /hôte /nous aurons les outils, les exécutables et
bibliothèques compilées pour l'hôte (ex: émulateur, mke2fs, etc).

Dans l'annuaire out /target /nous aurons les binaires compilés pour le
✗

cible.

Les images finales seront disponibles dans le répertoire de sortie du

✗

produit dans out /target /product /<product_name> /.

IMAGES FINALES
AUTRES OBJECTIFS DE MARQUE

Listez les principales cibles existantes:

✗

$ make help

Effacez le répertoire de construction ( Oct /):

✗

$ make clean

Commande alternative pour effacer le répertoire de construction ( Oct /):

✗

$ make clobber

Affichez les commandes exécutées lors de la compilation:

✗

$ make showcommands
AUTRES COMMANDES (suite)

Compilez tous les modules du répertoire courant:

✗

$ mm

Compilez tous les modules dans un répertoire spécifique:

✗

$ mmm <repertoire>

Régénérer l'image [Link]:

✗

$ make snod

Régénérer l'image [Link]:

✗

$ make vnod
RÉGLER UNE IMAGE

Si vous avez modifié une application, pour recompiler etrégénérer le

✗

Les images Android utilisent simplement la commande m:

$ m -j4

Alternativement, nous pouvons recompiler une application

✗

et régénérer les images Android séparément (le résultat final est le même). Exemple:

$ mmm system /vold

$ m snod
EMULATEUR

✗Android dispose d'un émulateur d'appareil mobile, capable de fonctionner dans la machine hôte
et émuler le système généré.

✗Cet émulateur peut être compilé à l'aide des produits qui démarrent avec aosp ( aosp_arm,
aosp_x86, aosp_x86_64, etc).

✗Il est capable d'émuler l'interface utilisateur via le moniteur, le clavier et la souris.

✗Divers autres périphériques matériels et événements tels que les coordonnées GPS, réception de
SMS ou changement d'état de la batterie peuvent être émulés via une interface graphique ou via
une connexion telnet.
ÉMULATEUR (suite)

✗En interne, l'émulateur Android est une interface graphique développésur QEMU.
[Link]

✗Pour compiler une image Android pour l'émulateur:

$ source build /[Link]
$ lunch aosp_x86_64-fra
$ m -j4

✗Et pour exécuter l'émulateur:

$ emulator
ÉMULATEUR (suite)
ÉMULATEUR (suite)
LABORATOIRE

Système de construction Android

 Embarqué Labworks

Android intégré

Architecture du systèmed'exploitation
 ARCHITECTURE ANDROID

Application Application Application Application

Plate-forme
Android Framework (services etAPI)

Couche native (bibliothèques, démons et outils)

Noyau Linux

Bootloader

Matériel
 MATÉRIEL

Application Application Application Application

Plate-forme
Android Framework (services etAPI)

Couche native (bibliothèques, démons et outils)

Noyau Linux

Bootloader

Matériel
MATÉRIEL TYPIQUE AVEC ANDROID

La source: [Link]
CPU

✗Android prend officiellement en charge les architectures ARM, x86 et MIPS.

✗Le plus courant est de trouver Android sur les appareils architecturaux ARM avec un ou
plusieurs cœurs fonctionnant au-dessus de 1 GHz.

✗Les architectures comme x86 et MIPS sont également prises en charge par d'autres
les entreprises ou la communauté: [Link]
[Link]

✗À partir d'Android 4.0, un GPU pris en charge est également requis

OpenGL ES 2.0.
MÉMOIRE ET STOCKAGE

✗ Selon Google, un minimum de 416 Mo de RAM est requis (dépend de la taille de l'écran),
mais un système avec 1 Go est asseztypique.

✗ Normalement, 4 Go à 8 Go de stockage persistant sont nécessaires pour le système

d'exploitation, les données d'application et les fichiers utilisateur.

Actuellement, sur les appareils Android, il est courant d'utiliser des technologies stockage en
✗ bloc au lieu de
la mémoire flash, comme les puces eMMC.
AUTRES CARACTÉRISTIQUES RECOMMANDÉES

✗ Écran tactile (spécification minimale définie par Google: 2,5 ", 426x320, 16 bits).

✗ Boutons de navigation (MENU, HOME, BACK). Les boutons peuvent également être émulés dans
le logiciel.

✗ Capteurs (accéléromètre, magnétomètre, GPS, gyroscope, etc.).

✗ Communication sans fil(Bluetooth, WiFi, NFC, etc.).

 BOOTLOADER

Application Application Application Application

Plate-forme
Android Framework (services etAPI)

Couche native (bibliothèques, démons et outils)

Noyau Linux

Bootloader

Matériel
BOOTLOADER

Le bootloader est le code responsable de:

✗

✗ Initialisez le matériel.
✗ Chargez et exécutez le système d'exploitation.

En plus de ces fonctionnalités de base, la plupart des chargeurs de démarrage

✗

il dispose d'un terminal de commande pour l'exécution de différentes opérations, telles que la vérification
de la mémoire, le formatage flash etles routines de diagnostic matériel.
BOOTLOADER SUR ANDROID

✗ Aucune fonctionnalité spécifique n'est requise dans le chargeur de démarrage pour Android, à part la possibilité

de charger et d'exécuter le noyau Linux.

✗ Étant donné que le chargeur de démarrage dépend entièrement du matériel, il n'y a pas de code
source du chargeur de démarrage dans AOSP.

✗ Normalement, chaque fabricant de SoC fournitun bootloader pour sa plate-forme

matérielle:
[Link]
[Link]
FASTBOOT

✗ Une fonctionnalité normalement disponible dans les chargeurs de démarrage pour Android est la démarrage

rapide:

[Link]

✗ O démarrage rapide est un protocole de communication avec le bootloader via USB, accessible via l'outil de
ligne de commande fastboot.

✗ Il présente plusieurs fonctionnalités, notamment:

✗ Lisez et modifiez les variables de configuration du chargeur de démarrage.

✗ Envoyez des commandes au chargeur de démarrage.

✗
Supprimer les partitions de périphérique.

✗ Mettez à jour les images du système d'exploitation.

FASTBOOT (suite)

$ fastboot -h
utilisation: démarrage rapide [<option>] <commande>

commandes:
mettre à jour <nom defichier>
Réfléchissez le périphérique à partirde [Link]. Définit l'emplacement
flashall flashé comme actif. Démarrage Flash, système, fournisseur et-si trouvé -
récupération. Si le périphérique prend en charge les emplacements,
l'emplacement sur lequel le flash a été flashé est défini comme actif. Les
images secondaires peuvent être flashées sur un emplacement inactif.

flash <partition> [<filename>] clignotantverrouillé Ecrivez un fichier sur une partitionflash. Verrouille l'appareil. Clignotant
empêche. Déverrouille l'appareil. Permet de flasher n'importe quelle
déverrouillage clignotant
partition sauf

partitions liées au chargeur de démarrage.

Empêche le clignotement lié au bootloader
clignotant lock_critical
partitions.
clignotant unlock_critical [...] Active le clignotement lié au bootloader
partitions.
 NOYAU

Application Application Application Application

Plate-forme
Android Framework (services etAPI)

Couche native (bibliothèques, démons et outils)

Noyau Linux

Bootloader

Matériel
APERÇU DU KERNEL

Application Application

Bibliothèque Bibliothèque Application

Espace utilisateur

Bibliothèque C

Appels système Événements /statut

(fichiers, sockets, etc.)

Noyau Linux

Gestion du matériel Notification d'événement

Matériel
KERNEL LINUX S U R ANDROID

✗ Comme pour les distributions GNU /Linux, le noyau utilisé sur Android est modifié pour
répondre aux besoins du projet.

✗ Cependant, les changements dans le noyau sont si importants (des centaines de correctifs) que la couche

utilisateur Android ne fonctionnera pas avec un noyau Linux standard.

✗Pour le moment, la plupart des changements sont déjà intégrés dans la version
noyau officiel, étant possible d'exécuter un système Android avec un noyau principal.
LIANT

✗ Mécanisme IPC /R P C d'Android, ajoutant au noyau la possibilité d'appeler des objets à

distance.

✗ Toutes les communications entre les applications, les services et HAL ont lieu via Binder. Sans cela, Android ne
fonctionne pas!

✗ Le classeur est exposé à l'utilisateur dans des fichiers sur /dev, étant accédé par des appels
ioctl().

#ls /dev /*classeur

/dev /binder /dev /hwbinder /dev /vndbinder
EXEMPLE DE LIANT

Capteur
Application Un service
Directeur
Android Directeur
Un service

4 3 1 deux

Pilote de classeur (/dev /binder)

ASHMEM

✗ Ashmem (Anonymous Shared Memory) est un mécanisme de partage de mémoire entre les
processus utilisés surAndroid.

✗ Certaines lacunes du mécanisme standard de partage de mémoire Linux (POSIX SHM) comme la
fuite de ressources ont conduit à la création de cette nouvelle interface par Google.

✗ Par exemple, cette implémentation utilise un compteur de référence pour détruire les régions de
mémoire qui ne sont plus utilisées par aucun processus.

✗ À travers le fichier /dev /ashmem une application demande une région mémoire et la partage avec
d'autres processus via Binder.
WAKELOCKS

✗ Wakelock est une fonctionnalité de gestion de l'alimentationAndroid.

✗ L'idée est de mettre le CPU en mode veille chaque fois que possible:

✗ Lorsqu'une application veut garder le C PU allumé, elle doit contenir un wakelock.

✗ Quand personne ne tientun wakelock, le noyau met le C PU en mode basse

consommation.

✗ Le contrôle se faitvia les fichiers exportés par le noyau:

#ls /sys /power /wake_ *

/sys /power /wake_lock
/sys /power /wake_unlock
TUEUR DE MÉMOIRE FAIBLE

✗ Lorsque le système est à court de mémoire, le noyau Linux exécute le Killer OOM (Out-of-Memory)
par défaut, qui tentera de tuer certains processus pour libérer de la mémoire.

✗ OOM Killer n'est pas prévisible etpourrait tuer un processus Android important. Pour
cette raison, Google a développé le Low Memory Killer.

✗ Le Low Memory Killer est déclenché avant le OOM Killer et:

✗ Il prend en compte la priorité etl'oisiveté du processus. Il permetde

✗ notifier un processus avant de le fermer.
COMMENT OBTENIR DES SOURCES DE NOYAU?

Il n'y a pas de code source pour le noyau Linux dans AOSP.

✗

✗Le code source du noyau est généralement fourni par le fabricant

du matériel.

S'il s'agit d'une version récente du noyau, les fonctionnalités de base d'Android
✗

(classeur, ashmem, lmk, etc.) devraient être disponibles.

S'il s'agit d'un noyau plus ancien, ou si vous voulez que toutsoit disponible
✗

les modifications apportées au noyau par Google, vous pouvez extraire les correctifs de l'arborescence
du noyau Google etles appliquer à votre noyau.

[Link]
 SYSTÈMES DE FICHIERS

Application Application Application Application

Plate-forme
Android Framework (services etAPI)

Couche native (bibliothèques, démons et outils)

Noyau Linux

Bootloader

Matériel