Il cambiamento importante riguarda il formato, non una promessa di compatibilità universale
Galaxy Z Fold8 è stato presentato il 22 luglio 2026. Nella guida per sviluppatori pubblicata lo stesso giorno, Google mette in evidenza una caratteristica con conseguenze dirette sul software: il telefono introduce uno schermo principale ultrawide il cui orientamento naturale è orizzontale. La raccomandazione non consiste nell’aggiungere una versione speciale per un singolo modello, ma nell’abbandonare presupposti rigidi su orientamento e proporzioni. Agli sviluppatori viene chiesto, in sostanza, di considerare il comportamento di un’app al variare della configurazione dello schermo, invece di assumere che il tradizionale layout verticale sia l’unico punto di partenza possibile. (Android Developers Blog)
Samsung descrive Fold8 come dotato di uno schermo principale con proporzioni 4:3, che si può ruotare per leggere, e di uno schermo esterno 10:16. La stessa app deve quindi affrontare due contesti distinti: una superficie esterna stretta e una superficie interna più ampia. Le informazioni disponibili consentono di parlare di una nuova sfida di progettazione; da sole, però, non dimostrano che tutte le app funzioneranno male né che ciascuna richieda una ricostruzione completa. La questione pratica è come un’interfaccia esistente reagisca quando l’utente passa da una superficie all’altra e se contenuti e comandi riescano ad adattarsi allo spazio realmente disponibile. Le proporzioni spiegano perché gli sviluppatori debbano considerare più di un layout, ma non provano l’esistenza di un problema di compatibilità universale. (Samsung Newsroom)
Prima di tutto, progettare per lo spazio disponibile nell’app
Google consiglia di far rispondere l’interfaccia prima alla larghezza disponibile e poi di considerare l’altezza. In una finestra ampia può essere utile mostrare contemporaneamente più colonne, pannelli o contenuti; quando lo spazio si riduce, questi elementi possono essere riordinati, ridimensionati o disposti in un altro modo. Il punto fondamentale è consentire al layout di redistribuirsi, anziché dipendere da coordinate o dimensioni fisse. Questo non significa che ogni schermata debba mostrare sempre la stessa quantità di informazioni. Significa che la disposizione può cambiare in modo intenzionale mentre cambia la finestra dell’app, così che contenuti e comandi restino utilizzabili invece di essere semplicemente compressi in un layout pensato per una forma diversa. (Android Developers Blog)
È inoltre importante distinguere le dimensioni fisiche dello schermo dallo spazio occupato dalla finestra dell’app. In modalità schermo diviso o in altri contesti multitasking, un’app può ricevere solo una parte del pannello e la sua finestra può persino avere un orientamento diverso da quello del dispositivo. Google indica Window Size Classes e Jetpack WindowManager come strumenti per identificare lo spazio effettivo e le caratteristiche della finestra. L’interfaccia può così reagire alle condizioni reali, anziché a un’ipotesi basata sulle dimensioni complessive del telefono. La distinzione conta anche per l’utente: uno schermo grande non significa che ogni app abbia sempre a disposizione l’intero pannello. Dimensioni e orientamento della finestra, insieme al modo in cui l’utente organizza le app, determinano lo spazio in cui l’interfaccia deve funzionare. (Android Developers Blog)
Pieghe, cambi di postura e continuità
Su un pieghevole, passare dalla posizione chiusa a quella aperta modifica la configurazione ricevuta dall’app. Le raccomandazioni adattive di Android chiedono di considerare questi stati, oltre agli orientamenti verticale e orizzontale, alla modalità multi-finestra e alle preferenze dell’utente. Per i layout che attraversano l’area della cerniera, Jetpack WindowManager fornisce informazioni su pieghe e cerniere: un’app può evitare di collocare contenuti importanti in quell’area oppure usarla come separazione tra pannelli. La cerniera diventa così un elemento da considerare nel layout, non un semplice dettaglio fisico. La scelta dipende dall’interfaccia: si può tenere il contenuto lontano dalla piega oppure collocare parti distinte dell’app ai suoi lati, quando ha senso farlo. (Android Developers)
Google consiglia anche di conservare lo stato dell’interfaccia durante questi cambiamenti, per esempio tramite ViewModel, così che l’utente non perda il contesto quando apre o chiude il dispositivo. È una linea guida per lo sviluppo, non una descrizione di ciò che qualsiasi app installata fa automaticamente. In pratica, quando cambia la configurazione dello schermo, l’attività in corso, la selezione o il punto di lettura dovrebbero essere mantenuti, se l’app lo consente. La qualità di questa continuità dipende da come è costruita ciascuna applicazione. Un pieghevole può modificare il layout disponibile senza che l’utente voglia ricominciare; un’app preparata dovrebbe quindi considerare quali informazioni devono sopravvivere alla transizione. La raccomandazione non dimostra che tutte le app conservino già il proprio stato, né significa che la piattaforma possa fornire al posto loro una continuità non implementata. (Android Developers Blog)
Android 17 elimina una via d’uscita per le app destinate agli schermi grandi, ma non ne ridisegna le interfacce
Android 17 introduce un cambiamento rilevante per le app che puntano al livello API 37: non è più disponibile l’opzione per escludersi dalle regole Android che ignorano i vincoli di orientamento, proporzioni e ridimensionamento sugli schermi grandi, larghi almeno 600 dp. Google spiega che queste regole erano già state introdotte in Android 16 per le app con livello API 36 o superiore. Il cambiamento riguarda il modo in cui l’app reagisce alle dimensioni e all’orientamento della finestra; da solo, non crea un’interfaccia adattiva. In altre parole, per le app interessate il sistema può non applicare più certi vincoli allo stesso modo, ma questo comportamento è distinto dal lavoro necessario per disporre bene i contenuti dell’app. (Android Developers)
Per questo è utile distinguere una regola del sistema dal lavoro di progettazione. Android può consentire di ridimensionare un’app o mostrarla in un orientamento diverso da quello che imponeva prima, ma non riordina per magia pulsanti, elenchi o pannelli per renderli comodi da usare. La documentazione di Google propone come pratica temporanea una strategia che limita la modalità verticale sugli schermi compatti e consente l’orientamento scelto dall’utente sugli schermi da 600 dp in su. La guida la presenta come un passaggio circoscritto, non come un sostituto del supporto completo. Gli sviluppatori devono comunque verificare l’aspetto e il funzionamento dell’interfaccia nelle configurazioni permesse dal sistema. Un cambiamento nel comportamento della piattaforma può mettere in evidenza i punti deboli di un layout, ma non equivale a un ridisegno automatico né garantisce che ogni comando si trovi nel posto giusto. (Android Developers)
Fotocamera: un’altra prova di adattamento, distinta dall’interfaccia generale
La guida di Google tratta separatamente la cattura con la fotocamera. Passando da uno schermo esterno compatto a uno interno più ampio, cambiano le proporzioni dell’area di anteprima anche se l’orientamento del dispositivo non cambia necessariamente. Un’implementazione che presuppone un rapporto fisso tra sensore e schermo può mostrare un’anteprima ruotata, deformata o ritagliata. Google consiglia CameraX per le nuove implementazioni e cita PreviewView come supporto per gestire orientamento del sensore, rotazione e ridimensionamento. È un esempio specifico del motivo per cui non sempre basta controllare l’interfaccia generale: l’anteprima della fotocamera ha una geometria propria e deve adattarsi alla superficie su cui viene visualizzata. (Android Developers Blog)
Per i progetti esistenti che usano Camera2, lo stesso articolo indica CameraViewfinder come alternativa per applicare trasformazioni di proporzioni e rotazione senza ricostruire l’intera architettura. Sono indicazioni rivolte a chi sviluppa o mantiene le app; non implicano che il sistema possa correggere tutti i problemi software della fotocamera nelle app di terze parti. Quando si valuta un’app fotografica su un pieghevole, è quindi utile osservare l’inquadratura e il passaggio da uno schermo all’altro, anziché dedurre una compatibilità completa dal solo fatto che l’app si apra. L’avvio è soltanto un segnale visibile. L’anteprima potrebbe comunque reagire male al cambiamento dello spazio disponibile; inoltre, gli strumenti citati sono raccomandazioni per lo sviluppo, non la garanzia che un’app li utilizzi già. (Android Developers Blog)
Che cosa può verificare l’utente e quali sono i limiti
Per l’utente, un controllo utile consiste nell’aprire un’app sullo schermo esterno, aprire il telefono, ruotarlo e, se l’app lo consente, provare lo schermo diviso. Conviene osservare se i contenuti si riordinano, se compaiono barre o aree vuote, se i comandi restano accessibili e se l’attività prosegue dopo il cambiamento. Nelle app di lettura, video o fotocamera, è importante anche verificare che il formato dei contenuti e l’anteprima non vengano ritagliati in modo imprevisto. Sono segnali osservabili, non una certificazione tecnica né il risultato di prove condotte per questo articolo. Provare configurazioni diverse può mostrare il comportamento di un’app nell’uso quotidiano, ma non dimostra che supporti ogni possibile dimensione di finestra o postura. Il controllo è utile proprio perché si concentra su ciò che si può vedere senza attribuirgli un valore maggiore.
L’annuncio di Google offre indicazioni per gli sviluppatori e strumenti della piattaforma; non pubblica una verifica di compatibilità delle singole app. Non consente neppure di concludere che Galaxy Z Fold8 obblighi a ridisegnare ogni app o che Android 17 garantisca un’esperienza ottimale in tutte. La tesi verificabile è più circoscritta: i formati orientati in orizzontale e le finestre variabili rendono più importante adattare l’interfaccia allo spazio disponibile, e Android 17 limita un’eccezione sull’orientamento per le app che puntano all’API 37 o successiva. La differenza tra accettare una configurazione e progettare bene per essa continuerà a dipendere da ciascuno sviluppatore. Gli utenti possono osservare tale differenza, ma le indicazioni non certificano il comportamento di una particolare applicazione. (Android Developers Blog)