Supporta architetture a 64 bit

Le app pubblicate su Google Play devono supportare Architetture a 64 bit. Aggiunta di una versione a 64 bit dell'app offre miglioramenti delle prestazioni e consente di configurare i dispositivi con un'architettura a 64 bit hardware.

I passaggi seguenti assicurano che la tua app a 32 bit supporti i dispositivi a 64 bit.

Valuta la tua app

Se la tua app utilizza soltanto codice scritto nel linguaggio di programmazione Java o in Kotlin, incluse tutte le librerie o tutti gli SDK, significa che la tua app supporta i dispositivi a 64 bit. Se la tua app utilizza un codice nativo o non hai la certezza che lo sia, valuta dell'app.

Controllo rapido dello stato

Accedi a Play Console e dai un'occhiata alle release esistenti per capire se sono conformi.

Play Console mostra anche avvisi relativi alle bozze delle release, se: eventuali problemi legati al requisito dei 64 bit. L'immagine seguente è un esempio.

Se viene visualizzato un avviso, segui questa procedura per rendere compatibile l'app con Dispositivi a 64 bit.

La tua app utilizza codice nativo?

La tua app utilizza il codice nativo se:

• Utilizza qualsiasi codice C/C++ (nativo) nella tua app.
• Collegamenti a eventuali librerie native di terze parti.
• È creato da uno strumento per la creazione di app di terze parti che utilizza librerie native.

La tua app include librerie a 64 bit?

Controlla la struttura del file APK. Una volta creato, l'APK è pacchettizzato con qualsiasi le librerie native richieste dall'app. Le librerie native sono archiviate in vari in base all'ABI. Non è necessario supportare ogni a 64 bit, ma per ogni architettura nativa a 32 bit supportata deve includere la corrispondente architettura a 64 bit.

Per l'architettura ARM, le librerie a 32 bit si trovano in armeabi-v7a. L'equivalente a 64 bit è arm64-v8a.

Per l'architettura x86, cerca x86 per 32 bit e x86_64 per 64 bit.

Assicurati di avere librerie native in entrambe le cartelle. Riepilogo:

Tieni presente che, a seconda dell'app, potrebbe esserci o meno lo stesso insieme di librerie in ogni cartella. L'obiettivo è garantire che l'app venga eseguita correttamente in un ambiente solo a 64 bit.

In un caso tipico, un APK o bundle realizzato per entrambi i sistemi a 32 e 64 bit ha cartelle per entrambe le ABI, ciascuna con un insieme corrispondente di librerie. Se non è disponibile il supporto per il formato a 64 bit, potresti visualizzare una cartella ABI a 32 bit ma non una cartella a 64 bit.

Cerca le librerie native usando l'Analizzatore APK

Lo Strumento di analisi APK consente di valutare vari aspetti di un APK creato. Utilizzala per trovare le librerie native e assicurati che l'architettura librerie sono presenti.

1. Apri Android Studio e apri un progetto.

2. Dal menu, seleziona Crea > Analizza APK...

   

3. Scegli l'APK che vuoi valutare.

4. Cerca nella cartella lib che ospita il file ".so". file esistenti. Se ci sono nessuno, la tua app supporta i dispositivi a 64 bit e non dovrai fare nient'altro obbligatorio. Se vedi armeabi-v7a o x86, allora hai librerie.

5. Verifica se hai un file ".so" simile in arm64-v8a o x86_64.

   

6. Se non hai librerie arm64-v8a o x86_64, aggiorna per iniziare a creare e pacchettizzare questi artefatti nel tuo APK.

7. Se vedi già che entrambe le librerie sono pacchettizzate, puoi passare direttamente testare l'app su hardware a 64 bit.

Cerca le librerie native decomprimendo gli APK

I file APK sono strutturati come file ZIP. Con la riga di comando o qualsiasi altra strumento di estrazione, estrai il file APK. A seconda dello strumento di estrazione, potrebbe essere necessario rinominare il file in .zip.

Sfoglia i file estratti, seguendo le indicazioni riportate sopra per determinare se la tua app supporta dispositivi a 64 bit. Puoi eseguire questo esempio di comando dalla riga di comando:

:: Command Line
> zipinfo -1 YOUR_APK_FILE.apk | grep \.so$
lib/armeabi-v7a/libmain.so
lib/armeabi-v7a/libmono.so
lib/armeabi-v7a/libunity.so
lib/arm64-v8a/libmain.so
lib/arm64-v8a/libmono.so
lib/arm64-v8a/libunity.so

In questo esempio, tieni presente la presenza di armeabi-v7a e arm64-v8a il che significa che l'app supporta architetture a 64 bit.

Crea la tua app con librerie a 64 bit

Le seguenti istruzioni spiegano come creare librerie a 64 bit. Tieni presente che questi passaggi riguardano solo la creazione di codice e librerie che sei in grado di creare dall'origine.

Crea con Android Studio o Gradle

La maggior parte dei progetti Android Studio utilizza Gradle come sistema di build sottostante, si applica a entrambi i casi. Per abilitare le build per il codice nativo, aggiungi arm64-v8a e/o x86_64, a seconda delle architetture che vuoi assistenza, all'impostazione ndk.abiFilters nel pannello "build.gradle" file:

// Your app's build.gradle
plugins {
  id 'com.android.app'
}

android {
   compileSdkVersion 27
   defaultConfig {
       appId "com.google.example.64bit"
       minSdkVersion 15
       targetSdkVersion 28
       versionCode 1
       versionName "1.0"
       ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'
// ...

// Your app's build.gradle
plugins {
    id("com.android.app")
}

android {
    compileSdkVersion(27)
    defaultConfig {
        appId = "com.google.example.64bit"
        minSdkVersion(15)
        targetSdkVersion(28)
        versionCode = 1
        versionName = "1.0"
        ndk {
            abiFilters += listOf("armeabi-v7a","arm64-v8a","x86","x86_64")
        }
// ...

Crea con CMake

Se la tua app è stata creata usando CMake, puoi creare contenuti per modelli a 64 bit ABI trasmettendo il arm64-v8a in "-DANDROID_ABI" :

:: Command Line
> cmake -DANDROID_ABI=arm64-v8a … or
> cmake -DANDROID_ABI=x86_64 …

Crea con ndk-build

Se la tua app è creata con ndk-build, puoi creare per ABI a 64 bit modificando il file "Application.mk" utilizzando la variabile APP_ABI:

APP_ABI := armeabi-v7a arm64-v8a x86 x86_64

Porta il codice da 32 bit a 64 bit

Se il codice viene già eseguito su computer o iOS, non è necessario di lavoro extra per Android. Se è la prima volta che crei il codice per un nel sistema a 64 bit, il problema principale da risolvere è che i cursori non rientrano più Tipi di numeri interi a 32 bit come int.

Aggiorna il codice che archivia i puntatori in tipi quali int, unsigned o uint32_t. Nei sistemi Unix, long corrisponde alla dimensione del puntatore, ma non è true su Windows. Usa invece i tipi che rivelano l'intenzione uintptr_t o intptr_t. Per memorizzare la differenza tra due puntatori, usa l'ptrdiff_t di testo.

Dovresti sempre preferire i tipi di numeri interi a larghezza fissa specifici definiti in <stdint.h> anziché tipi a larghezza non fissa come int o long, anche per i non puntatore.

Usa i seguenti flag del compilatore per rilevare i casi in cui il codice non è corretto Convertitori tra puntatori e numeri interi:

-Werror=pointer-to-int-cast
-Werror=int-to-pointer-cast
-Werror=shorten-64-to-32

Le classi Java con campi int che contengono puntatori a oggetti C/C++ hanno lo stesso problema. Cerca jint nell'origine JNI e assicurati di passare a long sul lato Java e jlong sul lato C++.

Le dichiarazioni di funzioni implicite sono molto più pericolose per il codice a 64 bit. C/C++ presupporre che il tipo restituito di una funzione implicitamente dichiarata (ovvero funzione per cui il compilatore non ha visto una dichiarazione) è int. Se il tipo restituito effettivo della funzione è un puntatore, questo funziona bene su un controller in cui il puntatore si inserisce in un valore intero. Tuttavia, su un sistema a 64 bit, il compilatore scarta la metà superiore del puntatore. Ad esempio:

// This function returns a pointer:
// extern char* foo();

// If you don't include a header that declares it,
// when the compiler sees this:
char* result = foo();

// Instead of compiling that to:
result = foo();

// It compiles to something equivalent to:
result = foo() & 0xffffffff;

// Which will then cause a SIGSEGV if you try to dereference `result`.

Il seguente flag del compilatore trasforma gli avvisi di dichiarazione di funzione implicita in in modo che tu possa individuare e risolvere il problema più facilmente:

-Werror=implicit-function-declaration

Se disponi di un assemblatore in linea, riscrivilo o utilizza una semplice implementazione C/C++.

Se i tipi di dimensioni sono hardcoded (ad esempio 8 o 16 byte), sostituiscili con l'espressione sizeof(T) equivalente, ad esempio sizeof(void*).

Se devi compilare in modo condizionale un codice diverso per è possibile utilizzare #if defined(__LP64__) per differenze generiche 32/64 oppure __arm__, __aarch64__ (arm64), __i386__ (x86) e __x86_64__ per lo specifico supportate da Android.

Regola le stringhe di formato per le funzioni di tipo printf o scanf, come avviene di formato non consentono di specificare i tipi a 64 bit con il corretto sia per i dispositivi a 32-bit che per quelli a 64-bit. Le macro PRI e SCN in <inttypes.h> risolvono il problema, PRIxPTR e SCNxPTR per la scrittura e la lettura dei puntatori esadecimali, e PRId64 e SCNd64 per aver scritto e per leggere i valori a 64 bit in modo portabile.

Durante lo spostamento, potrebbe essere necessario usare 1ULL per ottenere una costante a 64 bit per lo spostamento anziché utilizzare 1, che è di soli 32 bit.

Riduci l'aumento delle dimensioni con Android App Bundle

L'aggiunta del supporto dell'architettura a 64 bit alla tua app può aumentare le dimensioni dell'APK. Ti consigliamo vivamente di sfruttare Funzionalità Android App Bundle per ridurre al minimo l'impatto sulle dimensioni di inclusi il codice nativo a 32 e a 64 bit nello stesso APK.

Sviluppatori di giochi

I tre motori più utilizzati supportano il formato a 64 bit:

• Fantastico dal 2015
• Cocos2d dal 2015
• Unity dal 2018

Sviluppatori Unity

Esegui l'upgrade alle versioni supportate

Unity fornisce il supporto a 64 bit con le versioni 2018.2 e 16/04/2017.

Se utilizzi una versione di Unity che non supporta il formato a 64 bit, determina il a cui vuoi eseguire l'upgrade e segui le guide disponibili Unity ti fornisce la possibilità di eseguire la migrazione del tuo ambiente, per fare in modo che venga eseguito l'upgrade dell'app a un in grado di creare librerie a 64 bit. Unity ti consiglia di accedere ai Funzionalità e aggiornamenti più recenti eseguendo l'upgrade alla versione LTS più recente all'ultima versione dell'editor.

Ecco un grafico che illustra le varie versioni di Unity e cosa devi fare:

Modifica le impostazioni della build per produrre librerie a 64 bit

Se utilizzi una versione di Unity che supporta le librerie Android a 64 bit, Puoi generare una versione a 64 bit della tua app modificando le impostazioni della build. Utilizza le funzionalità di il backend IL2CPP come backend di script. Per configurare il tuo progetto Unity per creare un'architettura a 64 bit:

1. Vai a Impostazioni build e assicurati di creare per Android entro il verificando che il simbolo Unity sia visibile accanto ad Android nella sezione Piattaforma. 1. Se il simbolo Unity non si trova accanto alla piattaforma Android, Seleziona Android e fai clic su Cambia piattaforma.

2. Fai clic su Impostazioni player.

   

3. Vai al riquadro Impostazioni del player > Impostazioni per Android > Altro impostazioni > Configurazione

4. Imposta Backend di script su IL2CPP.

5. Seleziona Architettura di destinazione > ARM64.

   

6. Costruisci come di consueto!

Tieni presente che per sviluppare ARM64 tutti gli asset devono essere creati appositamente per quella piattaforma. Segui le linee guida di Unity per ridurre gli APK dimensione e valuta di sfruttare Funzionalità Android App Bundle per contribuire a mitigare questo aumento di dimensioni.

APK multiplo e conformità a 64 bit

Se utilizzi il supporto degli APK multipli di Google Play per: pubblichi l'app, tieni presente che viene valutata la conformità al requisito dei 64 bit a livello di release. Tuttavia, il requisito dei 64 bit non si applica agli APK o app bundle non distribuiti su dispositivi con Android 9 Pie o versioni successive.

Se uno dei tuoi APK è contrassegnato come non conforme, ma è una versione precedente e non è possibile renderla conforme, una strategia consiste nell'aggiungere Attributo maxSdkVersion="27" nell'elemento uses-sdk in al file manifest dell'APK. Questo APK non è disponibile sui dispositivi con Android 9 Pie o successiva e non blocca più la conformità.

RenderScript e conformità a 64 bit

Se la tua app utilizza RenderScript ed è stata creata con una versione precedente di Potresti riscontrare problemi di conformità della versione a 64 bit per l'app Android. Con build precedenti alla versione 21.0.0, il compilatore potrebbe generare bitcode in un .bc. Questi file .bc precedenti non sono più supportati per il formato a 64 bit di sistema, pertanto la presenza del file nell'APK determina la conformità problema.

Per risolvere il problema, rimuovi tutti i .bc file del progetto, esegui l'upgrade su build-tools-21.0.0 o una versione successiva e imposta renderscriptTargetApi in Android Studio a 21+, al compilatore per non emettere i file .bc. Quindi, ricrea l'app, controlla se è presente .bc ed eseguire il caricamento su Play Console.

Testare l'app su hardware a 64 bit

La versione a 64 bit della tua app deve offrire la stessa qualità e lo stesso insieme di funzionalità di la versione a 32 bit. Testa la tua app per assicurarti che gli utenti utilizzino la versione a 64 bit più recente per i dispositivi possono avere un'esperienza ottimale con la tua app.

Dispositivi solo a 64 bit

Se possibile, ti consigliamo di testare l'app con il protocollo rigoroso solo a 64 bit utilizzando una delle seguenti opzioni:

• Google Pixel con un'immagine di sistema solo a 64 bit
• Emulatore Android

Google Pixel con un'immagine di sistema solo a 64 bit

Per facilitare lo sviluppo e i test delle app, abbiamo fornito immagini di sistema speciali. in un ambiente rigido solo a 64 bit per alcuni dispositivi Pixel. Queste istanze solo a 64 bit le immagini erano originariamente fornite in concomitanza con le immagini di sistema standard per le versioni in anteprima di Android 13 e 14, ma puoi continuare a usarle come devi testare la tua app per verificarne la compatibilità a 64 bit.

Ottieni un'immagine a 64 bit

Come per le immagini di sistema di fabbrica, puoi eseguire il flashing di un'immagine solo a 64 bit sul tuo dispositivo utilizzando lo strumento Android Flash o eseguire il flashing della manualmente, come descritto nelle sezioni che seguono.

Esegui il flashing del dispositivo con Android Flash Tool

Android Flash Tool consente di eseguire il flashing sicuro di un'immagine di sistema al tuo dispositivo Pixel supportato. Android Flash Tool funziona con qualsiasi browser web che supporti WebUSB, come Chrome o Edge 79 e versioni successive.

Android Flash Tool ti guida passo passo nella procedura di flashing dispositivo, non occorre installare strumenti, ma è necessario sbloccare il dispositivo e attiva Debug USB nelle Opzioni sviluppatore. Per istruzioni complete, vedi lo strumento Android Flash documentazione.

Quindi, collega il dispositivo tramite USB, a seconda del tipo di immagine di sistema che vuoi eseguire il flash, apri Android Flash Tool utilizzando uno dei seguenti link e segui le indicazioni sullo schermo:

• Immagini di sistema solo a 64 bit per Android 14 (beta 5.2)

  Seleziona il dispositivo che stai tentando di flashare:

  • Pixel 4a (5G)
  • Pixel 5
  • Pixel 6
  • Pixel 6 Pro

• Immagini di sistema solo a 64 bit per Android 13 (QPR3 Beta 3.2)

  Seleziona il dispositivo che stai tentando di flashare:

  • Pixel 4a (5G)
  • Pixel 5
  • Pixel 6
  • Pixel 6 Pro

Esegui il flashing manuale del dispositivo

Puoi anche scaricare l'ultima immagine di sistema e aggiornarla manualmente sul tuo dispositivo. Consulta la tabella seguente per scaricare l'immagine di sistema per il test dispositivo. Il flashing manuale di un dispositivo è utile se hai bisogno di un controllo preciso nell'ambiente di test o se devi reinstallarlo spesso, ad esempio quando eseguendo test automatici.

Dopo aver eseguito il backup dei dati del dispositivo e scaricato l'immagine di sistema corrispondente, può eseguire il flashing dell'immagine sul dispositivo.

Puoi scegliere di tornare all'ultima build pubblica in qualsiasi nel tempo.

Immagini di fabbrica solo a 64 bit per Android 14 (beta 5.3)

Queste immagini forniscono un ambiente rigido solo a 64 bit per testare un'app a 64 bit la compatibilità. Queste configurazioni solo a 64 bit sono destinate esclusivamente all'uso da parte degli sviluppatori.

Immagini di fabbrica solo a 64 bit per Android 13 (QPR3 Beta 3.2)

Queste immagini forniscono un ambiente rigido solo a 64 bit per testare un'app a 64 bit la compatibilità. Queste configurazioni solo a 64 bit sono destinate esclusivamente all'uso da parte degli sviluppatori.

Torna a una build pubblica

Puoi usare Android Flash Tool per eseguire il flashing dell'immagine di fabbrica oppure ottenere un sistema di specifiche di fabbrica immagine dalle immagini del produttore per dispositivi Nexus e Pixel e poi eseguirla manualmente sul dispositivo.

Emulatore Android

A partire da Android 12 (livello API 31), le immagini di sistema di Android Emulator sono a 64 bit . Creare un dispositivo virtuale Android utilizzando un sistema con Android 12 (livello API 31) o versioni successive per ottenere un'immagine rigorosa solo per i test delle app.

Altre opzioni dispositivo

Se non hai uno di questi dispositivi o non puoi utilizzare l'emulatore Android, la seconda opzione migliore è utilizzare un dispositivo che supporti la velocità a 64 bit, come un Pixel o altri dispositivi di punta recenti di altri produttori.

Installare e testare l'app

Il modo più semplice per testare l'APK è installare l'app utilizzando il debug di Android Ponte (adb). Nella maggior parte dei casi, puoi fornire --abi come parametro per indicare quali librerie installare sul dispositivo. L'app viene installata solo con librerie a 64 bit sul dispositivo.

:: Command Line
# A successful install:
> adb install --abi armeabi-v7a YOUR_APK_FILE.apk
Success

# If your APK does not have the 64-bit libraries:
> adb install --abi arm64-v8a YOUR_APK_FILE.apk
adb: failed to install YOUR_APK_FILE.apk: Failure [INSTALL_FAILED_NO_MATCHING_ABIS: Failed to extract native libraries, res=-113]

# If your device does not support 64-bit, an emulator, for example:
> adb install --abi arm64-v8a YOUR_APK_FILE.apk
ABI arm64-v8a not supported on this device

Dopo averla installata, testa l'app come faresti normalmente garantire che la qualità sia la stessa della versione a 32 bit.

Verificare la presenza di problemi di compatibilità noti

Durante il test, controlla se nell'app sono presenti i seguenti problemi che interessano le app quando in esecuzione su dispositivi a 64 bit. Anche se la tua app non dipende dal modello direttamente le librerie, le librerie e gli SDK di terze parti nelle dipendenze dell'app potrebbero.

SoLoader

Se utilizzi l'SDK del caricatore di codice nativo SoLoader, aggiorna alla versione 0.10.4 o successive. Se le tue utilizza SDK che dipendono da SoLoader, accertati di eseguire anche l'aggiornamento all'ultima versione stabile degli SDK interessati.

SoLoader v0.9.0 e versioni precedenti presuppongono che le librerie di sistema siano presenti /vendor/lib:/system/lib. Questo bug non è osservabile in dispositivi come Pixel 7 in cui esiste il percorso, ma questa ipotesi causa arresti anomali nei dispositivi che dispongono di librerie di sistema in /vendor/lib64:/system/lib64.

Per ulteriori informazioni su come risolvere questo e altri problemi causati da SoLoader, consulta risposta corrispondente nel Centro assistenza Google.

OpenSSL

Se utilizzi la libreria OpenSSL, esegui l'aggiornamento a OpenSSL 1.1.1i o versioni successive. Se la tua app utilizza SDK che forniscono comunicazione tramite HTTPS o altri SDK che dipende da OpenSSL, assicurati di eseguire l'aggiornamento alla versione più recente dell'SDK che utilizza una versione di OpenSSL più recente. Se non lo è, contatta il provider dell'SDK. disponibili.

Il PAC ARMv8.3 consente il controllo tramite hardware e l'integrità del flusso autenticando i puntatori in fase di runtime. Versioni precedenti di OpenSSL utilizza queste funzionalità in modo errato, causando arresti anomali del runtime in tutti dispositivi con processori basati su ARMv8.3a e versioni successive.

Per ulteriori informazioni sulla risoluzione di questo e altri problemi causati da OpenSSL, consulta la risposta corrispondente nel Centro assistenza Google.

IMC

ARMv8.5 e versioni successive usano le istruzioni Branch Target (BTI) per proteggere Attacchi JOP. Versioni precedenti dell'offuscamento Gli SDK che si diramano in offset casuali delle librerie create con BTI possono in modo anomalo. Poiché le istruzioni sono codificate come HINTs, questo bug non è osservabile nei dispositivi che non supportano BTI.

Pubblica

Quando ritieni che la tua app sia pronta, pubblicala normalmente. Come sempre, continua segui le best practice per il deployment della tua app. Ti consigliamo di di canali di test chiusi per l'implementazione per un numero limitato di per garantire una qualità coerente dell'app.

Al momento di implementare un aggiornamento importante, assicuratevi di aver testato I dispositivi con funzionalità a 64 bit prima della pubblicazione per un pubblico più ampio.