Supportare dimensioni delle pagine di 16 kB

Storicamente, Android ha supportato solo dimensioni delle pagine di memoria di 4 KB, il che ha ottimizzato le prestazioni della memoria di sistema per la quantità media di memoria totale che i dispositivi Android hanno in genere avuto. A partire da Android 15, AOSP supporta i dispositivi configurati per utilizzare una dimensione pagina di 16 KB (dispositivi da 16 KB). Se la tua app utilizza librerie NDK, direttamente o indirettamente tramite un SDK, dovrai ricompilare l'app per farla funzionare su questi dispositivi da 16 KB.

Man mano che i produttori di dispositivi continuano a creare dispositivi con quantità maggiori di memoria fisica (RAM), molti di questi dispositivi adotteranno dimensioni delle pagine di 16 KB (e alla fine maggiori) per ottimizzare le prestazioni del dispositivo. L'aggiunta del supporto per i dispositivi con dimensioni di pagina di 16 kB consente alla tua app di essere eseguita su questi dispositivi e di sfruttare i miglioramenti delle prestazioni associati. Senza ricompilazione, le app non funzioneranno sui dispositivi da 16 KB nelle versioni future di Android.

Per aiutarti ad aggiungere il supporto per la tua app, abbiamo fornito indicazioni su come verificare se la tua app è interessata, su come ricompilare l'app (se applicabile) e su come testarla in un ambiente da 16 kB utilizzando emulatori (incluse le immagini di sistema Android 15 per Android Emulator).

Requisito di compatibilità di Google Play

Per garantire che la tua app funzioni correttamente sulle versioni più recenti di Android, tutte le app destinate ad Android 15 (livello API 35) e versioni successive devono supportare le dimensioni delle pagine di memoria di 16 KB sui dispositivi a 64 bit su Google Play. A partire dal 1° febbraio 2027, se gli aggiornamenti della tua app non supportano le dimensioni delle pagine di memoria di 16 kB, non potrai rilasciarli.

Vantaggi e miglioramenti delle prestazioni

I dispositivi configurati con dimensioni di pagina di 16 KB in media utilizzano un po' più di memoria, ma ottengono anche vari miglioramenti delle prestazioni sia per il sistema sia per le app:

• Tempi di avvio delle app più ridotti quando il sistema è sotto pressione di memoria: in media il 3,16% meno, con miglioramenti più significativi (fino al 30%) per alcune app che abbiamo testato
• Assorbimento di corrente ridotto durante l'avvio dell'app: riduzione media del 4,56%
• Avvio più rapido della fotocamera: in media gli avvii a caldo più veloci del 4,48% e degli avvii a freddo del 6,60% più velocemente
• Tempo di avvio del sistema migliorato: miglioramento medio dell'8% (circa 950 millisecondi)

Questi miglioramenti si basano sui nostri test iniziali e i risultati sui dispositivi effettivi potrebbero essere diversi. Forniremo ulteriori analisi dei potenziali guadagni per le app man mano che continuiamo i test.

Controllare se la tua app è interessata

Se la tua app utilizza codice nativo, devi ricompilarla con il supporto per i dispositivi da 16 kB. Se non sai con certezza se la tua app utilizza codice nativo, puoi utilizzare APK Analyzer per identificare se è presente codice nativo e poi controllare l'allineamento dei segmenti ELF per le librerie condivise che trovi. Android Studio offre anche funzionalità che ti aiutano a rilevare automaticamente i problemi di allineamento.

Se la tua app utilizza solo codice scritto nel linguaggio di programmazione Java o in Kotlin, incluse tutte le librerie o gli SDK, allora la tua app supporta già dispositivi da 16 KB. Tuttavia, ti consigliamo di testare l'app in un ambiente da 16 KB per verificare che non si verifichino regressioni impreviste nel comportamento dell'app.

La tua app utilizza codice nativo?

La tua app utilizza codice nativo se si verifica una delle seguenti condizioni:

• La tua app utilizza codice C/C++ (nativo). Se la tua app utilizza l'Android NDK, utilizza codice nativo.
• La tua app si collega a librerie o dipendenze native di terze parti (ad esempio SDK) che le utilizzano.
• La tua app è creata da un builder di app di terze parti che utilizza librerie native sul dispositivo.

Identificare le librerie native utilizzando lo Strumento di analisi APK

Strumento di analisi APK è uno strumento che ti consente di valutare vari aspetti di un APK creato. Per verificare se la tua app utilizza codice nativo (indipendentemente dalla compatibilità con 16 kB):

1. Apri Android Studio, poi fai clic su File > Apri e scegli un progetto.

2. Nella barra dei menu, fai clic su Build > Analyze APK… (Build > Analizza APK…)

   

3. Scegli l'APK da analizzare.

4. Cerca all'interno della cartella lib, che ospita i file degli oggetti condivisi (.so), se presenti. Se sono presenti file oggetto condivisi, la tua app utilizza codice nativo. La colonna Allineamento mostra messaggi di avviso per tutti i file che presentano problemi di allineamento. Se non sono presenti file oggetto condivisi o non è presente la cartella lib, la tua app non utilizza codice nativo.

   

Rilevare problemi di allineamento con controlli automatici

Android Studio ti avvisa in modo proattivo se le librerie o gli APK precompilati non sono conformi a 16 KB. Utilizza lo strumento APK Analyzer per esaminare quali librerie devono essere aggiornate o se sono necessarie modifiche al codice.

Lint in Android Studio evidenzia anche le librerie native che non sono allineate a 16 KB.

Controllare l'allineamento dei segmenti ELF per le librerie condivise

Per tutte le librerie condivise, verifica che i segmenti ELF delle librerie condivise siano allineati correttamente utilizzando l'allineamento ELF a 16 KB. Se sviluppi su Linux o macOS, puoi utilizzare lo script check_elf_alignment.sh come descritto nella sezione seguente. Puoi anche utilizzare direttamente gli strumenti a riga di comando.

Utilizza lo script check_elf_alignment.sh (Linux o macOS)

Segui questi passaggi per controllare l'allineamento dei segmenti ELF utilizzando lo script check_elf_alignment.sh:

1. Salva lo script check_elf_alignment.sh in un file.

2. Esegui lo script sul file APK della tua app:

   check_elf_alignment.sh APK_NAME.apk
   

   Lo script restituisce ALIGNED o UNALIGNED per tutte le librerie condivise arm64-v8a.

3. Se una delle librerie condivise arm64-v8a o x86_64 è UNALIGNED, devi aggiornare il packaging di queste librerie, poi ricompilare la tua app e ripetere il test seguendo i passaggi descritti in questa sezione.

Utilizzare direttamente gli strumenti a riga di comando

Segui questi passaggi per controllare l'allineamento dei segmenti ELF utilizzando direttamente gli strumenti a riga di comando:

1. Assicurati che sia installata la versione 35.0.0 o successive di Android SDK Build-Tools e l'Android NDK utilizzando SDK Manager in Android Studio o lo strumento a riga di comando sdkmanager.

2. Estrai il file APK dell'app:

   Linux o macOS

   unzip APK_NAME.apk -d /tmp/my_apk_out
   

   Windows (PowerShell)

   Expand-Archive -Path .\APK_NAME.apk -DestinationPath ~\tmp\my_apk_out
   

3. Nella directory temporanea in cui hai estratto il file APK, controlla i contenuti della directory lib per i file di oggetti condivisi (.so). Si tratta degli stessi file oggetto condivisi che avresti visto durante l'identificazione delle librerie native utilizzando Strumento di analisi APK. Esegui il comando seguente su ogni file oggetto condiviso:

   Linux o macOS

   SDK_ROOT_LOCATION/Android/sdk/ndk/NDK_VERSION/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-objdump -p SHARED_OBJECT_FILE.so | grep LOAD
   

   Windows (PowerShell)

   SDK_ROOT_LOCATION\Android\sdk\ndk\NDK_VERSION\toolchains\llvm\prebuilt\windows-x86_64\bin\llvm-objdump.exe -p SHARED_OBJECT_FILE.so | Select-String -Pattern "LOAD"
   

   Dove SDK_ROOT_LOCATION è il percorso della directory in cui hai installato l'SDK Android, SHARED_OBJECT_FILE è il nome dell'oggetto condiviso che stai controllando e NDK_VERSION è la versione dell'Android NDK che hai installato (ad esempio, 28.0.12433566). L'output sarà simile al seguente per ogni file che controlli:

   LOAD off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**14
   LOAD off    0x0000000000042a90 vaddr 0x0000000000043a90 paddr 0x0000000000043a90 align 2**14
   LOAD off    0x0000000000046230 vaddr 0x0000000000048230 paddr 0x0000000000048230 align 2**14
   

4. Controlla le righe di output per assicurarti che i segmenti di carico non abbiano valori inferiori a 2**14. Se uno dei segmenti di caricamento ha valori 2**13, 2**12 o inferiori, dovrai aggiornare il packaging di queste librerie, quindi ricompilare l'app e ripetere il test seguendo i passaggi descritti in questa sezione.

5. Successivamente, esegui lo strumento a riga di comando zipalign sul file APK della tua app:

   Linux o macOS

   SDK_ROOT_LOCATION/Android/sdk/build-tools/35.0.0/zipalign -v -c -P 16 4 APK_NAME.apk
   

   Windows (PowerShell)

   SDK_ROOT_LOCATION\Android\sdk\build-tools\35.0.0\zipalign.exe -v -c -P 16 4 APK_NAME.apk
   

   dove SDK_ROOT_LOCATION è il percorso della directory in cui hai installato l'SDK Android e APK_NAME è il nome del file APK della tua app. L'ultima riga dell'output indicherà "Verifica riuscita" se tutte le librerie condivise sono allineate correttamente.

   Se la verifica non è riuscita, alcune librerie condivise devono essere riallineate, quindi dovrai aggiornare il packaging di queste librerie, poi ricompilare l'app e ripetere il test seguendo i passaggi descritti in questa sezione.

Controllare il flag di sicurezza RELRO

Per mitigare gli exploit di sicurezza, i linker moderni utilizzano il flag Relocation Read-Only (RELRO) per rendere le sezioni di rilocazione del file oggetto condiviso di sola lettura dopo il caricamento. Attiva il flag RELRO nella tua build.

Una sezione RELRO con un indirizzo iniziale più la dimensione del segmento (MemSize) che non è allineata a 16 KB causa l'arresto anomalo dell'app in fase di runtime con un errore di segmentazione. Ciò si verifica se il file .so è stato creato con la toolchain NDK r27 e versioni precedenti senza attivare i flag pertinenti.

Esegui il seguente comando su ogni file oggetto condiviso (Linux o macOS):

SDK_ROOT_LOCATION/Android/sdk/ndk/NDK_VERSION/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-readelf -Wl SHARED_OBJECT_FILE.so | grep 'RELRO\|Type'

La stringa GNU_RELRO viene stampata se è presente un segmento RELRO.

Successivamente, controlla l'allineamento del segmento RELRO sommando l'indirizzo di offset virtuale (VirtAddr) con la dimensione della memoria del segmento (MemSiz) e dividendo per 16 kB (0x4000). Se il resto (modulo) è zero, il segmento RELRO è allineato a 16 KB.

Ecco un esempio di file .so non allineato:

Type           Offset   VirtAddr           PhysAddr           FileSiz MemSiz  Flg Align  
GNU_RELRO      0x0cfaf0 0x00000000000dfaf0 0x00000000000dfaf0 0x01510 0x01510 R   0x1

Formula: (VirtAddr + MemSiz) % 0x4000 == 0

Risultato: (0xdfaf0 + 0x01510) % 0x4000 = 0xE1000 % 0x4000 == 0x1000

Poiché 0x1000 non è zero, libbad.so non è conforme a 16 kB. L'intervallo di protezione RELRO da DC000 (l'interruzione di pagina precedente) a E4000 è di sola lettura, ma Android Linker prevede che il sottointervallo da E1000 a E4000 sia scrivibile, il che comporta un errore di segmentazione. In questo caso, ricompila il file .so come descritto nella sezione Compila la tua app utilizzando l'allineamento ELF a 16 kB.

Ecco un esempio di file .so allineato, con un segmento RELRO:

Type           Offset   VirtAddr           PhysAddr           FileSiz MemSiz  Flg Align
GNU_RELRO      0x0cfaf0 0x00000000000dfaf0 0x00000000000dfaf0 0x01510 0x00510 R   0x1  

Crea la tua app con il supporto per i dispositivi a 16 kB

Se la tua app utilizza codice nativo, completa i passaggi descritti nelle sezioni seguenti per assicurarti che supporti i dispositivi da 16 KB:

1. Aggiornare il packaging delle librerie condivise
2. Compila l'app utilizzando l'allineamento ELF a 16 kB
3. Correggere il codice e risolvere i problemi di runtime
4. Ottimizza gli allocatori di memoria personalizzati (se applicabile)
5. Controllare gli SDK per il supporto di 16 kB

Aggiornare il packaging delle librerie condivise

Esegui l'upgrade ad AGP versione 8.5.1 o successive e utilizza librerie condivise non compresse.

Utilizzare bundletool per verificare l'allineamento del file zip

Per visualizzare l'allineamento del bundle, utilizza:

bundletool dump config --bundle=<my .aab>  | grep alignment

Se vedi PAGE_ALIGNMENT_16K, significa che le richieste del bundle prevedono l'allineamento zip di 16 KB. Se vedi PAGE_ALIGNMENT_4K, l'APK creato da questo AAB deve avere file .so allineati a 4 KB nel file zip.

Versione 8.5.1 o successive di AGP

I dispositivi da 16 kB richiedono che le app fornite con librerie condivise non compresse le allineino a un limite allineato con zip di 16 kB. Per farlo, devi eseguire l'upgrade alla versione 8.5.1 o successive del plug-in Android per Gradle (AGP). Per informazioni dettagliate sulla procedura di upgrade, consulta la sezione Assistente all'upgrade del plug-in Gradle per Android.

Versione AGP 8.5 o precedenti

Se non riesci a eseguire l'upgrade di AGP alla versione 8.5.1 o successive, l'alternativa è passare all'utilizzo di librerie condivise compresse. Aggiorna la configurazione di Gradle in modo che Gradle comprima le librerie condivise durante il packaging dell'app per evitare problemi di installazione dell'app con librerie condivise non allineate.

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging true
      }
  }
}

android {
  ...
  packagingOptions {
      jniLibs {
        useLegacyPackaging = true
      }
  }
}

Versione AGP 8.0 o precedente

Se utilizzi una versione di AGP uguale o precedente alla 8.0, devi anche disattivare l'opzione per le librerie native non compresse per gli App Bundle nel file gradle.properties:

android.bundle.enableUncompressedNativeLibs=false

Compila l'app utilizzando l'allineamento ELF a 16 kB

Per l'esecuzione dell'app, i dispositivi da 16 kB richiedono che i segmenti ELF delle librerie condivise siano allineati correttamente utilizzando l'allineamento ELF a 16 kB.

Per gli sviluppatori di giochi, se il tuo gioco viene eseguito su motore grafico Unity, consulta la guida di Unity. Se il tuo gioco viene eseguito sul motore grafico Unreal, fai riferimento alla guida di Unreal.Per i motori grafici nativi, continua con questa guida.

Per compilare l'app utilizzando l'allineamento ELF a 16 KB, completa i passaggi in una delle sezioni seguenti a seconda della versione di Android NDK che stai utilizzando.

Android NDK r28 e versioni successive

NDK versione r28 e successive vengono compilate con allineamento a 16 KB per impostazione predefinita.

Android NDK r27 e versioni precedenti

Per supportare la compilazione di librerie condivise allineate a 16 KB con Android NDK versione r27 o precedente, utilizza i seguenti flag del linker:

-Wl,-z,max-page-size=16384
-Wl,-z,common-page-size=16384

Ecco come aggiornare i file di configurazione del sistema di compilazione:

LOCAL_LDFLAGS += -Wl,-z,max-page-size=16384 -Wl,-z,common-page-size=16384

target_link_options(${CMAKE_PROJECT_NAME} PRIVATE
    "-Wl,-z,max-page-size=16384"
    "-Wl,-z,common-page-size=16384"
)

Correggere il codice e risolvere i problemi di runtime

Anche se la tua app è allineata a 16 kB, può riscontrare errori se in alcuni punti del codice si presuppone che un dispositivo utilizzi dimensioni di pagina specifiche. Per evitare questo problema, completa i seguenti passaggi:

1. Rimuovi eventuali dipendenze hardcoded che fanno riferimento alla costante PAGE_SIZE o alle istanze nella logica del codice che presuppongono che la dimensione della pagina di un dispositivo sia 4 KB (4096).

   Utilizza invece getpagesize() o sysconf(_SC_PAGESIZE).

2. Cerca gli utilizzi di mmap() e di altre API che richiedono argomenti allineati alla pagina e sostituiscili con alternative, se necessario.

In alcuni casi, se la tua app utilizza PAGE_SIZE come valore pratico non associato alle dimensioni della pagina sottostante, ciò non causerà l'interruzione del funzionamento dell'app quando viene utilizzata in modalità a 16 kB. Tuttavia, se questo valore viene passato al kernel con mmap senza MAP_FIXED, il kernel utilizza comunque un'intera pagina, il che spreca un po' di memoria. Per questi motivi, PAGE_SIZE non è definito quando la modalità 16 KB è attivata su NDK r27 e versioni successive.

Se la tua app utilizza PAGE_SIZE in questo modo e non passa mai direttamente questo valore al kernel, anziché utilizzare PAGE_SIZE, crea una nuova variabile con un nuovo nome per indicare che viene utilizzata per altri scopi e non riflette una pagina di memoria reale.

Ottimizzare gli allocatori di memoria personalizzati

Sui sistemi da 16 KB, l'unità più piccola di memoria fisica allocata dal sistema operativo è quattro volte più grande rispetto ai sistemi da 4 KB. Se un allocatore personalizzato è stato progettato in base a presupposti di 4 KB, può distribuire piccoli oggetti su più pagine da 16 KB e conservare inutilmente la memoria vuota. Ciò può aumentare notevolmente l'utilizzo della memoria fisica (RSS) e ridurre l'efficienza dello swap compresso (ZRAM).

Se il tuo codice gestisce i propri pool di memoria, segui questi consigli:

1. Evita le soglie di byte hardcoded per liberare memoria

Molti allocatori utilizzano limiti di byte fissi per decidere quando rilasciare la memoria al sistema operativo utilizzando madvise(MADV_DONTNEED) (ad esempio, rilascia la memoria solo se gli oggetti attivi occupano meno di 8 KB).

In un sistema da 16 KB, anche un singolo oggetto live da 16 byte blocca un'intera pagina da 16 KB (che è maggiore di 8 KB). Di conseguenza, la soglia di rilascio non viene mai raggiunta e l'allocatore non restituisce mai la memoria inutilizzata circostante al kernel.

Cosa fare: non utilizzare mai costanti di byte hardcoded per l'euristica di rilascio delle pagine. Scala dinamicamente le soglie di rilascio in fase di runtime in base alle dimensioni effettive della pagina utilizzando sysconf(_SC_PAGESIZE).

2. Riempi prima le pagine già utilizzate (allocazione densa)

Se un allocatore distribuisce la memoria in ordine FIFO (first-in-first-out) o round robin, le nuove allocazioni vengono distribuite su molte pagine da 16 KB parzialmente riempite. Un singolo oggetto in una pagina mantiene tutti i 16 KB residenti nella RAM fisica.

Cosa fare: alloca sempre nuovi oggetti dalla pagina o dal blocco più pieno (più denso) prima di toccare pagine vuote o poco utilizzate. Concentrando le nuove allocazioni sulle pagine già sporche, le pagine poco utilizzate possono essere svuotate naturalmente fino a zero oggetti attivi, in modo che l'intera pagina da 16 KB possa essere rilasciata al sistema operativo.

3. Allinea i pool di memoria a 16 KB e mantieni le dimensioni dei pool moderate

Gli intervalli multipagina progettati per i sistemi da 4 KB possono contenere un'eccessiva memoria non rilasciata sui kernel da 16 KB. Inoltre, le classi di dimensioni che non si dividono in modo uniforme in 16 KB causano la frammentazione alla fine di ogni pagina.

Cosa fare:

• Assicurati che tutti i pool di memoria, i limiti dei blocchi e gli allineamenti dei buffer siano multipli esatti delle dimensioni della pagina di runtime.
• Rivaluta le dimensioni degli intervalli di più pagine per le classi di oggetti di piccole dimensioni per evitare di allocare slab eccessivamente grandi che intrappolano la memoria inattiva.

4. Rilascia immediatamente la memoria fisica per i buffer di grandi dimensioni memorizzati nella cache

Gli allocatori personalizzati spesso memorizzano nella cache buffer di grandi dimensioni (> 64 KB) in un pool in memoria in modo che possano essere riutilizzati senza pagare l'overhead delle chiamate di sistema mmap o munmap. Tuttavia, mantenere questi buffer modificati in memoria spreca megabyte di RAM fisica in attesa di un timer di espulsione.

Cosa fare: mantieni l'intervallo di indirizzi della memoria virtuale riservato per un rapido riutilizzo, ma chiama madvise(..., MADV_DONTNEED) o madvise(..., MADV_FREE) immediatamente quando restituisci un buffer alla cache. Il sistema operativo recupera immediatamente la RAM fisica, mentre la tua app può riutilizzare immediatamente l'indirizzo virtuale senza riallocarlo.

5. Azzera la memoria libera anziché quella allocata per la compressione ZRAM

Android utilizza lo swap compresso (ZRAM) per mantenere le app in background in memoria. Sui dispositivi da 16 KB, se una pagina contiene anche un solo oggetto attivo, l'intera pagina da 16 KB rimane residente o viene scambiata con ZRAM. I dati spazzatura rimanenti (come puntatori e stringhe obsoleti) nelle parti della pagina liberate in precedenza vengono compressi male.

Se l'allocatore azzera la memoria (ad esempio per la sicurezza o le allocazioni inizializzate a zero), valuta la possibilità di azzerare la memoria al momento della deallocazione (free()) anziché al momento dell'allocazione:

• Le pagine bloccate costano meno:la memoria inattiva sulle pagine da 16 KB parzialmente riempite viene compressa quasi completamente in ZRAM, quindi le pagine bloccate non sprecano spazio di swap fisico.
• Overhead della cache minimo:al momento della chiamata di free(), la memoria è già calda nella cache della CPU, evitando ulteriori fallimenti della cache in un secondo momento.

Riepilogo dei consigli

Controlla gli SDK per il supporto di 16 kB

Molti SDK sono compatibili con le dimensioni delle pagine di 16 KB, soprattutto se li crei tu stesso o se utilizzi versioni precompilate recenti. Tuttavia, poiché alcuni SDK precompilati o versioni dell'SDK non sono compatibili con 16 KB, devi controllare il sito web di ogni provider di SDK per determinare quale versione utilizzare con 16 KB.

Testare l'app in un ambiente da 16 kB

Dopo aver creato la tua app con il supporto per i dispositivi da 16 kB, ti consigliamo di testarla in un ambiente da 16 kB per verificare se si verificano regressioni. A questo scopo, procedi nel seguente modo:

1. Configura l'SDK Android 15 o versioni successive.

2. Configura uno dei seguenti ambienti di test:

   • Configurare l'emulatore Android con un'immagine di sistema Android 15 basata su 16 KB
   • Utilizzare Cuttlefish con dimensioni pagina di 16 KB su ARM64
   • Simulare Cuttlefish con dimensioni pagina di 16 kB su x86-64
   • Attivare la modalità a 16 kB su un dispositivo utilizzando le opzioni sviluppatore
   • Utilizzare Samsung Remote Test Lab su 16 KB dispositivi supportati

3. Avvia il dispositivo di test, quindi esegui il comando seguente per verificare che utilizzi un ambiente di 16 KB:

   adb shell getconf PAGE_SIZE
   

   Il comando deve restituire un valore pari a 16384.

4. Esegui il seguente comando zipalign per verificare che la tua app sia allineata a 16 KB, dove APK_NAME è il nome del file APK della tua app:

   zipalign -c -P 16 -v 4 APK_NAME.apk
   

5. Testa attentamente la tua app, concentrandoti su tutte le aree che potrebbero essere interessate da modifiche alle istanze di codice che fanno riferimento a dimensioni specifiche delle pagine.

Configura l'emulatore Android con un'immagine di sistema basata su 16 KB

Per configurare un ambiente da 16 kB utilizzando l'emulatore Android, segui questi passaggi:

1. In Android Studio, fai clic su Strumenti > SDK Manager.

2. Nella scheda Piattaforme SDK, seleziona Mostra dettagli pacchetto, quindi espandi la sezione Android VanillaIceCream o versioni successive e seleziona una o entrambe le seguenti immagini di sistema dell'emulatore, a seconda dei dispositivi virtuali che vuoi creare:

   • Immagine di sistema sperimentale ARM 64 v8a di 16 kB per le API di Google
   • API di Google sperimentali con dimensioni delle pagine di 16 kB per sistema Intel x86_64 Atom Immagine

   

3. Fai clic su Applica > OK per scaricare le immagini di sistema selezionate.

4. Segui i passaggi per configurare un dispositivo virtuale per Android 15 e, quando ti viene chiesto di selezionare un'immagine di sistema, seleziona l'immagine di sistema da 16 KB che hai scaricato. Se non viene consigliata automaticamente, puoi trovare l'immagine di sistema da 16 KB nella scheda Altre immagini.

   

Avviare l'emulatore

Dopo aver completato la configurazione dell'emulatore Android e dei dispositivi virtuali, avvia l'emulatore dal menu del dispositivo di destinazione o dalla riga di comando.

Attivare la modalità a 16 kB su un dispositivo utilizzando le opzioni sviluppatore

Attiva l'opzione per sviluppatori Avvia con dimensione pagina 16 kB per avviare un dispositivo in modalità a 16 kB.

Nelle versioni QPR di Android 15, puoi utilizzare l'opzione sviluppatore disponibile su alcuni dispositivi per avviare il dispositivo in modalità 16 KB ed eseguire test sul dispositivo. Prima di utilizzare l'opzione sviluppatore, vai a Impostazioni > Sistema > Aggiornamenti software e applica gli aggiornamenti disponibili.

Questa opzione per sviluppatori è disponibile sui seguenti dispositivi:

• Pixel 8 e 8 Pro (con Android 15 QPR1 o versioni successive)

• Pixel 8a (con Android 15 QPR1 o versioni successive)

• Pixel 9, 9 Pro e 9 Pro XL (con Android 15 QPR2 o versioni successive)

• Pixel 9a (con Android 16 o versioni successive)

Modalità di compatibilità con le versioni precedenti a 16 kB

Avviso in modalità di compatibilità con le dimensioni pagina

L'opzione di compatibilità con le versioni precedenti a 16 kB è disponibile quando un dispositivo è in esecuzione con un kernel a 16 kB. Il gestore dei pacchetti esegue un'app in modalità di compatibilità con le versioni precedenti a 16 KB quando vengono soddisfatte le seguenti condizioni:

• Se l'app ha file ELF (con estensione .so) con un allineamento del segmento LOAD di 4 KB.
• Se l'APK compresso contiene file ELF non compressi di 4 KB allineati a ZIP.

Se il gestore di pacchetti ha attivato la modalità di compatibilità con le versioni precedenti a 16 kB per un'app, l'app mostra un avviso al primo avvio che indica che è in esecuzione in modalità di compatibilità con le versioni precedenti a 16 kB.

La modalità di compatibilità con le versioni precedenti a 16 kB consente il funzionamento di alcune app, ma per una migliore affidabilità e stabilità, le app devono comunque essere allineate a 16 kB.

Nella pagina delle informazioni sull'app, in Avanzate, attiva o disattiva l'impostazione Esegui app con modalità compatibilità dimensioni pagina per attivare o disattivare la modalità di compatibilità con le versioni precedenti a 16 kB per un'app specifica. Questa impostazione è visibile solo quando il dispositivo è in esecuzione con dimensioni pagina di 16 kB.

Impostazione della modalità di compatibilità delle dimensioni della pagina

Per forzare la compatibilità con le versioni precedenti a 16 kB per ogni app sul dispositivo:

adb shell setprop bionic.linker.16kb.app_compat.enabled true
adb shell setprop pm.16kb.app_compat.disabled false

Per disattivare la compatibilità con le versioni precedenti a 16 KB per ogni app sul dispositivo:

adb shell setprop bionic.linker.16kb.app_compat.enabled false
adb shell setprop pm.16kb.app_compat.disabled true

In Android 17, puoi anche disattivare la compatibilità con le versioni precedenti di 16 kB per ogni app e far sì che qualsiasi file binario incompatibile venga interrotto immediatamente:

    adb shell setprop bionic.linker.16kb.app_compat.enabled fatal
    adb shell setprop pm.16kb.app_compat.disabled true

Imposta la proprietà android:pageSizeCompat su attivata o disattivata per attivare o disattivare la modalità di compatibilità con le versioni precedenti per un'app specifica nel relativo AndroidManifest.xml. Quando questa proprietà è impostata, l'app non visualizza avvisi relativi alla modalità di compatibilità con le versioni precedenti all'avvio.