Le code source Android n’est pas un bloc uniforme : l’AOSP répartit les applications, les services, les bibliothèques et les composants matériels dans des répertoires spécialisés. Lire cette organisation aide à comprendre comment le système d’exploitation Android relie l’interface visible aux couches techniques.
Pour un développeur qui prépare une ROM personnalisée ou examine un problème système, le chemin parcouru dans l’arborescence compte autant que le fichier étudié. Quelques dossiers donnent rapidement une carte utile de cette architecture logicielle.
A retenir :
- Répertoires AOSP associés aux principales couches d’Android
- Différence entre framework Android, services système et applications
- Rôle de la couche d’abstraction matérielle et des pilotes
- Repères pour explorer, compiler ou personnaliser une plateforme
Structure AOSP : repérer les couches du code source Android
Une fois l’arborescence récupérée, le premier repère consiste à distinguer les composants destinés aux applications de ceux qui pilotent la plateforme. La disposition exacte évolue selon les versions et les configurations de compilation.
Packages et frameworks : des applications aux API système
Le répertoire packages rassemble des applications et composants livrés avec certaines configurations Android, tandis que frameworks/base contient une grande partie des API et services centraux. Selon la documentation AOSP, le projet expose une implémentation modifiable de la plateforme, mais tous les appareils ne livrent pas exactement les mêmes éléments.
Un développeur qui cherche comment l’application Paramètres consulte les fonctions système peut examiner son code dans les sources correspondantes, puis suivre les API du framework Android utilisées. Les services associés, comme la gestion des activités ou des paquets, permettent de comprendre ce qui se passe au-delà de l’écran.
Pour lire l’arborescence sans se disperser, ces repères offrent un point de départ :
- packages : applications et composants regroupés par fonction
- frameworks/base : API, ressources et services de la plateforme
- system : outils et composants système de bas niveau
- build : règles et outils de compilation de la plateforme
Ces chemins indiquent des zones de recherche, pas une carte figée : certains modules peuvent changer de place ou être gérés séparément. Après les couches visibles et les services, l’exécution du code constitue un autre repère essentiel.
Architecture logicielle Android : exécution, système et compilation
Quand les API et les applications sont repérées, l’analyse peut descendre vers les composants qui exécutent le code et maintiennent les fonctions communes. Ces dossiers éclairent les performances, le stockage, le réseau et la compilation.
Machine virtuelle ART et bibliothèques fondamentales
La machine virtuelle ART, dont les sources se trouvent dans le répertoire art, exécute le code des applications Android. Elle gère notamment l’exécution et la mémoire, tandis que libcore fournit des bibliothèques de base utilisées par la plateforme.
Le dossier dalvik renvoie surtout à l’ancienne machine virtuelle, remplacée par ART comme environnement d’exécution principal depuis Android 5.0. Selon la documentation AOSP, il faut donc interpréter ce répertoire en tenant compte de son contexte historique et de la branche consultée.
System et build : services de plateforme et production des images
Le dossier system regroupe des composants de bas niveau, alors que build contient des éléments du système de compilation. Le répertoire de sortie out apparaît pendant la construction et accueille les fichiers générés, sans constituer une source à modifier comme un module ordinaire.
Un constructeur de ROM personnalisée peut ainsi vérifier les règles de compilation, sélectionner une configuration d’appareil, puis examiner les images produites. Selon les consignes du projet AOSP, les sources et outils nécessaires varient avec la cible choisie.
Les fonctions de ces dossiers se distinguent par leur rôle dans le cycle logiciel :
- art : environnement d’exécution des applications
- libcore : bibliothèques fondamentales de la plateforme
- system : composants et outils système
- build et out : compilation et résultats générés
Ces éléments expliquent comment Android exécute et assemble ses composants ; le fonctionnement concret d’un appareil dépend ensuite de l’interface avec ses équipements.
Noyau Linux, HAL et pilotes matériels dans AOSP
À mesure que l’analyse se rapproche de l’appareil, les différences entre fabricants deviennent déterminantes. Le noyau Linux, les pilotes matériels et la couche d’abstraction matérielle assurent le lien entre le logiciel Android et les composants physiques.
HAL et répertoires device ou vendor
La couche d’abstraction matérielle (HAL) expose des interfaces permettant au framework de solliciter des fonctions telles que la caméra, l’audio ou les capteurs. Les implémentations et leur organisation dépendent des versions Android, des interfaces utilisées et des choix du constructeur.
Les répertoires device et vendor contiennent souvent des configurations propres à une cible et des éléments fournis par le fabricant. Selon la documentation AOSP, l’intégration de ces composants est essentielle pour adapter la plateforme à un appareil précis, sans supposer que chaque pilote soit publié dans le même dépôt.
Noyau Linux et compatibilité matérielle
Le noyau Linux gère notamment les processus, la mémoire et les échanges avec les périphériques, au moyen de pilotes matériels adaptés. Les sources du noyau peuvent être distribuées séparément de l’arborescence principale d’AOSP, selon l’appareil et les pratiques du fournisseur.
Un tableau aide à distinguer les responsabilités avant de modifier une configuration ou de diagnostiquer une panne :
| Zone | Rôle principal | Exemple d’usage |
|---|---|---|
| frameworks/base | API et services Android | Suivre une demande d’application |
| hardware | Interfaces matérielles communes ou liées aux HAL | Étudier l’accès à la caméra |
| device | Configuration adaptée à un appareil | Repérer les paramètres de compilation |
| vendor | Éléments spécifiques fournis par un fabricant | Identifier une intégration constructeur |
| kernel | Sources ou configuration du noyau, selon l’arbre | Examiner un pilote périphérique |
La frontière entre code public et composants propres au fabricant explique pourquoi deux appareils peuvent s’appuyer sur la même base Android sans partager la même arborescence complète. Pour éviter les erreurs, il faut toujours vérifier la branche et la cible matérielle examinées.
Pour explorer une cible de manière méthodique, ces vérifications limitent les recherches à l’aveugle :
- Repérer la branche AOSP et la configuration d’appareil utilisées
- Suivre l’API depuis le framework jusqu’à l’interface HAL
- Vérifier où sont publiés les pilotes matériels concernés
- Comparer les fichiers de configuration avant toute modification
Cette lecture par couches permet de relier une fonction visible à ses dépendances, tout en gardant à l’esprit que les noms et contenus des dossiers évoluent avec les versions.
