Android 16 en 2026 : Nouvelles APIs, Desktop Mode et Questions d'Entretien

Android 16 (API level 36, nom de code "Baklava") constitue l'une des mises à jour les plus structurantes de la plateforme depuis le redesign Material You d'Android 12. Lancée en version stable le 10 juin 2025, cette version équipe désormais plus de 21% des appareils actifs en mars 2026, ce qui en fait la version Android la plus déployée. Pour les développeurs Android préparant des entretiens techniques en 2026, la maîtrise de ces changements d'API est incontournable.

Modèle de release SDK d'Android 16 : stratégie Major-Minor

Android 16 introduit une structure de release duale qui transforme la planification d'adoption des fonctionnalités. Le SDK majeur a été livré avec la Beta 3 en mars 2025, verrouillant les changements de comportement et les APIs principales. Un second SDK mineur a suivi le 2 décembre 2025, ajoutant de nouvelles APIs sans modifier le comportement de la plateforme.

Cette séparation est fondamentale en entretien : la release majeure concentre les changements de compatibilité (edge-to-edge, enforcement d'orientation), tandis que la release mineure fournit de nouvelles capacités (bibliothèques Jetpack supplémentaires, APIs liées à l'IA) sans impact sur le comportement existant des applications. Google a conçu ce modèle pour accélérer la livraison d'APIs tout en offrant aux équipes enterprise une cible annuelle stable et prévisible pour la conformité.

Une question fréquente en entretien porte sur la distinction entre targetSdkVersion et compileSdkVersion dans le contexte de ce modèle dual. La réponse : targetSdkVersion = 36 déclenche tous les changements de comportement de la release majeure. Le SDK mineur est purement additif — il ne nécessite aucun opt-in ni mise à jour de target.

Enforcement Edge-to-Edge sur API 36

Les applications ciblant Android 16 ne peuvent plus désactiver les layouts edge-to-edge. Le système ignore les appels à setDecorFitsSystemWindows(true) et les flags de visibilité SystemUI hérités. Chaque application doit gérer correctement les window insets, sous peine de voir des éléments d'interface masqués derrière la barre de statut et la barre de navigation.

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // enableEdgeToEdge() is now the default on API 36+
        // No opt-out available
        enableEdgeToEdge()
        setContent {
            Scaffold(
                modifier = Modifier.fillMaxSize()
            ) { innerPadding ->
                // innerPadding accounts for system bars
                MainContent(
                    modifier = Modifier.padding(innerPadding)
                )
            }
        }
    }
}

Le composant Scaffold de Jetpack Compose gère automatiquement les insets via innerPadding. Pour les applications basées sur le système de Views, ViewCompat.setOnApplyWindowInsetsListener reste l'approche recommandée. Le point critique : WindowInsetsCompat.Type.systemBars() doit être consommé explicitement, sinon le système applique un padding par défaut qui peut ne pas correspondre au design de l'application.

Les recruteurs demandent souvent ce qui se passe pour les applications qui s'appuyaient sur android:fitsSystemWindows="true" dans les layouts XML. Sur l'API 36, cet attribut fonctionne toujours mais applique uniquement du padding pour les barres système — il n'empêche plus l'application de dessiner en edge-to-edge.

Applications adaptatives et changements d'orientation sur grands écrans

Android 16 ignore android:screenOrientation et android:resizeableActivity="false" pour les applications non-jeu sur les écrans avec smallestWidth >= 600dp. Les tablettes, les pliables et les moniteurs externes connectés via le Desktop Mode sont tous concernés. Cela met fin à des années de layouts téléphone letterboxés sur grands écrans.

// Responsive layout using WindowSizeClass
@Composable
fun AdaptiveLayout() {
    val windowSizeClass = currentWindowAdaptiveInfo().windowSizeClass
    when {
        windowSizeClass.windowWidthSizeClass == 
            WindowWidthSizeClass.EXPANDED -> {
            // Two-pane layout for tablets/desktop
            TwoPaneLayout()
        }
        windowSizeClass.windowWidthSizeClass == 
            WindowWidthSizeClass.MEDIUM -> {
            // Adapted layout for foldables
            MediumLayout()
        }
        else -> {
            // Phone layout
            CompactLayout()
        }
    }
}

La bibliothèque Jetpack WindowManager fournit WindowSizeClass pour le design responsive. Une option de désinscription était disponible pour les applications ciblant spécifiquement l'API 36, mais Android 17 (prévu Q2 2026) supprime cette désinscription définitivement.

Les recruteurs formulent souvent la question ainsi : "Comment migreriez-vous une application verrouillée en orientation portrait pour supporter les grands écrans ?" La réponse implique de remplacer l'orientation fixe par des layouts responsifs, de tester les changements de configuration (notamment onConfigurationChanged), et de vérifier que l'état sauvegardé survit aux transitions de taille d'écran.

Desktop Mode et écrans connectés

Le Desktop Mode est disponible en tant que fonctionnalité GA dans Android 16 QPR3 (mars 2026 Pixel Drop), supportant les Pixel 8+ et les appareils Samsung Galaxy S26/Fold7/Flip7. Connecter un téléphone à un moniteur externe via USB-C lance une session bureau indépendante avec une barre des tâches, des fenêtres redimensionnables, des bureaux virtuels multiples, et un support complet clavier/souris.

fun launchOnExternalDisplay(context: Context) {
    val displayManager = context.getSystemService(
        Context.DISPLAY_SERVICE
    ) as DisplayManager
    // Find external displays
    val externalDisplays = displayManager.displays.filter {
        it.displayId != Display.DEFAULT_DISPLAY
    }
    if (externalDisplays.isNotEmpty()) {
        val options = ActivityOptions.makeBasic().apply {
            launchDisplayId = externalDisplays.first().displayId
        }
        context.startActivity(
            Intent(context, DesktopActivity::class.java),
            options.toBundle()
        )
    }
}

Le téléphone et l'écran externe fonctionnent indépendamment — les applications sont spécifiques à l'écran sur lequel elles s'exécutent. Google et Samsung ont collaboré sur l'expérience de fenêtrage bureau pour réduire la fragmentation dans l'écosystème. Samsung DeX intègre les mêmes APIs de plateforme, créant une cible développeur unifiée.

Considérations clés pour le Desktop Mode :

• Les métriques de fenêtre changent dynamiquement. Ne jamais mettre en cache les objets Display. Interroger WindowMetricsCalculator ou LocalConfiguration de Compose à chaque changement de configuration.
• Support clavier et souris. Les périphériques externes sont la norme en session bureau. Gérer le dispatch de KeyEvent et les états de survol du pointeur.
• Support multi-instance. Les utilisateurs bureau s'attendent à plusieurs fenêtres de la même application. Déclarer android:documentLaunchMode="intoExisting" ou gérer FLAG_ACTIVITY_NEW_DOCUMENT de manière appropriée.

Notifications ProgressStyle et mises à jour en temps réel

Android 16 introduit Notification.ProgressStyle, un nouveau template de notification pour les parcours utilisateur centrés sur la progression comme le suivi de livraisons, les mises à jour de commandes et la navigation. Cela remplace les layouts de notification personnalisés ad hoc par un format standardisé et promu par le système.

fun buildDeliveryNotification(
    context: Context,
    orderId: String,
    progress: Float,  // 0.0 to 1.0
    currentStep: String
): Notification {
    val style = Notification.ProgressStyle()
        .setStyledByProgress(true)
        .setProgress(progress)
        .setProgressTrackerIcon(
            Icon.createWithResource(context, R.drawable.ic_delivery_truck)
        )
        .addProgressSegment(
            Notification.ProgressStyle.Segment(0.33f)
                .setColor(context, R.color.segment_preparing)
        )
        .addProgressSegment(
            Notification.ProgressStyle.Segment(0.33f)
                .setColor(context, R.color.segment_in_transit)
        )
        .addProgressSegment(
            Notification.ProgressStyle.Segment(0.34f)
                .setColor(context, R.color.segment_delivered)
        )
        .addProgressPoint(
            Notification.ProgressStyle.Point(0.0f)
                .setLabel("Order placed")
        )
        .addProgressPoint(
            Notification.ProgressStyle.Point(0.33f)
                .setLabel("Preparing")
        )
        .addProgressPoint(
            Notification.ProgressStyle.Point(0.66f)
                .setLabel("In transit")
        )
        .addProgressPoint(
            Notification.ProgressStyle.Point(1.0f)
                .setLabel("Delivered")
        )

    return Notification.Builder(context, DELIVERY_CHANNEL_ID)
        .setSmallIcon(R.drawable.ic_notification)
        .setContentTitle("Order #$orderId")
        .setContentText(currentStep)
        .setStyle(style)
        .setOngoing(true)
        .build()
}

ProgressStyle supporte les segments (sections colorées de la barre de progression), les points (jalons étiquetés) et une icône de suivi qui se déplace le long de la barre. L'activation de setStyledByProgress(true) permet au système de colorer les segments en fonction de l'avancement. Pour la préparation aux entretiens sur les notifications Android, comprendre quand utiliser ProgressStyle plutôt qu'une notification setProgress() standard est essentiel : ProgressStyle convient aux parcours multi-étapes avec des jalons distincts, tandis que setProgress() reste approprié pour les opérations à tâche unique comme les téléchargements de fichiers.

Navigation prédictive avec OnBackInvokedCallback

Android 16 achève la migration pluriannuelle de onBackPressed() vers l'API OnBackInvokedCallback. Le système affiche désormais une animation de "peek" de l'écran de destination pendant le geste retour, permettant aux utilisateurs de confirmer ou annuler. Les applications qui surchargent encore onBackPressed() sans enregistrer de callback cassent cette animation.

class DetailActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        if (Build.VERSION.SDK_INT >= 36) {
            onBackInvokedDispatcher.registerOnBackInvokedCallback(
                OnBackInvokedDispatcher
                    .PRIORITY_SYSTEM_NAVIGATION_OBSERVER
            ) {
                // Observe back navigation without intercepting
                // Log analytics or trigger save-draft logic
                analyticsTracker.logBackNavigation(
                    screen = "detail"
                )
            }
        }
    }
}

La nouvelle priorité PRIORITY_SYSTEM_NAVIGATION_OBSERVER permet aux applications d'observer les événements retour sans bloquer l'animation système. Android 16 ajoute également finishAndRemoveTaskCallback et moveTaskToBackCallback pour les comportements de back-stack personnalisés qui s'intègrent toujours avec l'animation prédictive.

La navigation prédictive fonctionne aussi sur la navigation 3 boutons dans Android 16 : un appui long sur le bouton retour déclenche la même animation de prévisualisation que la navigation gestuelle. C'est un sujet fréquent en entretien — les candidats qui ne mentionnent que la navigation gestuelle passent à côté de la moitié de la réponse.

Notification Cooldown et regroupement obligatoire

Deux changements supplémentaires de notification affectent toutes les applications Android. Le cooldown de notification réduit le volume d'alertes pour les notifications rapides d'une même application, en diminuant progressivement le niveau sonore sur environ 60 secondes avant réinitialisation. Cette fonctionnalité est activée par défaut et ne peut pas être désactivée par les développeurs.

Le regroupement obligatoire des notifications signifie que le système regroupe désormais automatiquement les notifications, que l'application utilise setGroup() ou non. Les applications qui comptaient sur la proéminence individuelle des notifications pour l'engagement devront repenser leur stratégie de notification.

APIs Health Connect FHIR et RangingManager

Android 16 étend Health Connect avec le support d'écriture FHIR (Fast Healthcare Interoperability Resources), permettant aux applications de santé de créer et stocker des dossiers médicaux structurés. L'API RangingManager unifie la mesure de distance/angle à travers BLE channel sounding, BLE RSSI, Ultra-Wideband et Wi-Fi RTT — consolidant ce qui nécessitait auparavant quatre surfaces d'API distinctes.

Le sélecteur de photos gagne des APIs de personnalisation plus poussées, permettant aux développeurs de contrôler l'apparence du sélecteur tout en maintenant le même modèle de sécurité sandboxé. La recherche dans les fournisseurs de médias cloud a été ajoutée dans la Developer Preview 2.

Ces APIs ont moins de chances d'apparaître dans les entretiens Android généraux mais sont critiques pour les postes spécialisés en santé, IoT ou applications média.

Questions et réponses d'entretien Android 16

Q : Quels sont les changements de comportement obligatoires lors du ciblage de l'API 36 ? Trois changements sont imposés : le rendu edge-to-edge (sans opt-out), les restrictions d'orientation/redimensionnement ignorées sur les écrans >= 600dp, et la navigation prédictive activée à l'échelle du système. Les applications doivent gérer correctement les WindowInsets, supporter les layouts responsifs et migrer de onBackPressed() vers OnBackInvokedCallback.

Q : Comment le Desktop Mode affecte-t-il l'architecture d'une application ? Le Desktop Mode crée une session d'affichage indépendante. Les applications doivent éviter de mettre en cache les objets Display, supporter les métriques de fenêtre dynamiques, gérer les entrées clavier/souris et considérer les scénarios multi-instance. L'API ActivityOptions.launchDisplayId permet de cibler des écrans spécifiques programmatiquement.

Q : Quand ProgressStyle devrait-il remplacer setProgress() ? ProgressStyle est destiné aux parcours utilisateur multi-étapes avec des jalons distincts (covoiturage, livraison, navigation). Le setProgress() standard reste approprié pour les progressions à opération unique (téléchargement, upload). ProgressStyle bénéficie d'une visibilité promue dans le tiroir de notifications.

Q : Qu'est-ce que le modèle de release SDK major/minor d'Android 16 ? La release majeure (mars 2025) contient les changements de comportement et nécessite une mise à jour de targetSdkVersion. La release mineure (décembre 2025) ajoute de nouvelles APIs sans changement de comportement — aucune mise à jour de targetSdkVersion nécessaire. Cela découple la stabilité de l'innovation.

Q : Comment fonctionne la navigation prédictive avec la navigation 3 boutons ? Sur API 36+, un appui long sur le bouton retour de la navigation 3 boutons déclenche la même animation prédictive que la navigation gestuelle. Les applications doivent enregistrer un OnBackInvokedCallback avec la priorité appropriée. La priorité PRIORITY_SYSTEM_NAVIGATION_OBSERVER permet d'observer sans intercepter.

Conclusion

• Le edge-to-edge n'est plus optionnel sur l'API 36. Auditer tous les écrans pour une gestion correcte des WindowInsets, en particulier les barres d'outils personnalisées et les bottom sheets.
• Remplacer les manifestes à orientation fixe par des layouts responsifs Jetpack Compose utilisant WindowSizeClass avant qu'Android 17 ne supprime l'option de désinscription.
• Le Desktop Mode est prêt pour la production sur Pixel 8+ et les flagships Samsung. Tester les applications avec des écrans externes, la saisie clavier et les scénarios multi-instance.
• Migrer de onBackPressed() vers OnBackInvokedCallback. Utiliser PRIORITY_SYSTEM_NAVIGATION_OBSERVER pour le suivi analytics sans bloquer les animations système.
• Adopter Notification.ProgressStyle pour tout parcours utilisateur multi-étapes. Le cooldown de notification et le regroupement obligatoire affectent toutes les applications indépendamment du SDK cible.
• Le modèle SDK major/minor signifie que les changements de comportement arrivent une fois par an. Le SDK mineur apporte de nouvelles APIs sans risque de compatibilité — les adopter librement.