Risposta rapida
Google Play richiede che le app che puntano ad Android 15 (livello API 35) o superiore supportino le pagine di memoria da 16 KB sui dispositivi a 64 bit, e dal 1º febbraio 2027 non potrai più pubblicare aggiornamenti che non lo fanno. Un’app scritta solo in Java o Kotlin, comprese tutte le sue librerie e SDK, è già conforme. Un’app che impacchetta librerie native .so fallisce finché ognuna di esse non viene ricompilata o sostituita, preferibilmente con Android Gradle Plugin 8.5.1+ e NDK r28+, e finché la build non supera due controlli distinti: ogni segmento ELF LOAD allineato ad almeno 2**14 e l’app bundle che riporta PAGE_ALIGNMENT_16K. Aggiornare il framework non è una prova; l’artefatto sì. Se risolvere questo avviso ha bloccato un test chiuso (closed testing) già in corso, PrimeTestLab tiene in piedi il lato tester mentre ricompili.
L’avviso è breve, al massimo nomina un file e arriva quando pensavi che la build fosse finita. Per questo si ripetono sempre le stesse tre svolte sbagliate: fidarsi di una scadenza che è cambiata, aggiornare un framework e dare per fatto il lavoro, oppure controllare un solo APK locale senza mai guardare il bundle da cui Google costruisce davvero. Questo articolo è organizzato nell’ordine in cui il problema si risolve sul serio: individuare, attribuire, riparare, dimostrare. Tutto quello che leggi è aggiornato al 5 agosto 2026 e verificato sulla guida di Google alle dimensioni delle pagine lo stesso giorno del suo ultimo aggiornamento. Dove la prova è l’issue tracker di un manutentore e non una nota di rilascio ufficiale, la scheda lo dichiara invece di arrotondarlo a fatto.
Il laboratorio di allineamento
Dodici strumenti costruiti per questo singolo errore. Nessuno richiede un account, un caricamento o una richiesta di rete: girano tutti nel tuo browser sui valori che digiti.
Sommario
Risolvilo in tre passaggi
Ogni soluzione reale a questo errore sono le stesse tre mosse nello stesso ordine: individua la libreria nativa non allineata, aggiorna la dipendenza che la contiene, poi verifica l’artefatto che stai per caricare. Saltare dritti al passaggio due è il motivo per cui tanti sviluppatori aggiornano un framework, ricompilano e vedono tornare l’avviso identico a prima.
Il requisito in sé è circoscritto. La guida di Google alle dimensioni delle pagine dice che le app che puntano ad Android 15 (livello API 35) o superiore devono supportare le pagine di memoria da 16 KB sui dispositivi a 64 bit, e che dal 1º febbraio 2027 non potrai più pubblicare aggiornamenti che non lo fanno. Vale solo per il codice nativo. Se la tua app e ogni libreria e SDK al suo interno sono puro Java o Kotlin, Google afferma che la tua app supporta già i dispositivi a 16 KB. Il problema è che la maggior parte di chi vede questo avviso crede di rientrare in quella categoria e non ci rientra.
Individua il .so difettoso
Apri l’APK di rilascio in Android Studio con Build > Analyze APK..., espandi lib/arm64-v8a e lib/x86_64 e leggi la colonna Alignment. Annota ogni nome file segnalato. Quei nomi sono le uniche chiavi di ricerca affidabili che hai.
Aggiorna chi lo contiene
Un binario che hai compilato tu si sistema con la tua toolchain: AGP 8.5.1 o successivo con NDK r28 o successivo. Un binario arrivato dentro un plugin, un SDK, un motore o un AAR può essere sistemato solo da chi lo ha costruito, quindi l’azione è aggiornare, sostituire o chiedere un artefatto ricompilato a quel pacchetto.
Trova la via più breve per il tuo frameworkVerifica l’artefatto, non l’aggiornamento
Devono passare due controlli indipendenti. Ogni segmento ELF LOAD deve essere allineato a 2**14 o più, e bundletool deve riportare PAGE_ALIGNMENT_16K per il bundle di rilascio. Passarne uno non dimostra nulla sull’altro.
Tutta la decisione, in una schermata
Prima di cambiare una singola versione di dipendenza, percorri questo schema. Richiede circa due minuti ed è la differenza tra sistemare la cosa giusta e aggiornare undici pacchetti che non c’entravano nulla.
L’APK di rilascio contiene una cartella lib con file .so?
Già conforme
Nessun codice nativo nell’APK. Google afferma che un’app solo Java o Kotlin, comprese librerie e SDK, supporta già i dispositivi a 16 KB. Vale comunque una prova, e vale la pena confermare di aver ispezionato la stessa build che hai caricato.
APK Analyzer o check_elf_alignment.sh nominano una libreria non allineata?
Attribuisci, poi aggiorna
Trova quale framework, plugin, SDK o motore fornisce quel nome file esatto e aggiorna quel pacchetto. Il tuo NDK non può riscrivere un binario precompilato da qualcun altro.
Che cosa riporta bundletool dump config per il bundle di rilascio?
PAGE_ALIGNMENT_4K
Le librerie vanno bene, è l’impacchettamento a non andare. Passa ad AGP 8.5.1 o successivo e ricompila, oppure applica la soluzione di ripiego con l’impacchettamento legacy se non puoi aggiornare.
PAGE_ALIGNMENT_16K
L’impacchettamento è corretto. Ora prova gli APK generati da Play su un vero ambiente a 16 KB e controlla il codice a runtime che dà per scontata una dimensione di pagina fissa.
La trappola in una riga
Un APK locale che supera ogni controllo di allineamento non dimostra che il bundle caricato sia corretto. Google avverte in modo specifico che Android Gradle Plugin dalla 8.3 alla 8.5 può produrre un bundle i cui APK costruiti da Play non sono allineati correttamente nello ZIP, anche quando l’APK sulla tua macchina sembra perfetto. Questo disallineamento è il motivo singolo più comune per cui l’avviso sopravvive a una correzione "riuscita".
Che cosa significa davvero l’avviso della Play Console
La conseguenza documentata da Google è precisa: dal 1º febbraio 2027 non potrai pubblicare aggiornamenti che puntano ad Android 15 (livello API 35) o superiore senza il supporto ai 16 KB. È un blocco alla pubblicazione degli aggiornamenti, non un’affermazione che un’app già pubblicata venga rimossa dallo store quel giorno. Fino ad allora la maggior parte degli sviluppatori vede un avviso di compatibilità, non un rifiuto al caricamento.
Le parole contano, perché la versione allarmista di questa storia viaggia più veloce di quella accurata. Leggi le stringhe che Google mostra davvero e l’ambito diventa stretto e gestibile.
App must support 16 KB memory page sizes
Ricostruito dallo screenshot della Play Console pubblicato da Google nella guida alle dimensioni delle pagine. Le etichette restano in inglese come in quello screenshot: la tua Console può mostrarle in italiano, e layout e pulsanti disponibili possono variare da account ad account.
Due letture di quella scheda sono spesso sbagliate. Primo: "Action by Feb 1, 2027" non è un conto alla rovescia verso la cancellazione; il testo di Google sulla stessa pagina descrive l’esito come l’impossibilità di pubblicare quegli aggiornamenti. Secondo: la stringa Extension granted compare nello screenshot di Google, ma questo non stabilisce che oggi esista per te una procedura di richiesta di proroga aperta. Considera reale una proroga solo se vedi l’opzione dentro la tua Play Console.
Quale scadenza hai letto davvero?
Circolano tre date e una sola è valida. Scegli quella che hai visto e qui ne trovi lo stato rispetto alla pagina attuale di Google, aggiornata l’ultima volta il 5 agosto 2026.
Strumento 01
Verifica delle scadenze
Google ha spostato questa scadenza più di una volta. Prima di costruire un piano di rilascio attorno al 1º febbraio 2027, apri tu stesso la guida alle dimensioni delle pagine e controlla la dicitura "Last updated" in fondo. Quell’unica abitudine vale più di qualsiasi data stampata in un articolo, incluso questo.
Il requisito dei 16 KB riguarda la mia app?
Non lo decide il tuo framework: lo decide il contenuto dell’APK che generi. Se ci sono file .so sotto lib sei nell’ambito, che tu abbia mai aperto un file C++ o no; se non ce n’è nessuno, sono le indicazioni di Google a dire che supporti già i dispositivi a 16 KB.
App in solo Java o Kotlin
Qui Google è netto: se la tua app e tutte le sue librerie e SDK usano solo Java o Kotlin, la tua app supporta già i dispositivi a 16 KB. Google consiglia comunque di testare in un ambiente a 16 KB per intercettare regressioni impreviste, e ti costa una sessione di emulatore.
L’inghippo è nella frase "e tutte le sue librerie e SDK". Una singola dipendenza di database, analytics, crash reporting, media, mappe, machine learning o sicurezza può aggiungere binari nativi a un progetto il cui sorgente contiene solo Kotlin. "Non ho scritto C++" non è una prova. La cartella lib sì.
Flutter, React Native, Unity, Kivy e gli app builder
Questi stack includono per progettazione runtime nativi, binari del motore e librerie dei plugin, quindi rientrano quasi sempre nell’ambito. Google nomina esplicitamente gli app builder di terze parti che usano librerie native come una via per cui un’app può essere coinvolta anche quando il suo autore non ha mai scritto C o C++. Quello che cambia non è se hai codice nativo ma quale pacchetto ha fornito il pezzo difettoso: ecco perché attribuire il nome file viene prima di qualsiasi aggiornamento.
Come controllare, esattamente
Apri l’APK di rilascio, espandi lib e guarda le cartelle ABI al suo interno, normalmente arm64-v8a e x86_64. La presenza di qualsiasi file shared object significa che la tua app usa codice nativo. Nessun file .so e nessuna cartella lib significa che questo APK non usa affatto codice nativo. La colonna Alignment nell’analizzatore mostra messaggi di avviso per i file con problemi di allineamento, ed è la via più rapida per passare da "qualcosa non va" a un nome file.
Strumento 02
Diagnosi di ambito
01 A che cosa punta oggi la tua app?
02 Apri l’APK di rilascio in APK Analyzer. C’è una cartella lib?
03 Quale descrive meglio l’app?
04 Hai eseguito bundletool dump config sul bundle di rilascio?
Perché un binario a 4 KB fallisce su un dispositivo a 16 KB
Una pagina di memoria è il blocco più piccolo che il kernel mappa in una volta. Android ha storicamente usato pagine da 4 KB; Android 15 ha aggiunto il supporto ai dispositivi configurati con pagine da 16 KB. Una libreria nativa registra l’allineamento per cui i suoi segmenti sono stati collegati, e se quel valore è più piccolo della dimensione di pagina del dispositivo il loader non può collocare il segmento su un confine di pagina.
Il meccanismo è tutto qui, e spiega l’unico numero che continuerai a vedere. L’allineamento si esprime come potenza di due: 2**12 vale 4096 byte, 2**14 vale 16384 byte. La regola di Google è che ogni segmento LOAD in una libreria nativa sia allineato a 2**14 o più. Una libreria costruita a 2**14 funziona sia sui dispositivi a 4 KB sia su quelli a 16 KB, perché 16384 è un multiplo esatto di 4096. Una libreria costruita a 2**12 funziona solo con la dimensione di pagina più piccola. È per questa asimmetria che la soluzione è sempre "alza l’allineamento" e mai "rileva il dispositivo".
Strumento 03
Visualizzatore di pagine
Scegli l’allineamento che riporta la tua libreria e guarda dove possono iniziare i suoi segmenti su un dispositivo che usa pagine da 16 KB.
Passa
C’è un secondo vincolo, del tutto separato, che vive fuori dalla libreria. Le librerie native non compresse memorizzate dentro un APK devono trovarsi anche loro su un confine da 16 KB dentro l’archivio ZIP. È una proprietà dell’impacchettamento, si controlla con zipalign ed è configurata dal tuo plugin di build, e può essere sbagliata mentre ogni libreria all’interno è perfettamente allineata. Tenere separate queste due idee è la cosa più utile che puoi portarti via da questa sezione.
Come leggere i numeri
Quando vedi 2**14 nell’output di llvm-objdump, è un successo. 2**13 o 2**12 è un fallimento. Non esistono mezze misure né "ci siamo quasi": basta un segmento LOAD non allineato, in una libreria, in un’ABI, per tenerti l’avviso sull’account.
La via più breve per ciascun framework
Prontezza del framework e conformità dell’app sono due cose diverse. React Native 0.77 e le versioni Unity supportate sono riferimenti reali e documentati. Flutter non ha un minimo universale verificabile. In ogni caso l’aggiornamento sistema i binari del framework stesso e lascia ogni plugin di terze parti esattamente non conforme com’era.
Strumento 04
Ricerca per framework
Che cosa può ancora fallire dopo
Tutti i riferimenti in una tabella
| Framework | Riferimento documentato | Azione più breve | Affidabilità |
|---|---|---|---|
| Flutter | Nessun minimo universale verificato; 3.38 è il riferimento documentato di preparazione (NDK r28 predefinito) | Flutter stabile corrente, aggiorna i plugin nativi, pulisci, ricompila, ispeziona ogni libreria | PARZIALE |
| React Native | 0.77 | Percorso di aggiornamento supportato, poi aggiorna moduli nativi e SDK dei fornitori | VERIFICATO |
| Linea Unity 6.1 | 6000.1 o successive | Aggiorna l’editor, aggiorna pacchetti e plugin, ricompila | VERIFICATO |
| Unity 6 LTS | 6000.0.38f1 o successive | Come sopra | VERIFICATO |
| Unity 2022 LTS | 2022.3.56f1 o successive | Come sopra | VERIFICATO |
| Unity 2021 | 2021.3.48f1 o successive, serve l’idoneità all’LTS esteso | Aggiorna se ne hai diritto, altrimenti migra a un editor supportato | VERIFICATO |
| Unity Burst | 1.8.21 o successive | Aggiorna Burst quando viene nominato lib_burst_generated.so |
VERIFICATO |
| Android nativo | NDK r28+ con AGP 8.5.1+ | Ricompila il codice tuo, aggiorna ogni dipendenza precompilata | VERIFICATO |
| Bloccato su NDK vecchio | r27 o precedenti con entrambe le opzioni del linker | Aggiungi max-page-size e common-page-size, ricompila tutte le librerie |
FUNZIONA, NON PREFERITO |
| Kivy o builder Python | Nessuna versione universale verificata | Aggiorna builder e ricette, segnala a monte il nome file esatto | DIPENDE DAL FORNITORE |
| Builder no-code | Nessuna versione universale verificata | Rigenera sullo stack di build conforme del fornitore e mandagli il nome file | DIPENDE DAL FORNITORE |
Le etichette di affidabilità hanno lo stesso significato ovunque in questa pagina. VERIFICATO significa che una fonte primaria attuale lo afferma direttamente. PARZIALE significa che una fonte affidabile sostiene l’affermazione centrale ma non ogni dettaglio implementativo. SEGNALATO significa che la prova è l’issue tracker di un manutentore o le segnalazioni degli sviluppatori invece di una nota di rilascio ufficiale.
Trova la libreria esatta che causa l’errore
Il nome file è tutta l’indagine. Una volta che sai che libfoo.so è il binario difettoso, la domanda smette di essere "come sistemo il supporto ai 16 KB" e diventa "quale pacchetto distribuisce libfoo.so ed esiste una versione più recente". La seconda domanda ha una risposta; la prima no.
Parti da APK Analyzer
Apri Build > Analyze APK..., carica l’APK di rilascio ed espandi lib. Dentro vedrai una cartella per ABI, normalmente arm64-v8a e x86_64. La colonna Alignment mostra messaggi di avviso sui file con problemi di allineamento. Anche gli avvisi di Android Studio e Lint evidenziano le librerie native non conformi, quindi puoi vedere la stessa segnalazione in più punti.
Annota ogni nome file segnalato prima di toccare un solo numero di versione. Controlla separatamente entrambe le cartelle ABI: è del tutto normale che arm64-v8a passi mentre x86_64 fallisce, o viceversa, perché sono binari diversi costruiti potenzialmente da pipeline diverse.
Decodifica l’output da riga di comando
Se preferisci lavorare in un terminale, Google distribuisce check_elf_alignment.sh, che riporta ALIGNED o UNALIGNED per un APK, e puoi ispezionare una singola libreria direttamente con llvm-objdump. Entrambi richiedono Android SDK Build-Tools 35.0.0 o successivo. Incolla qui sotto quello che stampano e te lo rileggiamo noi.
Strumento 05
Decodificatore ELF
Incolla l’output di llvm-objdump -p file.so | grep LOAD, check_elf_alignment.sh o zipalign -c -P 16. Tutto viene analizzato nel tuo browser: niente viene caricato da nessuna parte.
Capisci quale dipendenza la contiene
La Play Console e APK Analyzer ti danno entrambi un nome file e nessun proprietario. Digitalo qui sotto e ti diremo che cosa si sa di quel binario, con la qualità della prova allegata, dandoti i comandi di ricerca con il tuo nome file già inserito.
Strumento 06
Chi possiede la libreria
./gradlew app:dependencies ti mostra il grafo delle dipendenze risolte, ed è così che trovi il pacchetto transitivo che ha tirato dentro una libreria che non hai mai aggiunto tu. Non ti dirà direttamente quale artefatto contiene un dato .so, quindi abbinalo alla decompressione dell’AAR sospetto. Sono tecniche diagnostiche pratiche, non passaggi imposti da Google.
Verifica l’app bundle, non solo l’APK locale
Il tuo APK locale e gli APK che Google Play genera dal tuo bundle sono artefatti diversi. L’allineamento ELF vive dentro ogni libreria; l’allineamento ZIP è una proprietà di come è stato impacchettato l’archivio; e il bundle porta una configurazione che dice a Play quale dei due usare. Tutti e tre possono non essere d’accordo, e solo l’ultimo decide che cosa installano gli utenti.
È il meccanismo dietro la versione più frustrante del problema: lo sviluppatore aggiorna tutto, ispeziona l’APK locale, vede un output pulito, carica, e l’avviso è ancora lì. Niente di quello che ha controllato era sbagliato. Semplicemente non ha mai controllato la cosa che Play valuta.
Quello che hai ispezionato
app-release.apk sulla tua macchinaCostruito direttamente da Gradle sul tuo hardware, con il tuo comportamento di impacchettamento. Superare zipalign qui dimostra che questo file è impacchettato correttamente.
Quello che Play valuta
Gli APK generati da app-release.aabCostruiti da Google a partire dal tuo bundle, usando l’allineamento che il bundle richiede. Se il bundle dice 4 KB, questi sono sbagliati per quanto pulito fosse il tuo APK locale.
Quindi esegui questo comando sul bundle che stai per caricare, ogni volta:
bundletool dump config --bundle=app-release.aab | grep alignment
PAGE_ALIGNMENT_16K è il risultato che vuoi. PAGE_ALIGNMENT_4K significa che il bundle sta dicendo a bundletool di impacchettare le librerie native su confini da 4 KB, quindi ogni APK che Play costruirà da lì sarà sbagliato. Google avverte in modo specifico che Android Gradle Plugin dalla 8.3 alla 8.5 può produrre esattamente questo disallineamento: la build locale sembra allineata e l’app che Play costruisce dal bundle non si installerà correttamente su un dispositivo a 16 KB. La soluzione preferita è passare ad Android Gradle Plugin 8.5.1 o successivo.
Ogni comando, con dentro i tuoi nomi file
Digita i tuoi nomi file una volta sola. Ogni comando qui sotto si riscrive da solo e ogni scheda mostra l’output esatto che vale come successo, così non devi mai indovinare se un risultato fosse buono.
Strumento 07
Laboratorio dei comandi
Non fermarti a "APK Analyzer dice allineato"
Un’ispezione dell’APK superata è uno dei quattro controlli, non il traguardo. Conferma l’allineamento ELF dei LOAD, l’allineamento ZIP dell’APK, la configurazione del bundle e il comportamento a runtime dell’artefatto che Play genera davvero. Basta che uno solo fallisca per tenerti l’avviso sull’account dopo una build che credevi sistemata.
AGP, NDK e la trappola dell’impacchettamento
Due versioni reggono quasi tutto il peso. NDK r28 o successivo compila il codice nativo allineato a 16 KB in modo predefinito, e Android Gradle Plugin 8.5.1 o successivo impacchetta correttamente le librerie native non compresse sui confini ZIP da 16 KB. Nessuno dei due può riparare un binario precompilato arrivato dentro una dipendenza.
La zona grigia pericolosa è Android Gradle Plugin dalla 8.3 alla 8.5. In quell’intervallo una build locale può sembrare del tutto corretta mentre bundletool non allinea nello ZIP gli APK che produce dal tuo bundle per Play, e le parole di Google sull’esito sono nette: l’app costruita da quel bundle non si installerà correttamente. Se sei sulla 8.5.0 e il tuo APK locale supera ogni controllo che ti viene in mente, questa è la prima cosa da escludere.
Strumento 08
Verifica della toolchain
Riferimento delle impostazioni di build
| Situazione | Impostazione | Note |
|---|---|---|
| NDK consigliato | r28 o successivo |
Produce output nativo allineato a 16 KB in modo predefinito |
| AGP consigliato | 8.5.1 o successivo |
Gestisce le librerie native non compresse sui confini ZIP da 16 KB |
| NDK r27 o precedente | -Wl,-z,max-page-size=16384 |
Opzione del linker obbligatoria su ogni target nativo |
| NDK r27 o precedente | -Wl,-z,common-page-size=16384 |
Da usare insieme all’opzione sulla dimensione massima di pagina |
ndk-build |
LOCAL_LDFLAGS += ... |
Applica entrambe le opzioni a ogni target nativo |
| CMake | target_link_options(...) |
Applica entrambe le opzioni a ogni target interessato |
| Non puoi aggiornare AGP | jniLibs.useLegacyPackaging = true |
Comprime le librerie native; aumenta lo spazio occupato dopo l’installazione |
| AGP 8.0 o precedente | android.bundle.enableUncompressedNativeLibs=false |
Proprietà legacy aggiuntiva, insieme all’opzione qui sopra |
| Codice a runtime | getpagesize() o sysconf(_SC_PAGESIZE) |
Sostituisce i 4096 fissi e le assunzioni su PAGE_SIZE costante |
La parte che l’impacchettamento non può sistemare
Se il tuo C o C++ dà per scontata una dimensione di pagina, nessuna opzione di build ti salva. Elimina i valori 4096 scritti a mano e ogni dipendenza da una costante PAGE_SIZE fissa, leggi il valore reale a runtime con getpagesize() o sysconf(_SC_PAGESIZE), e rivedi ogni chiamata a mmap() insieme a qualsiasi argomento che stai allineando a mano. È la classe di guasti in cui un’app si installa senza problemi su un dispositivo a 16 KB, supera i controlli sul bundle e poi va in crash la prima volta che tocca la mappatura della memoria.
Ordine delle operazioni
Sistema il lato compilatore prima di quello dell’impacchettamento. Se applichi prima la soluzione con l’impacchettamento legacy, il tuo APK inizierà a superare zipalign mentre le librerie al suo interno sono ancora costruite per pagine da 4 KB, e avrai nascosto il problema vero dietro un risultato verde.
Prova su un vero ambiente a 16 KB
Un solo comando decide se la tua prova significa qualcosa: adb shell getconf PAGE_SIZE deve restituire 16384. Eseguilo prima di ogni sessione. Un emulatore avviato in silenzio in modalità 4 KB lascerà passare una build rotta a qualsiasi cosa tu le lanci contro.
Hai tre strade pratiche e due specialistiche. Scegli quella a cui puoi arrivare davvero oggi: ai fini di intercettare i guasti da dimensione di pagina non c’è differenza di qualità tra loro.
Strumento 09
Scelta dell’ambiente di test
Limite
Poi, ogni singola volta, prima di qualsiasi test
adb shell getconf PAGE_SIZE
Non proseguire se l’output non è 16384.
Che cosa provare davvero
Una volta confermato l’ambiente, la prova utile non è "si avvia". I guasti nativi si concentrano nelle funzioni che toccano codice nativo, quindi usale deliberatamente: avvio a freddo, navigazione nell’app, fotocamera, letture e scritture sul database, riproduzione e registrazione di contenuti multimediali, autenticazione, lavoro in background, qualsiasi funzione di machine learning o realtà aumentata, ogni superficie dei plugin nativi e tutto ciò che nel tuo codice usa la mappatura della memoria. Se una funzione è alimentata da una delle librerie che hai appena aggiornato, quella funzione è la prova.
La modalità di compatibilità non è un successo
Android può eseguire alcune app allineate a 4 KB su un dispositivo a 16 KB attraverso un percorso di compatibilità, e quando succede può comparire un avviso al primo avvio. Google consiglia comunque un corretto allineamento a 16 KB per la migliore affidabilità e stabilità. Un’app che gira solo perché è intervenuta la compatibilità non è un’app sistemata, e pubblicarla su quella base significa che il guasto vero ti aspetta più avanti.
Perché l’avviso sopravvive a un aggiornamento
Quasi ogni caso di "ma io l’ho già sistemato" è una di tredici situazioni specifiche, e undici di esse si possono dimostrare dall’artefatto che hai davanti. Scegli il sintomo che corrisponde e di solito conoscerai la causa prima di finire di leggere.
Strumento 10
Diagnosi dell’avviso persistente
Due di questi casi meritano una riserva invece di una risposta sicura. Nessuna fonte primaria stabilisce quanto tempo impieghi Google Play a rivalutare un bundle caricato, quindi se il tuo avviso persiste subito dopo un invio, la mossa onesta è confermare che il nuovo version code compaia nelle tue ultime versioni e app bundle e ricontrollare più tardi, invece di fidarsi di un numero specifico letto da qualche parte sui tempi di elaborazione. E un’app che funziona solo perché è intervenuta la modalità di compatibilità non è stata sistemata: è stata assecondata.
Librerie di terze parti che tornano spesso
Questi sono esempi segnalati, non una classifica di quanto sia comune ciascuno, e non la promessa che una data versione sistemerà la tua build. Un pacchetto può aggiungere, rimuovere o sostituire artefatti nativi in qualsiasi rilascio. L’autorità finale è sempre il binario che si trova nel tuo bundle di rilascio.
Usalo come punto di partenza quando un nome file ti sembra familiare, poi verifica sui rilasci correnti e sulle issue aperte di quel progetto. Dove la prova è l’issue tracker di un manutentore e non una nota di rilascio, la scheda lo dichiara.
Strumento 11
Elenco delle librerie segnalate
libobjectbox-jni.so
Vecchie librerie native Android fallivano in un ambiente a 16 KB. Non è emersa una versione corretta abbastanza confermata da pubblicarla qui. Controlla le note di rilascio correnti di ObjectBox per la versione che ha aggiunto il supporto ai 16 KB, poi verifica il binario dentro l’APK che hai costruito invece di fidarti della sola versione.
libreria Android inclusa
L’SDK Dart di ObjectBox include una propria libreria Android. Non è emersa una versione corretta abbastanza confermata da pubblicarla qui. Controlla le note di rilascio correnti di ObjectBox, poi verifica l’artefatto che la tua build risolve davvero.
libsqlite3.so
Una vecchia dipendenza 3.43.0 è comparsa nell’impacchettamento di Flutter e AWS Amplify coinvolti. Le prove dalle issue indicano la 3.46.1+1 come versione che ha aggiunto il supporto a 16 KiB. Controlla la versione della dipendenza risolta, non solo quella dichiarata, perché un pacchetto di framework può fissarne una più vecchia.
sqlcipher-android
Il vecchio pacchetto android-database-sqlcipher è deprecato a monte a favore del pacchetto mantenuto sqlcipher-android. Nessuna versione specifica è risultata abbastanza confermata da pubblicarla come minimo corretto, quindi migra al pacchetto attualmente mantenuto e valida ogni ABI nell’app costruita invece di fidarti di un numero di versione.
binari di elaborazione multimediale
Il repository originale di FFmpegKit è stato dismesso e non è stato stabilito un rilascio conforme universalmente sicuro. La qualità dei fork varia. Individua esattamente quale fork risolve la tua build, ispeziona direttamente i suoi artefatti per ABI e valuta manutenzione e provenienza prima di adottarne uno come soluzione.
binari Realm e JNI
Le segnalazioni sono in conflitto. È stata indicata la versione 20.1.0 e una segnalazione successiva diceva che la 20.2.0 aveva sistemato un binario Realm mentre un altro binario JNI restava problematico. Non è possibile indicare responsabilmente una singola versione sicura, quindi aggiorna e poi controlla una per una ogni libreria che Realm porta con sé.
libmediapipe_tasks_vision_jni.so
Segnalato con allineamento 2**12. Nella issue consultata non è stato stabilito un rilascio correttivo, quindi tratta la compatibilità come specifica della versione: controlla le note di rilascio correnti, aggiorna e verifica il binario nella tua build.
artefatto OpenCV Android
L’allineamento è stato segnalato su un artefatto Android di OpenCV 5.0.0. La issue del repository fa riferimento a una correzione in CI, ma nessun artefatto rilasciato specifico è stato stabilito con sicurezza. Scarica l’AAR esatto da cui dipendi, decomprimilo e ispeziona le librerie tu stesso.
lib_burst_generated.so
L’indicazione di Unity è aggiornare il pacchetto Burst alla 1.8.21 o successiva quando questo file viene segnalato. È l’unica voce dell’elenco sostenuta da documentazione ufficiale del fornitore invece che da segnalazioni nelle issue.
libUnityARCore.so, libquack.so e altri
Le segnalazioni della community indicano questi tra i binari che sopravvivono a un aggiornamento dell’editor. Non esiste una versione universale da citare, perché ognuno appartiene a un pacchetto diverso. Usa il nome file esatto per decidere quale pacchetto inseguire.
Nessuna voce corrisponde a quel filtro. È normale: questo elenco copre esempi segnalati, non ogni libreria dell’ecosistema. Usa la ricerca del proprietario della libreria e traccia il file dentro il tuo progetto.
Perché questo elenco è corto: il numero di issue mostra quali progetti hanno utenti rumorosi, non quali librerie siano installate più spesso. Pubblicare una classifica dei "colpevoli più comuni" significherebbe inventare una statistica. Quello che si generalizza è invece il metodo: prendi il nome file, trova il pacchetto, controlla i rilasci correnti di quel pacchetto, verifica il binario nella tua build.
Che rapporto ha con la scadenza API 36 del 31 agosto 2026
Sono due requisiti di Google Play indipendenti che si incontrano in un punto solo. Alzare il livello API target può far emergere l’avviso dei 16 KB, perché il requisito vale per le app che puntano ad Android 15 (livello API 35) o superiore. Non crea il disallineamento e non è in grado di ripararlo.
Google Play richiede che le app nuove e gli aggiornamenti puntino ad Android 16 (livello API 36) dal 31 agosto 2026, con una proroga richiedibile fino al 1º novembre 2026. È una modifica al manifest e al comportamento. La regola dei 16 KB invece è una modifica di compatibilità binaria. Chi alza targetSdk di lunedì e martedì vede un avviso sui 16 KB non ha rotto niente: le librerie native erano già compilate per pagine da 4 KB, e il livello target più alto ha semplicemente portato l’app dentro il perimetro di un controllo che si sarebbe comunque applicato.
Requisito A
Puntare all’API 36- Data 31 agosto 2026, proroga fino al 1º novembre 2026
- Ambito App nuove e aggiornamenti
- Vive in Il tuo manifest e la tua configurazione di build
- Si risolve Alzando il livello target e gestendo i cambi di comportamento di Android 16
Requisito B
Supporto alle pagine da 16 KB- Data 1º febbraio 2027
- Ambito App che puntano ad API 35+ su dispositivi a 64 bit
- Vive in I binari nativi dentro il tuo bundle
- Si risolve Ricompilando o sostituendo ogni libreria non allineata
In pratica trattali come un’unica migrazione con due prove. Il livello target lo alzerai comunque: pianifica l’audit delle librerie native nella stessa versione invece di scoprirlo nella corsa all’API 36. Per l’elenco completo dei livelli per formato di dispositivo, le eccezioni e il meccanismo della proroga leggi il nostro articolo sulla scadenza API 36 di Google Play, e per tutta la sequenza dall’account alla produzione il nostro articolo sui requisiti di pubblicazione 2026.
I controlli prima del caricamento
Undici verifiche, ognuna con una prova di superamento precisa. Falle prima di caricare invece che dopo che Play ti dice che qualcosa non va, e trasformi una sessione di debug senza fine in un elenco finito.
Strumento 12
Controlli di rilascio
0 di 11 superati
Ancora nulla di dimostrato. Parti dalla build che intendi caricare davvero, non dall’ultima che ti è capitato di avere aperta.
L’avanzamento è salvato solo in questo browser. Non viene inviato da nessuna parte e cancellando i dati del browser sparisce.
Superare tutti e undici i controlli dimostra l’allineamento tecnico rispetto alle verifiche citate in questa pagina. Non è una promessa di approvazione. Google Play può comunque sollevare problemi di policy, contenuto o qualità non correlati sullo stesso caricamento, e nessuna checklist al mondo può parlare per quelli.
Dove questo problema va a sbattere contro il test chiuso
Niente in questa pagina cambia il tuo requisito sui tester, e niente dei tuoi tester cambia la tua build. I due problemi si scontrano su un solo asse: il tempo. Un test chiuso di 14 giorni gira su un orologio che non puoi fermare, e un’indagine su una libreria nativa gira su un orologio che nessuno può prevedere.
La sequenza che fa male va così. Un account sviluppatore personale avvia un test chiuso, parte la finestra di 14 giorni continuativi di attivazione, e a metà strada un aumento del livello target fa emergere un avviso sui 16 KB. Ora lo sviluppatore ricompila dipendenze native mentre attorno a lui un gruppo di tester deve restare intatto. Caricare una nuova build sul canale va benissimo, e Google incoraggia a continuare ad aggiornare durante un test. Quello che rompe il percorso è il lato tester che si spegne.
È esattamente la parte che PrimeTestLab tiene ferma. Mettiamo a disposizione 12 tester reali su dispositivi reali da Android 7 a 17, attivati e mantenuti per tutti i 14 giorni, così la tua ricompilazione avviene contro un test stabile e non contro uno che si sta sgretolando. Il test parte in 4-6 ore e finora lo abbiamo fatto girare su oltre 7.400 app in 120+ Paesi con un tasso di successo del 99,9%.
Reclutare i tester da solo contro affidare tutto
| Il requisito di Google | Reclutarli da solo | Affidarlo a noi |
|---|---|---|
| Almeno 12 tester attivati | Trovare, istruire e rincorrere persone vere, poi sperare che nessuna si disattivi | 12 forniti e mantenuti per tutta la finestra |
| 14 giorni continuativi | Basta un tester che esce a metà per spezzare la finestra continuativa | Il gruppo è monitorato perché la finestra resti intatta |
| Dispositivi reali, persone vere | Emulatori e account inattivi sono la scorciatoia solita, e il motivo solito per cui un test fallisce | Dispositivi reali da Android 7 a 17 |
| Tempo fino alla prima attivazione | Giorni, a seconda di chi ti risponde | Il test parte in 4-6 ore |
| Costo | Il tuo tempo, proprio nella settimana in cui stai già ricompilando librerie | Da $19.99, più il 5% di commissione di servizio |
| Ricompilare a test in corso | Ogni nuovo caricamento è un altro giro di richieste di aggiornamento alle persone | Carica nuove build liberamente: il gruppo resta attivato |
Diciamolo chiaramente: non ricompiliamo le tue librerie native e questo articolo non è una vetrina per venderti quel servizio. Il lavoro sui 16 KB è tuo, e tutto quello che sta sopra questa sezione è scritto per renderlo il più breve possibile. Quello che ti togliamo dal piatto è il requisito sui tester che gira in parallelo, così i due problemi smettono di contendersi le stesse due settimane.
Consiglio sulla sequenza
Se non hai ancora avviato il test chiuso e sai già di avere librerie native, fai partire prima la finestra dei tester e svolgi il lavoro di allineamento al suo interno. Il periodo di qualificazione di Google si misura sulla continuità dell’attivazione dei tester e non su una singola build congelata, e Google incoraggia a continuare ad aggiornare durante un test: le due tempistiche possono quindi sovrapporsi invece di sommarsi. Nel frattempo tieni lo stesso canale e lo stesso gruppo di tester. Spesso è una settimana intera risparmiata.
Domande frequenti
Google Play sta rifiutando adesso le app non compatibili con i 16 KB?
La documentazione attuale di Google dice che a partire dal 1º febbraio 2027 non potrai più pubblicare aggiornamenti che puntano ad Android 15 (livello API 35) o superiore senza il supporto ai 16 KB sui dispositivi a 64 bit. Prima di quella data la maggior parte degli sviluppatori vede un avviso di compatibilità nella Play Console e non un blocco vero e proprio. La conseguenza documentata sulla pagina Google citata è l’impossibilità di pubblicare aggiornamenti non conformi, non la rimozione automatica di un’app già pubblicata.
Perché Google dice 1º febbraio 2027 mentre altri articoli dicono 1º novembre 2025?
Il 1º novembre 2025 era la scadenza annunciata originariamente da Google e il 31 maggio 2026 è stata una proroga successiva ormai storica. Al 5 agosto 2026 la pagina attuale di Android Developers e lo screenshot attuale dell’avviso nella Play Console mostrano entrambi il 1º febbraio 2027, quindi vale la fonte primaria più recente. Molti post e molte risposte delle AI citano ancora le date vecchie perché sono stati scritti prima del cambiamento.
Non ho mai scritto C++. Perché la mia app è coinvolta?
Un framework, un SDK, un plugin, un motore di gioco, un database, un componente multimediale o un app builder possono aggiungere file .so nativi anche quando il tuo sorgente è Dart, JavaScript, Python, Java o Kotlin. Le indicazioni di Google includono esplicitamente le app che usano librerie NDK in modo indiretto tramite una dipendenza. Apri l’APK in Android Studio con Build e poi Analyze APK: qualsiasi file .so sotto lib significa che l’app impacchettata usa codice nativo.
Un’app in solo Kotlin ha bisogno di modifiche?
Secondo Google, un’app che usa solo Java o Kotlin, comprese tutte le sue librerie e SDK, supporta già i dispositivi a 16 KB. Google consiglia comunque di testare in un ambiente a 16 KB per intercettare regressioni impreviste. Verifica che l’APK di rilascio reale non abbia una cartella lib prima di definire la tua app solo Kotlin, perché basta una dipendenza di analytics o di database ad aggiungerne una.
Quale versione di Flutter risolve l’avviso sulla dimensione pagina da 16 KB?
Nessuna fonte ufficiale stabilisce una versione di Flutter che garantisca la conformità di ogni app e di ogni plugin. Le note di rilascio di Flutter 3.27 sono più strette di quanto sembrino: coprono il supporto ai 16 KB per i template plugin_ffi in particolare e non l’intero engine. Flutter 3.38 è il riferimento documentato più solido, perché Flutter ha presentato esplicitamente l’aggiornamento a quella versione come preparazione al requisito dei 16 KB di Play e ha portato l’NDK predefinito a r28. La cosa più sicura è passare alla release stabile corrente di Flutter, aggiornare ogni plugin nativo, ricompilare il bundle di rilascio e ispezionare ogni file .so che ne esce.
Quale versione di React Native supporta le pagine da 16 KB?
React Native 0.77 è il riferimento ufficiale chiaro. L’annuncio di rilascio dichiara che React Native è pronto a supportare pienamente le pagine di memoria da 16 KB. I moduli nativi della community, il codice C++ locale e gli SDK di terze parti possono comunque contenere binari non compatibili, quindi aggiorna seguendo il percorso di migrazione supportato di React Native o Expo e poi ispeziona l’APK generato.
Di quale versione di Unity ho bisogno per il supporto ai 16 KB?
Unity indica 6000.1 o successive, 6000.0.38f1 o successive, 2022.3.56f1 o successive e 2021.3.48f1 o successive nell’LTS esteso per i clienti Enterprise o Industry idonei. Aggiorna anche i plugin nativi e porta Burst alla 1.8.21 o successiva se la Play Console nomina lib_burst_generated.so. Una versione supportata dell’editor è necessaria ma non sufficiente, perché i plugin di terze parti portano i propri binari.
Come trovo il file .so esatto che sta fallendo?
Apri l’APK con Build e poi Analyze APK in Android Studio, espandi lib/arm64-v8a e lib/x86_64 e leggi la colonna Alignment, che mostra avvisi per i file con problemi di allineamento. Per la conferma da riga di comando esegui lo script check_elf_alignment.sh di Google sull’APK, oppure ispeziona una singola libreria con llvm-objdump -p file.so filtrando con grep LOAD. Qualsiasi allineamento LOAD sotto 2**14 va sistemato.
Perché il mio APK passa ma l’app bundle continua a fallire?
L’allineamento ELF dentro una libreria e l’allineamento ZIP dentro l’artefatto impacchettato sono due controlli distinti. Esegui bundletool dump config --bundle=app.aab e filtra con grep alignment: PAGE_ALIGNMENT_16K passa, mentre PAGE_ALIGNMENT_4K significa che gli APK generati vengono ancora richiesti a 4 KB. Google avverte in modo specifico che Android Gradle Plugin dalla 8.3 alla 8.5 può sembrare corretto in locale mentre gli APK che Play costruisce dal tuo bundle non sono allineati correttamente nello ZIP, quindi passa alla 8.5.1 o successiva.
Basta aggiornare a NDK r28 per risolvere?
No. NDK r28 e successivi compilano allineati a 16 KB in modo predefinito, ma questo riguarda solo il codice nativo compilato durante la tua build. Non può riscrivere un file .so precompilato che arriva dentro un AAR, un plugin o un pacchetto di un motore di gioco di terze parti. Ogni dipendenza nativa precompilata deve essere aggiornata, sostituita oppure ricompilata e reimportata.
Posso testare il supporto ai 16 KB senza possedere un telefono compatibile?
Installa una delle immagini di sistema a 16 KB dell’emulatore Android tramite SDK Manager, oppure prenota un dispositivo supportato su Samsung Remote Test Lab. Qualunque cosa usi, conferma prima l’ambiente con adb shell getconf PAGE_SIZE: l’output deve essere 16384 perché il test significhi qualcosa. Il successo su emulatore dimostra il comportamento a runtime, non l’impacchettamento, quindi continua a ispezionare anche il bundle di rilascio.
Risolvere i 16 KB azzera o influenza il mio test chiuso in corso?
Google misura il periodo di qualificazione sul fatto che almeno 12 tester restino attivati continuativamente per 14 giorni, non su una singola build congelata, e incoraggia a continuare ad aggiornare la build durante un test. Google non pubblica una garanzia esplicita che copra ogni scenario di sostituzione della build, quindi la strada più sicura è mantenere stabile il gruppo di tester mentre carichi a metà test un bundle ricompilato e conforme ai 16 KB. PrimeTestLab fornisce 12 tester reali su dispositivi reali da $19.99, più il 5% di commissione di servizio, e tiene il gruppo per tutti i 14 giorni.
In sintesi
Riepilogo
Google Play richiede che le app che puntano ad Android 15 (livello API 35) o superiore supportino le pagine di memoria da 16 KB sui dispositivi a 64 bit, e dal 1º febbraio 2027 gli aggiornamenti non conformi non potranno più essere pubblicati. 1º novembre 2025 e 31 maggio 2026 sono date morte che però continuano a posizionarsi. Le app scritte solo in Java o Kotlin sono già conformi. Tutti gli altri seguono gli stessi tre passaggi: individua il .so che fallisce, aggiorna il pacchetto che lo contiene e dimostra la bontà dell’artefatto con due controlli indipendenti, cioè ogni segmento ELF LOAD ad almeno 2**14 e il bundle che riporta PAGE_ALIGNMENT_16K. AGP 8.5.1+ con NDK r28+ è la toolchain predefinita più sicura, e nessuno dei due può riparare un binario compilato da qualcun altro. Se tutto questo capita durante un test chiuso, il lato tester è la parte che puoi delegare. Vedi i piani →
Fonti primarie
Che cosa invecchierà per primo in questa pagina
- La data del 1º febbraio 2027. Google ha già spostato questa scadenza più di una volta. Prima di pianificarci sopra una versione, controlla la dicitura "Last updated" in fondo alla guida sulle dimensioni delle pagine.
- I testi della Play Console. Testi e navigazione della Console cambiano in modo indipendente dalle pagine di policy, quindi le voci che vedi possono differire da quelle riprodotte qui.
- Le versioni di riferimento dei framework. Flutter rilascia versioni stabili di frequente, la policy di supporto di React Native evolve e i requisiti Unity LTS cambiano. Verifica sulle note di rilascio correnti, non su una versione stampata in un articolo.
- L’elenco delle librerie segnalate. Qualunque pacchetto può aggiungere, sostituire o far regredire un binario nativo in qualsiasi rilascio. Verifica sempre l’artefatto nel tuo bundle.
- I nomi delle immagini per emulatore. Le immagini contrassegnate come sperimentali possono essere rinominate o promosse, quindi la stringa esatta in SDK Manager potrebbe non coincidere.
Verificato sulla documentazione di Google il 9 agosto 2026. Revisione mensile fino ad almeno un mese dopo l’entrata in vigore.