Android passa a 16 KB di pagine di memoria E non si tratta di un cambiamento di poco conto per lo sviluppatore. Dietro c'è un piccolo aggiustamento nel modo in cui il sistema gestisce la RAM Ciò può tradursi in un avvio più rapido delle app, un consumo energetico inferiore e dispositivi più reattivi, soprattutto su hardware moderni con più memoria. Se lavori con NDK, motori di gioco o SDK che includono file .so, questa modifica ti riguarda direttamente.
Nelle prossime versioni, Sempre più dispositivi saranno configurati per 16 KB E Google Play stabilirà il passo con un requisito specifico: se la tua app è destinata ad Android 15 o versioni successive, deve essere compatibile. Qui scoprirai, senza ulteriori indugi, cosa cambia, perché è importante, chi è interessato, come rilevarlo nel tuo APK o AAB, cosa aggiornare in AGP e NDK, come testare su emulatori e Pixel, modalità di compatibilità e date di rilascio principali.
Cos'è una pagina di memoria e perché Android passa a 16 KB?
Una pagina è l'unità con cui il sistema operativo alloca e gestisce la RAM. Android è stato storicamente ottimizzato per 4KB perché era una cosa normale nei kernel e nei dispositivi. CPU ARM Supportano anche 16 KB e, a partire da Android 15, AOSP consente di configurare il sistema per utilizzare pagine da 16 KB su arm64, mantenendo al contempo la compatibilità con kernel da 4 KB o 16 KB a partire da android14-6.1.
Il cambiamento ha un compromesso: in media viene utilizzata leggermente più memoria, ma la contabilità della tabella delle pagine è ridotta e l'efficienza della memoria e dell'I/O è migliorata. Con più RAM nei terminali attuali, l'equilibrio è bilanciato. Inoltre, l'allineamento ELF a 16 KB nello spazio utente consente allo stesso binario di funzionare sia su kernel da 4 KB che da 16 KB, se correttamente allineato.
Benefici misurati e costi associati
I test interni di Google indicano chiari miglioramenti: Lancio di app in media del 3,16% più veloce, con casi che si avvicinano al 30% in alcune app. All'avvio delle app, il consumo energetico si riduce di circa il 4,56%.
Sono stati osservati anche impatti sulle funzioni di sistema sensibili alle prestazioni: La fotocamera si avvia il 4,48% più velocemente quando è calda e il 6,60% più velocemente quando è freddae il tempo di avvio del sistema migliora di circa l'8% (circa 950 ms). Altre analisi pubblicate riportano guadagni complessivi del 5-10% al costo di circa il 9% di RAM in più.
Chi ne è realmente colpito?
Se la tua app utilizza codice C o C++ nativo Se si utilizza l'NDK, si collega a librerie .so di terze parti, si integrano motori come Unity o Unreal o si fa affidamento su SDK che includono file .so, è consigliabile ricompilare e allineare a 16 KB. Se si sospetta un utilizzo elevato, consultare le istruzioni per identificarlo. applicazioni che consumano molta memoriaSono ora supportate le app scritte esclusivamente in Java o Kotlin, comprese le relative dipendenze, anche se è consigliabile testare con dimensioni inferiori a 16 KB per evitare sorprese.
Si noti che Molti SDK moderni offrono già build compatibili E, secondo diversi media, molte app e framework popolari come Flutter e React Native si stanno adattando. Tuttavia, è fondamentale verificare ogni file .so che si crea.
Come sapere se la tua app utilizza la tecnologia nativa ed è interessata
Per prima cosa, controlla se l'APK o l'AAB contiene .so. Analizzatore APK in Android Studio semplifica le cose: Build → Analizza APK, vai a lib e controlla se ci sono oggetti condivisi in arm64-v8a o x86_64. Se ci sono file .so, significa che sono nativi. La colonna Allineamento mostra avvisi quando rileva problemi con 16 KB.
Inoltre, Lint avvisa della presenza di librerie native non allineate entro 16 KBÈ un modo rapido per vedere quali dipendenze o moduli necessitano attenzione, anche prima di compilare una build finale.
Controllare l'allineamento ELF e l'imballaggio
Il punto chiave è che il I segmenti LOAD del tuo .so sono allineati a 16 KB e l'APK risultante è allineato allo zip a 16 KB quando non si comprimono le jniLibs.
- Sceneggiatura ufficiale check_elf_alignment.sh su Linux o macOS – Analizza un APK e contrassegna ogni .so come ALLINEATO o NON ALLINEATO per arm64-v8a e x86_64.
- strumenti da riga di comando: Estrarre l'APK, individuare i file .so in lib ed esaminare i segmenti LOAD con readelf. Cercare align 2**14.
- zipalign: convalida che l'APK sia allineato a 16 KB quando non si comprimono le librerie condivise.
# Comprobar segmentos de carga y su alineación
readelf -l ruta/libmilib.so | grep LOAD
# Ejemplo de salida válida (alineación 16 KB)
LOAD off 0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**14
LOAD off 0x0000000000042a90 vaddr 0x0000000000043a90 paddr 0x0000000000043a90 align 2**14
# Verificar zipalign del APK en 16 KB
zipalign -c -P 16 -v 4 MiApp.apk
# Debe terminar con Verification successfulSe vedi allinea 213, 212 o inferiore, oppure se zipalign fallisce, che la libreria o l'imballaggio non sono conformiRicompilare, correggere i flag e ricontrollare prima di pubblicare.
Aggiorna la tua toolchain: AGP, NDK e flag necessari
Per i dispositivi da 16 KB ci sono due frontali obbligatori: Allineamento ELF del .so y Allineamento APK ZIP quando distribuisci jniLib non compresse.
Plugin Android Gradle 8.5.1 o superiore
Con le librerie non compresse, i dispositivi da 16 KB richiedono che l'APK sia allineato tramite zip a 16 KB. AGP 8.5.1 o versioni successive eseguono questa operazione per impostazione predefinita. Ed è la strada consigliata. Se si lavora con AGP dalla versione 8.3 alla 8.5, c'è un problema noto: bundletool non comprime di default, e si potrebbe vedere che tutto sembra corretto localmente, ma la build distribuita da Play non riesce a installarsi.
Se non è ancora possibile eseguire l'aggiornamento alla versione 8.5.1, esiste una piano B temporaneo: Crea pacchetti di librerie compresse per evitare il requisito di allineamento zip da 16 KB. In Gradle, puoi forzare il packaging legacy delle jniLib.
// Groovy
authoring example
android {
packagingOptions {
jniLibs {
useLegacyPackaging true
}
}
}
// Kotlin DSL
android {
packaging {
jniLibs {
useLegacyPackaging = true
}
}
}Fate attenzione a questo approccio: Quando si comprime .so, il programma di installazione deve estrarli e copiarli, che aumenta l'ingombro e può aumentare il tasso di errore dell'installazione a causa di spazio di archiviazione insufficiente. La soluzione definitiva è l'aggiornamento ad AGP 8.5.1 o versione successiva.
NDK e collegato a 16 KB
- NDK r28 o successivo: compila di default con allineamento a 16 KB. Questa è l'opzione ideale.
- NDK-r27: Consenti 16 KB aggiungendo i flag appropriati in ndk-build, CMake o direttamente al linker.
- NDK r26 e precedenti: Non consigliato. Può essere forzato, ma il supporto non è garantito. Nella R22 e nelle versioni precedenti, potrebbe essere richiesto common-page-size=16384 a causa di bug storici in ld e lld e a causa dell'ELF che include .relro_padding con LLD 18 o superiore.
# Flag estándar de vinculador para máximo tamaño de página
-Wl,-z,max-page-size=16384Se la tua app si collega dinamicamente con il vecchio libc++_shared.so Se si utilizza NDK r26 o una versione precedente, si corre il rischio che l'installazione non vada a buon fine sui dispositivi da 16 KB. Si consiglia di migrare a NDK r27 o r28; come alternativa temporanea, è possibile collegare staticamente l'STL alla libreria, valutando i pro e i contro in termini di manutenzione e dimensioni.
Correggi le ipotesi di 4 KB nel tuo codice
Anche se l'allineamento è corretto, potrebbero verificarsi arresti anomali o perdite se si presume che PAGE_SIZE sia 4096. Evita di fare affidamento su PAGE_SIZE rigidamente; in NDK r27 e versioni successive, al di sotto dei 16 KB non è nemmeno definito per impedirne l'uso improprio.
Ottieni la dimensione effettiva in fase di esecuzione con getpagesize o sysconfe controlla le chiamate mmap e le API che richiedono argomenti allineati alla pagina. Se richiedi 1–5 KB, il kernel allocherà comunque 16 KB per 16 KB; quando possibile, combina le regioni RW per sfruttare al meglio una singola pagina e ridurre gli sprechi.
// Ejemplos en C/C++
long sz = getpagesize();
// o
long sz2 = sysconf(_SC_PAGESIZE);
// Usa sz en lugar de valores fijos al calcular offsets, tamaños y alineacionesTest in ambiente da 16 KB
Dopo la ricompilazione, è il momento di convalidare accuratamente. Configura Android 15 nell'SDK e crea un AVD basato su immagine da 16 KB. Android Studio Jellyfish 2023.3.1 o versioni successive lo supporta; per un'esperienza ottimale, si consiglia Ladybug 2024.2.1 o versioni successive.
In SDK Manager, in Piattaforme SDK, mostra i dettagli e, in Android VanillaIceCream o versioni successive, seleziona Immagini da 16 KB Hai bisogno di: ARM 64 v8a Google APIs Experimental o x86_64 Google APIs Experimental. Dimensioni pagina 16 KB. Se stai emulando un Pixel compatibile, ARM 64 v8a è sufficiente.
Nota sull'emulatore e sul debug
Tra le versioni dell'emulatore 35.1.5 e 35.1.20 e prima della revisione 4 delle immagini Android 15 da 16 KB, su x86_64 c'è un passaggio in più: modifica config.ini dell'AVD e includere il parametro kernel.
# Edita config.ini del AVD
añade esta lÃnea y guarda
kernel.parameters = androidboot.page_shift=14
# Verifica el entorno de 16 KB
a db shell getconf PAGE_SIZE
16384C'è un problema noto con LLDB in immagini da 16 KB, che è stato risolto in NDK r27 RC1 e Android Studio Koala 2024.1.2 Canary 5. Mantieni aggiornati i tuoi strumenti per un debug senza intoppi.
Test su hardware reale e opzioni per sviluppatori
A partire da Android 15 QPR1, alcuni dispositivi includono un interruttore per l'avvio a 16 KB. Pixel 8, 8 Pro e 8a con 15 QPR1e Pixel 9, 9 Pro e 9 Pro XL con QPR2 Beta 15 o versioni successive, possono essere abilitati dalle Opzioni Sviluppatore. Assicurati di applicare gli aggiornamenti di sistema prima di testarli.
# Comprueba el tamaño de página del dispositivo
adb shell getconf PAGE_SIZE
# Espera ver 16384Modalità di compatibilità 16 KB
Quando il dispositivo esegue un kernel da 16 KB, Package Manager può attivare una modalità di compatibilità con le versioni precedenti Se rileva un file .so con segmenti LOAD da 4 KB o un APK con un file ELF non compresso allineato a 4 KB, l'app visualizzerà un avviso al primo avvio indicando che è in esecuzione in modalità di compatibilità .
Questa modalità consente il funzionamento di alcune app, ma non è l'opzione consigliata. Per affidabilità e stabilità , allineare tutto a 16 KBÈ possibile abilitare o disabilitare la compatibilità per ogni app dalle informazioni dell'app, in Avanzate, in Esegui app in modalità compatibilità dimensioni pagina, visibile solo sui dispositivi configurati con 16 KB.
# Control global de compatibilidad en el dispositivo
adb shell setprop bionic.linker.16kb.app_compat.enabled true
adb shell setprop pm.16kb.app_compat.disabled false
# Forzar desactivación global
adb shell setprop bionic.linker.16kb.app_compat.enabled false
adb shell setprop pm.16kb.app_compat.disabled true
# A nivel de app en el manifest
android:pageSizeCompatDate e requisiti di Google Play
Per preparare i nuovi dispositivi, dal 1 novembre 2025 Tutte le nuove app e gli aggiornamenti per Android 15 o versioni successive devono supportare le pagine da 16 KB su Google Play. Senza questo supporto, la pubblicazione potrebbe essere bloccata.
Diversi sviluppatori hanno ricevuto ulteriori comunicazioni sulla Play Console che pone un pietra miliare intorno al 1 maggio 2026 per rafforzare il blocco degli aggiornamenti non conformi. Controlla la tua console e le comunicazioni di Play per verificare quali scadenze si applicano al tuo caso.
Come preparare i bagagli e controllare prima dell'imbarco
Prima di pubblicare, assicurati che il tuo APK o AAB sia in ordine. Costruire, analizzare e convalidare sempre in CI e localmente.
- Compila con AGP 8.5.1 o superiore e NDK r28, se possibile. Se usi r27, aggiungi flag da 16 KB durante il collegamento.
- Esegui la scansione con APK Analyzer e Lint per trovare avvisi di allineamento e .so.
- Utilizzare readelf per confermare l'allineamento 2**14 nei segmenti LOAD di tutti i file .so.
- Convalidare zipalign a 16 KB con zipalign -c -P 16 -v 4.
- Installa e prova su un emulatore o su un Pixel con 16 KB abilitati. Assicurati che PAGE_SIZE = 16384.
Errori comuni e come risolverli
- L'installazione da Play non riesce ma ha funzionato localmente: Questo è solitamente dovuto a un zipalign mancante durante la generazione da un bundle con AGP 8.3–8.5. Aggiorna ad AGP 8.5.1 o usa temporaneamente jniLibs compresse e convalida di nuovo.
- INSTALL_FAILED_INVALID_APK o dimensione della pagina ELF non supportata: : c'è .so a 4 KB. Correggi NDK r27 o r28, aggiungi -Wl,-z,max-page-size=16384 se applicabile, pulisci e ricompila.
- Funziona sull'emulatore e non funziona sul dispositivo da 16 KB- SDK di terze parti sospetti e obsoleti. Identifica il file .so problematico in logcat, aggiorna la dipendenza o richiedi una build compatibile.
- L'avviso di Play Console persiste: Ci sono alcuni file .so rimanenti di 4 KB nel tuo AAB. Genera file .apk con bundletool, estraili ed esegui readelf su tutti i file .so finché non sei sicuro che mostrino tutti l'allineamento 2**14.
Per piattaforma e dispositivi OEM: kernel e spazio utente
Su arm64, puoi compilare il kernel in 16 KB con Kleaf utilizzando l'opzione appropriata o abilitando CONFIG_ARM64_16K_PAGES invece di CONFIG_ARM64_4K_PAGES. Nello spazio utente Android, questi flag di prodotto aiutano ad abilitare 16 KB e a prova di futuro:
PRODUCT_NO_BIONIC_PAGE_SIZE_MACRO := true
PRODUCT_MAX_PAGE_SIZE_SUPPORTED := 16384Dopo aver selezionato la destinazione con lunch, controlla le variabili con get_build_var e conferma che restituiscano rispettivamente 16384 e true. Anche se la compilazione passa, possono persistere differenze di runtime fino a 16 KB, quindi è consigliabile testare attentamente mmap, allineamenti e ipotesi sui componenti critici.
Controlli aggiuntivi per precompilati e test
Per ridurre le sorprese con i binari esterni, puoi abilitare PRODUCT_CHECK_PREBUILT_MAX_PAGE_SIZE A partire da Android 16, questa funzionalità viene utilizzata per convalidare le app predefinite nelle build. Può essere temporaneamente ignorata con ignore_max_page_size in Android.bp o LOCAL_IGNORE_MAX_PAGE_SIZE in Android.mk.
PRODUCT_CHECK_PREBUILT_MAX_PAGE_SIZE := true
# Ignorar temporalmente en Android.bp
ignore_max_page_size: true
# Ignorar temporalmente en Android.mk
LOCAL_IGNORE_MAX_PAGE_SIZE := true
# Test de alineación en dispositivos lanzados con Android 15+
atest elf_alignment_testLista di controllo per la conformità rapida
- AGP 8.5.1+ o jniLib compresse come misura temporanea.
- NDK r28+ (o r27 con flag) e tutto .so con align 2**14.
- Nessuna ipotesi di 4KB nel codice; utilizzare getpagesize o sysconf.
- zipalign in 16 KB convalidato e testato su emulatore e Pixel 16 KB.
- Dipendenze native verificato e aggiornato alle build compatibili.
Chiunque sviluppi app con native dovrebbe dedicare un po' di tempo a questo adattamento, ma il guadagno in termini di prestazioni e la garanzia di installazione sui nuovi dispositivi Ne vale la pena. Con strumenti aggiornati, verifica sistematica dei file .so, correzione delle ipotesi del codice e test a 16 KB, lo stesso binario funzionerà sia a 4 KB che a 16 KB.
Preparare ora la tua app ti consente di risparmiare blocchi di pubblicazione su Play e di offrire lanci più rapidi, transizioni più fluide e un consumo più mirato su base giornaliera. Condividi queste informazioni in modo che più utenti siano a conoscenza di questo argomento..