Un développeur Android AOSP travaille sur des couches que le développeur d'applications ne voit jamais, et les questions d'entretien portent sur elles. Il écrit une HAL en AIDL stable, ajoute un service système en Java ou en C++, ouvre les droits SELinux d'un nouveau processus, déclare des modules dans des fichiers Android.bp pour le build Soong et fait passer les suites CTS et VTS. Sur Android Automotive OS, la HAL véhicule (VHAL) et CarService s'ajoutent.
Un développeur d'applications Android maîtrise Kotlin et Compose sans avoir jamais lancé lunch ni lu un refus SELinux. Un ingénieur Linux embarqué connaît le noyau et le BSP, mais pas forcément Binder ni la séparation entre system et vendor imposée par Treble. Les deux profils peuvent convenir si vous savez ce qui manque. Faites décrire la dernière image construite : version d'Android, carte ou SoC, partitions modifiées.
Le code source a aussi changé de rythme. Depuis 2026, Google publie AOSP deux fois par an, au deuxième et au quatrième trimestre, et recommande la branche android-latest-release pour construire. HIDL est déprécié au profit des HAL AIDL, et le VNDK l'est depuis Android 15. Le PDF contient 30 questions sur six axes et un cas de 20 minutes.
Les couches d'Android qu'un développeur plateforme modifie
AOSP, repo et build Soong
Le code source d'Android, récupéré avec l'outil repo et compilé par Soong à partir de fichiers Android.bp, les anciens Android.mk passant encore par Kati. lunch choisit une cible au format produit, configuration de release et variante, puis m construit l'image. Une compilation complète demande une machine puissante et plusieurs centaines de gigaoctets de disque.
Framework et services système
La couche Java du système : system_server et les services que les applications appellent à travers le SDK, comme ActivityManager ou PackageManager. Ajouter ou modifier un service système touche aux API, aux permissions et aux tests de compatibilité.
Binder et AIDL
Le mécanisme de communication entre processus d'Android. Les interfaces s'écrivent en AIDL, avec des versions figées (AIDL stable) quand elles traversent la frontière entre system et vendor. Une bonne part des blocages et des lenteurs du système se lit dans les transactions Binder.
HAL, Treble et VINTF
Les HAL font le lien entre le framework et les pilotes du fabricant. Depuis Treble, elles vivent sur la partition vendor, déclarées dans un manifeste VINTF et vérifiées par une matrice de compatibilité. HIDL est déprécié, et les nouvelles HAL s'écrivent en AIDL, en C++, en Java ou en Rust.
SELinux
Chaque processus tourne dans un domaine SELinux en mode enforcing, et tout accès non prévu est refusé. Un nouveau service ou une nouvelle HAL demande ses propres règles (fichiers .te, file_contexts, service_contexts). Les refus apparaissent dans les journaux sous la forme « avc: denied ».
init, partitions et noyau GKI
init lance les services décrits dans des fichiers .rc et gère les propriétés système. L'image se découpe en partitions (system, vendor, product, odm, boot), souvent dynamiques, avec des mises à jour A/B. Le noyau suit le modèle GKI : un noyau générique de Google et des modules du fabricant.
Android Automotive OS
La version d'Android qui tourne sur l'écran central des véhicules. La VHAL expose les propriétés du véhicule (vitesse, climatisation, sièges), en AIDL depuis Android 13, et CarService les transmet aux applications avec des permissions dédiées. Les offres citent aussi le multi-utilisateur et les restrictions pendant la conduite.
CTS, VTS, Perfetto et Cuttlefish
CTS vérifie que les API se comportent comme Google l'exige, VTS teste les HAL et le noyau. Le diagnostic passe par logcat, dmesg, dumpsys, les bugreports et les traces Perfetto. Cuttlefish, l'appareil virtuel de Google, permet de tester une image sans matériel.
Le poste couvre plus ou moins de couches selon l'équipe. Certains développeurs restent dans le framework Java et les applications système privilégiées. D'autres descendent dans les HAL en C++ et travaillent avec l'équipe BSP sur le noyau et les pilotes. L'intégrateur système passe ses journées dans le build, les partitions, SELinux et les campagnes CTS. Sur Android Automotive OS, la VHAL et les contraintes de démarrage rapide s'ajoutent. Précisez dans l'offre la couche principale, la version d'Android ciblée et le matériel, car un candidat solide sur le framework peut n'avoir jamais écrit de HAL, et l'inverse est fréquent.
Six domaines à couvrir dans l'entretien AOSP
- Build AOSP et Soong
- Framework et services système
- Binder, AIDL et HAL
- SELinux et sécurité de la plateforme
- Démarrage, partitions et mises à jour
- Android Automotive et VHAL
Les questions AOSP à poser, avec ce qu'une bonne réponse contient
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · senior
Vous ajoutez une HAL pour un capteur propriétaire. Comment définissez-vous l'interface, et comment le framework trouve-t-il le service ?
Une bonne réponseUne interface AIDL marquée @VintfStability, déclarée dans un module aidl_interface de l'Android.bp avec la stabilité vintf et un backend NDK pour l'implémentation C++. Le service s'enregistre auprès de servicemanager sous le nom d'instance déclaré dans le manifeste VINTF de la partition vendor, et la matrice de compatibilité le référence. La version est figée avant livraison, et une nouvelle méthode s'ajoute dans une nouvelle version au lieu de modifier l'ancienne. Il prévoit les règles SELinux du service et un test VTS.
Signal d'alerteUne HAL HIDL pour un nouveau développement, ou une interface modifiée sans gestion de version.
Question 2 · confirmé
Votre nouveau démon natif fonctionne quand SELinux est en mode permissive, mais échoue en enforcing avec des messages « avc: denied ». Comment écrivez-vous la politique ?
Une bonne réponseIl lit chaque refus : domaine source (scontext), type cible (tcontext), classe et permission. Il crée un domaine pour le démon dans un fichier .te, une transition à l'exécution grâce au type du binaire dans file_contexts, des types pour ses fichiers et pour son service Binder, puis n'accorde que les permissions nécessaires en s'appuyant sur les macros existantes. audit2allow aide à lire les refus, sa sortie ne se colle pas telle quelle. Si une règle neverallow bloque, c'est la conception qui doit changer.
Signal d'alerteLe domaine laissé en permissive, ou la sortie d'audit2allow copiée en bloc, avec des droits bien plus larges que le besoin.
Question 3 · junior à confirmé
Vous avez modifié un fichier du framework. Comment le testez-vous sur l'appareil sans reconstruire et reflasher toute l'image ?
Une bonne réponseAprès source build/envsetup.sh et lunch, il reconstruit le seul module concerné (m avec le nom du module, ou mm dans son dossier), puis pousse le résultat avec adb sync sur une partition remontée en écriture (adb root et adb remount sur un build userdebug, vérification dm-verity désactivée), et redémarre le framework ou l'appareil. Il connaît les limites : certaines modifications de ressources ou de partitions imposent un flash.
Signal d'alerteUne compilation complète à chaque modification, ou aucune idée de ce qu'est un build userdebug.
Question 4 · senior
Un appel Binder du framework vers votre service bloque system_server pendant plusieurs secondes. Comment trouvez-vous la cause, et que changez-vous ?
Une bonne réponseIl récupère les piles des threads avec un bugreport ou debuggerd et lit les traces ANR ou watchdog, puis repère le thread Binder bloqué et la transaction en attente, avec une trace Perfetto qui inclut les événements Binder. Les corrections : une méthode oneway pour une simple notification, le travail long sorti du thread Binder vers un thread dédié, aucun verrou tenu pendant un appel sortant. Il sait que le watchdog de system_server redémarre le framework si un thread surveillé reste bloqué trop longtemps.
Signal d'alerteLe délai du watchdog augmenté, ou le blocage déplacé dans un autre thread sans en comprendre la cause.
Question 5 · confirmé
Une application Android Automotive doit afficher la température extérieure. Quel chemin suit la donnée, du réseau du véhicule à l'écran ?
Une bonne réponseUn calculateur publie la valeur sur le réseau du véhicule (CAN ou autre), une couche du fabricant la reçoit et l'implémentation de la VHAL la publie comme propriété, ENV_OUTSIDE_TEMPERATURE. CarService s'abonne à la VHAL, et l'application lit la propriété avec CarPropertyManager après avoir obtenu la permission correspondante. Il parle du mode de changement (continu avec une fréquence d'échantillonnage, ou à chaque changement), des zones (areaId) et du cas où la propriété est indisponible.
Signal d'alerteUne application qui lirait directement le bus CAN, ou aucune notion de CarService.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Recruter un profil plateforme Android, vos questions
Quels profils réussissent le passage vers la plateforme Android ?
Deux origines reviennent. Les ingénieurs Linux embarqué, qui connaissent le noyau, les pilotes et la compilation croisée, doivent apprendre Binder, Treble et le framework. Les développeurs d'applications Android connaissent les API et Java ou Kotlin, mais découvrent le C++, SELinux et le build. Pour une HAL, le premier profil part avec de l'avance ; pour un service du framework ou une application système, le second. Évaluez la couche du poste, pas le titre du CV.
Quel langage domine sur un poste AOSP ?
Le framework est en Java, avec un peu de Kotlin dans les applications système récentes. Les HAL, les démons natifs et une partie des services sont en C++. Rust progresse dans AOSP, surtout pour les composants sensibles à la sécurité, sans être exigé dans la plupart des offres. Un développeur plateforme lit ces trois langages et écrit couramment au moins Java et C++, plus le shell et le Python des outils de build.
Comment organiser un test technique sans donner accès à vos sources ?
Partez d'AOSP public. Donnez un extrait de fichier .te et trois refus « avc: denied » à corriger, une interface AIDL à faire évoluer sans casser la version précédente, ou un extrait de bugreport à analyser. Ce test technique tient en une heure sur papier ou sur écran partagé, sans compiler d'image. Il montre si la personne a déjà travaillé sur une vraie plateforme, et vous n'exposez aucun code propriétaire.
L'expérience Android Automotive se transfère-t-elle à d'autres appareils ?
En grande partie. La VHAL et CarService sont propres à Android Automotive OS, mais le reste du travail est le même sur tout appareil Android : build, HAL AIDL, SELinux, init, mises à jour, CTS. Un profil Automotive arrive avec l'habitude des contraintes de démarrage et du multi-utilisateur. Dans l'autre sens, un développeur plateforme sans expérience Automotive prend vite en main la VHAL s'il maîtrise déjà les HAL AIDL.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
