Android 16 nel 2026: Nuove API, Modalità Desktop e Domande per i Colloqui

Android 16 (API level 36, nome in codice "Baklava") rappresenta uno degli aggiornamenti di piattaforma più significativi dall'introduzione di Material You con Android 12. Rilasciato come versione stabile il 10 giugno 2025, a marzo 2026 è già in esecuzione su oltre il 21% dei dispositivi attivi, il che lo rende la singola versione di Android più diffusa al mondo. Per gli sviluppatori Android che si preparano ai colloqui tecnici nel 2026, la conoscenza approfondita di queste modifiche alle API è un requisito imprescindibile.

Il modello di rilascio SDK di Android 16: strategia Major e Minor

Android 16 introduce una struttura a doppio rilascio che cambia radicalmente il modo in cui gli sviluppatori pianificano l'adozione delle funzionalità. L'SDK major è stato distribuito con la Beta 3 nel marzo 2025, consolidando le modifiche comportamentali e le API principali. Un secondo SDK minor è seguito il 2 dicembre 2025, aggiungendo nuove API senza alterare il comportamento della piattaforma.

Questa separazione è rilevante nei colloqui: il rilascio major contiene le modifiche che rompono la compatibilità (edge-to-edge, imposizione dell'orientamento), mentre il rilascio minor fornisce nuove funzionalità (librerie Jetpack aggiuntive, API legate all'intelligenza artificiale) con zero impatto sul comportamento esistente delle app. Google ha progettato questo modello per accelerare la distribuzione delle API, offrendo al contempo ai team enterprise un obiettivo annuale stabile e prevedibile per la conformità.

Una domanda frequente nei colloqui riguarda targetSdkVersion rispetto a compileSdkVersion nel contesto di questo modello duale. La risposta: targetSdkVersion = 36 attiva tutte le modifiche comportamentali del rilascio major. L'SDK minor è puramente additivo — non richiede alcun opt-in né aggiornamento del target.

Obbligo Edge-to-Edge su API 36

Le app che puntano ad Android 16 non possono più disattivare i layout edge-to-edge. Il sistema ignora le chiamate a setDecorFitsSystemWindows(true) e i flag di visibilità SystemUI legacy. Ogni app deve gestire correttamente i window insets, altrimenti rischia di avere elementi dell'interfaccia nascosti dietro la barra di stato e la barra di navigazione.

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)
                )
            }
        }
    }
}

Il composable Scaffold in Jetpack Compose gestisce automaticamente gli insets tramite innerPadding. Per le app basate su View, ViewCompat.setOnApplyWindowInsetsListener rimane l'approccio consigliato. Il dettaglio critico: WindowInsetsCompat.Type.systemBars() deve essere consumato esplicitamente, altrimenti il sistema applicherà un padding predefinito che potrebbe non corrispondere al design dell'app.

Nei colloqui tecnici viene spesso chiesto cosa succede alle app che si affidavano a android:fitsSystemWindows="true" nei layout XML. Su API 36, questo attributo funziona ancora ma applica solo il padding per le barre di sistema — non impedisce più all'app di disegnare edge-to-edge.

App Adattive e Cambiamenti di Orientamento su Schermi Grandi

Android 16 ignora android:screenOrientation e android:resizeableActivity="false" per le app non-gioco su display con smallestWidth >= 600dp. Tablet, foldable e monitor esterni collegati tramite la modalità desktop rientrano tutti in questa categoria. Questo pone fine ad anni di layout telefonici in letterbox su schermi grandi.

// 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 libreria Jetpack WindowManager fornisce WindowSizeClass per il design responsivo. Una proprietà di opt-out era disponibile specificamente per le app che puntavano all'API 36, tuttavia Android 17 (previsto per il Q2 2026) rimuoverà completamente questa possibilità.

Una domanda tipica nei colloqui è: "Come si migrerebbe un'app bloccata in orientamento portrait per supportare schermi grandi?" La risposta prevede la sostituzione dell'orientamento fisso con layout responsivi, il test delle modifiche di configurazione (in particolare onConfigurationChanged) e la verifica che lo stato salvato sopravviva alle transizioni di dimensione dello schermo.

Modalità Desktop e Display Esterni

La modalità desktop è stata rilasciata come funzionalità generalmente disponibile in Android 16 QPR3 (Pixel Drop di marzo 2026), con supporto per Pixel 8+ e dispositivi Samsung Galaxy S26/Fold7/Flip7. Collegando uno smartphone a un monitor esterno tramite USB-C si avvia una sessione desktop indipendente con barra delle applicazioni, finestre ridimensionabili, desktop virtuali multipli e supporto completo per tastiera e mouse.

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()
        )
    }
}

Lo smartphone e il display esterno operano in modo indipendente — le app sono specifiche per il display su cui vengono eseguite. Google e Samsung hanno collaborato sull'esperienza desktop per ridurre la frammentazione nell'ecosistema. Samsung DeX integra le stesse API della piattaforma, creando un obiettivo di sviluppo unificato.

Considerazioni fondamentali per gli sviluppatori riguardo alla modalità desktop:

• Le metriche delle finestre cambiano dinamicamente. Gli oggetti Display non devono mai essere memorizzati in cache. WindowMetricsCalculator o Compose LocalConfiguration devono essere interrogati ad ogni cambio di configurazione.
• Supporto tastiera e mouse. Le periferiche esterne sono la norma nelle sessioni desktop. È necessario gestire il dispatching di KeyEvent e gli stati hover del puntatore.
• Supporto multi-istanza. Gli utenti desktop si aspettano finestre multiple della stessa app. Occorre dichiarare android:documentLaunchMode="intoExisting" o gestire FLAG_ACTIVITY_NEW_DOCUMENT in modo appropriato.

Notifiche ProgressStyle e Aggiornamenti Live

Android 16 introduce Notification.ProgressStyle, un nuovo template di notifica per percorsi utente orientati al progresso come il tracciamento di corse, aggiornamenti sulle consegne e navigazione. Sostituisce i layout personalizzati delle notifiche con un formato standardizzato e promosso dal sistema.

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 supporta segmenti (sezioni colorate della barra di progresso), punti (milestone etichettati) e un'icona tracker che si muove lungo la barra. Impostando setStyledByProgress(true), il sistema colora i segmenti in base al completamento. Per la preparazione ai colloqui sulle notifiche Android, è essenziale comprendere quando utilizzare ProgressStyle rispetto a un setProgress() standard: ProgressStyle è pensato per percorsi multi-step con milestone distinti, mentre setProgress() rimane appropriato per operazioni singole come il download di file.

Navigazione Predittiva Back con OnBackInvokedCallback

Android 16 completa la migrazione pluriennale da onBackPressed() all'API OnBackInvokedCallback. Il sistema mostra ora un'animazione "peek" dello schermo di destinazione durante il gesto di ritorno, permettendo all'utente di confermare o annullare l'azione. Le app che continuano a sovrascrivere onBackPressed() senza registrare un callback interrompono questa animazione.

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 nuova priorità PRIORITY_SYSTEM_NAVIGATION_OBSERVER consente alle app di osservare gli eventi back senza bloccare l'animazione di sistema. Android 16 aggiunge inoltre finishAndRemoveTaskCallback e moveTaskToBackCallback per comportamenti personalizzati del back stack che si integrano comunque con l'animazione predittiva.

La navigazione predittiva back funziona anche con la navigazione a 3 pulsanti su Android 16: la pressione prolungata del tasto indietro avvia l'animazione di anteprima. Questo è un argomento frequente nei colloqui — i candidati che menzionano solo la navigazione a gesti raccontano solo metà della storia.

Cooldown delle Notifiche e Raggruppamento Obbligatorio

Due ulteriori modifiche alle notifiche influenzano ogni app Android. Il cooldown delle notifiche riduce il volume degli avvisi per le notifiche in rapida successione dalla stessa app, diminuendo gradualmente il livello sonoro nell'arco di circa 60 secondi prima del reset. Questa funzionalità è attivata per impostazione predefinita e non può essere sovrascritta dagli sviluppatori.

Il raggruppamento obbligatorio significa che il sistema raggruppa automaticamente le notifiche indipendentemente dall'uso di setGroup() da parte dell'app. Le app che facevano affidamento sulla prominenza individuale delle notifiche per l'engagement potrebbero dover ripensare la propria strategia di notifica.

Per la preparazione ai colloqui, queste modifiche si abbinano bene con domande sulle coroutine Kotlin e Flow, poiché il batch efficiente e il throttling delle notifiche spesso richiedono pattern di debouncing basati sulle coroutine.

API Health Connect FHIR e RangingManager

Android 16 espande Health Connect con il supporto alla scrittura FHIR (Fast Healthcare Interoperability Resources), consentendo alle app sanitarie di creare e archiviare cartelle cliniche strutturate. L'API RangingManager unifica le misurazioni di distanza e angolo attraverso BLE channel sounding, BLE RSSI, Ultra-Wideband e Wi-Fi RTT — consolidando quattro superfici API precedentemente separate.

Il selettore foto ottiene API di personalizzazione più profonde, che permettono agli sviluppatori di controllare l'aspetto del selettore mantenendo lo stesso modello di sicurezza sandboxed. La ricerca tramite cloud media provider è stata aggiunta nella Developer Preview 2.

Queste API hanno meno probabilità di comparire nei colloqui Android generici, ma sono fondamentali per ruoli specifici in ambito health tech, IoT o applicazioni ad uso intensivo di media.

Domande e Risposte sui Colloqui Android 16

Ecco le domande che più probabilmente emergeranno nei colloqui per sviluppatori Android nel 2026, basate sulle modifiche comportamentali e alle API trattate sopra.

D: Quali sono le modifiche comportamentali obbligatorie quando si punta all'API 36? Tre modifiche sono imposte: rendering edge-to-edge (nessun opt-out), restrizioni su orientamento/ridimensionabilità ignorate su schermi >= 600dp, e navigazione predittiva back attivata a livello di sistema. Le app devono gestire correttamente i WindowInsets, supportare layout responsivi e migrare da onBackPressed() a OnBackInvokedCallback.

D: Come influisce la modalità desktop sull'architettura dell'app? La modalità desktop crea una sessione display indipendente. Le app non devono memorizzare in cache gli oggetti Display, devono supportare metriche delle finestre dinamiche, gestire input da tastiera/mouse e considerare scenari multi-istanza. L'API ActivityOptions.launchDisplayId consente di puntare a display specifici in modo programmatico.

D: Quando ProgressStyle dovrebbe sostituire setProgress()? ProgressStyle è destinato a percorsi utente multi-step con milestone distinti (ride-sharing, consegna, navigazione). Il setProgress() standard rimane appropriato per operazioni singole (download di file, upload). ProgressStyle ottiene una visibilità promossa nel pannello delle notifiche.

D: Cos'è il modello di rilascio SDK major/minor di Android 16? Il rilascio major (marzo 2025) contiene le modifiche comportamentali e richiede un aggiornamento della targetSdkVersion. Il rilascio minor (dicembre 2025) aggiunge nuove API senza modifiche comportamentali — nessun bump della targetSdkVersion necessario. Questo separa la stabilità dall'innovazione.

D: Come funziona la navigazione predittiva back con la navigazione a 3 pulsanti? Su API 36+, la pressione prolungata del tasto indietro nella navigazione a 3 pulsanti attiva la stessa animazione predittiva della navigazione a gesti. Le app devono registrare OnBackInvokedCallback con la priorità appropriata. La priorità PRIORITY_SYSTEM_NAVIGATION_OBSERVER consente di osservare senza intercettare.

Conclusione

• L'edge-to-edge non è più opzionale su API 36. Tutti gli schermi devono essere verificati per la corretta gestione dei WindowInsets, in particolare toolbar personalizzate e bottom sheet.
• Le dichiarazioni di orientamento fisso nel manifest devono essere sostituite con layout responsivi in Jetpack Compose utilizzando WindowSizeClass, prima che Android 17 rimuova la possibilità di opt-out.
• La modalità desktop è pronta per la produzione su Pixel 8+ e dispositivi Samsung di punta. Le app devono essere testate con display esterni, input da tastiera e scenari multi-istanza.
• La migrazione da onBackPressed() a OnBackInvokedCallback è necessaria. PRIORITY_SYSTEM_NAVIGATION_OBSERVER è adatto per il tracking analitico senza bloccare le animazioni di sistema.
• Notification.ProgressStyle dovrebbe essere adottato per qualsiasi percorso utente multi-step. Il cooldown delle notifiche e il raggruppamento obbligatorio influenzano tutte le app indipendentemente dall'SDK target.
• Il modello SDK major/minor significa che le modifiche comportamentali arrivano una volta all'anno. L'SDK minor porta nuove API senza rischi di compatibilità — possono essere adottate liberamente.