Questa pagina è stata tradotta dall'API Cloud Translation.

Supporta architetture a 64 bit

Le app pubblicate su Google Play devono supportare architetture a 64 bit. L'aggiunta di una versione a 64 bit dell'app offre miglioramenti delle prestazioni e consente di configurare i dispositivi con hardware solo a 64 bit.

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 solo codice scritto nel linguaggio di programmazione Java o in Kotlin, incluse tutte le librerie o tutti gli SDK, significa che supporta i dispositivi a 64 bit. Se la tua app utilizza codice nativo o non hai la certezza che lo sia, valuta l'app.

Controllo rapido dello stato

Vai a Play Console e controlla le release esistenti per verificare se sono conformi.

Play Console mostra anche avvisi relativi alle bozze delle release in caso di problemi relativi al requisito dei 64 bit. L'immagine seguente è un esempio.

Se viene visualizzato un avviso, segui la procedura riportata di seguito per rendere compatibile l'app con i 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 viene pacchettizzato con eventuali librerie native richieste dall'app. Le librerie native vengono archiviate in varie cartelle in base all'ABI. Non è necessario supportare ogni architettura a 64 bit, ma per ogni architettura nativa a 32 bit supportata devi includere l'architettura a 64 bit corrispondente.

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:

Piattaforma	Cartella delle librerie a 32 bit	Cartella delle librerie a 64 bit
ABILITA	`lib/armeabi-v7a`	`lib/arm64-v8a`
x86	`lib/x86`	`lib/x86_64`

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

In un caso tipico, un APK o bundle creato per architetture a 32 e 64 bit dispone di cartelle per entrambe le ABI, ciascuna con un set corrispondente di librerie native. Se il supporto per il formato a 64 bit non è disponibile, potresti vedere una cartella ABI a 32 bit, ma non una cartella a 64 bit.

Cerca le librerie native usando l'Analizzatore APK

Strumento di analisi APK è uno strumento che consente di valutare vari aspetti di un APK creato. Utilizzala per trovare eventuali librerie native e assicurati che siano presenti librerie a 64 bit.

Apri Android Studio e apri un progetto.
Dal menu, seleziona Crea > Analizza APK...
Scegli l'APK che vuoi valutare.
Cerca nella cartella lib che ospita eventuali file ".so". Se non sono disponibili, la tua app supporta i dispositivi a 64 bit e non sono necessarie ulteriori azioni. Se vedi armeabi-v7a o x86, significa che hai librerie a 32 bit.
Verifica se nella cartella arm64-v8a o x86_64 sono presenti file ".so" simili.
Se non hai librerie arm64-v8a o x86_64, aggiorna il processo di compilazione per iniziare a creare e pacchettizzare questi artefatti nel tuo APK.
Se noti che entrambe le librerie sono già pacchettizzate, puoi passare direttamente al test della tua 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 altro strumento di estrazione, estrai il file APK. A seconda dello strumento di estrazione, potrebbe essere necessario rinominare il file .zip.

Sfoglia i file estratti, seguendo le indicazioni riportate sopra per determinare se la tua app supporta i dispositivi a 64 bit. Dalla riga di comando puoi eseguire questo esempio 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 librerie 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 puoi creare dal codice sorgente.

Crea con Android Studio o Gradle

La maggior parte dei progetti Android Studio utilizza Gradle come sistema di compilazione sottostante, quindi questa sezione 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 supportare, all'impostazione ndk.abiFilters nel file "build.gradle" dell'app:

Alla moda

// 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'
// ...

Kotlin

// 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 con CMake, puoi crearla per ABI a 64 bit passando arm64-v8a al parametro "-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 ABI a 64 bit modificando il file 'Application.mk' con 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 su iOS, non dovresti fare altro per Android. Se è la prima volta che viene creato un codice per un sistema a 64 bit, il problema principale da risolvere è che i puntatori non rientrano più nei tipi di numeri interi a 32 bit come int.

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

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

Utilizza i seguenti flag del compilatore per rilevare i casi in cui il codice effettua la conversione errata 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++ presentano lo stesso problema. Cerca jint nell'origine JNI e assicurati di passare a long sul lato Java e a jlong sul lato C++.

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

// 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 in errori gli avvisi di dichiarazione di funzione implicita per consentirti di trovare e risolvere più facilmente questo problema:

-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, come sizeof(void*).

Se devi compilare in modo condizionale un codice diverso per i formati a 32-bit e a 64 bit, puoi utilizzare #if defined(__LP64__) per differenze generiche di 32/64 oppure __arm__, __aarch64__ (arm64), __i386__ (x86) e __x86_64__ per le architetture specifiche supportate da Android.

Regola le stringhe di formato per le funzioni di tipo printf o scanf, poiché gli indicatori di formato tradizionali non consentono di specificare i tipi a 64 bit in un modo corretto per i dispositivi a 32 e a 64 bit. Le macro PRI e SCN in <inttypes.h> risolvono questo problema, PRIxPTR e SCNxPTR per la scrittura e la lettura dei puntatori esadecimali e PRId64 e SCNd64 per la scrittura e la lettura portabile di valori a 64 bit.

Durante lo spostamento, potrebbe essere necessario utilizzare 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 la funzionalità Android App Bundle per ridurre al minimo l'impatto sulle dimensioni dell'inclusione di codice nativo a 32 e 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 2017.4.16.

Se utilizzi una versione di Unity che non supporta i formati a 64 bit, individua la versione a cui vuoi eseguire l'upgrade e segui le guide fornite da Unity per eseguire la migrazione del tuo ambiente, assicurandoti che l'app venga aggiornata a una versione in grado di creare librerie a 64 bit. Unity consiglia di accedere alle funzionalità e agli aggiornamenti più recenti eseguendo l'upgrade all'ultima versione LTS dell'editor.

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

Versione Unity	La versione supporta il formato a 64 bit?	Azione consigliata
2020,x	✔️	Assicurati che le impostazioni di build generino librerie a 64 bit.
2019,x	✔️	Assicurati che le impostazioni di build generino librerie a 64 bit.
2018.4 (LTS)	✔️	Assicurati che le impostazioni di build generino librerie a 64 bit.
2018,3	✔️	Assicurati che le impostazioni di build generino librerie a 64 bit.
2018/02	✔️	Assicurati che le impostazioni di build generino librerie a 64 bit.
2018/01	➖	Supporto sperimentale del formato a 64 bit.
2017.4 (LTS)	✔️	Supportata a partire dal 16/4/2017. Assicurati che le impostazioni di build abbiano come output librerie a 64 bit.
2017,3	🔍️	Esegui l'upgrade alla versione che supporta il formato a 64 bit.
2017/02	🔍️	Esegui l'upgrade alla versione che supporta il formato a 64 bit.
2017/01	🔍️	Esegui l'upgrade alla versione che supporta il formato a 64 bit.
<=5,6	🔍️	Esegui l'upgrade alla versione che supporta il formato a 64 bit.

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 il backend IL2CPP come backend di script. Per configurare il progetto Unity per creare un'architettura a 64 bit:

Vai a Impostazioni build e assicurati di creare per Android verificando che il simbolo Unity sia presente accanto ad Android in Piattaforma. 1. Se il simbolo Unity non si trova accanto alla piattaforma Android, seleziona Android e fai clic su Cambia piattaforma.
Fai clic su Impostazioni player.
Vai al riquadro Impostazioni del player > Impostazioni per Android > Altre impostazioni > Configurazione.
Imposta Backend di script su IL2CPP.
Seleziona la casella di controllo Architettura di destinazione > ARM64.
Costruisci come di consueto!

Tieni presente che lo sviluppo di ARM64 richiede che tutti gli asset siano creati appositamente per quella piattaforma. Segui le linee guida di Unity per ridurre le dimensioni degli APK e valuta la possibilità di sfruttare la funzionalità Android App Bundle per contribuire a mitigare questo aumento delle dimensioni.

APK multiplo e conformità a 64 bit

Se utilizzi il supporto degli APK multipli di Google Play per pubblicare la tua app, tieni presente che la conformità al requisito dei 64 bit viene valutata a livello di release. Tuttavia, il requisito dei 64 bit non si applica agli APK o agli 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 renderlo conforme, una strategia consiste nell'aggiungere un attributo maxSdkVersion="27" nell'elemento uses-sdk nel file manifest dell'APK. Questo APK non viene fornito sui dispositivi con Android 9 Pie o versioni successive 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 degli strumenti Android, potresti riscontrare problemi di conformità a 64 bit per l'app. Con gli strumenti di build precedenti alla versione 21.0.0, il compilatore potrebbe generare bitcode in un file .bc esterno. Questi file .bc precedenti non sono più supportati per le architetture a 64 bit, pertanto la presenza del file nell'APK causa il problema di conformità.

Per risolvere il problema, rimuovi tutti i file .bc nel progetto, esegui l'upgrade dell'ambiente a build-tools-21.0.0 o versioni successive e imposta renderscriptTargetApi in Android Studio su un valore superiore a 21 per indicare al compilatore di non inviare i file .bc. Dopodiché ricrea l'app, controlla se sono presenti file .bc e caricala su Play Console.

Testare l'app su hardware a 64 bit

La versione a 64 bit dell'app dovrebbe offrire la stessa qualità e lo stesso insieme di funzionalità della versione a 32 bit. Testa la tua app per assicurarti che gli utenti che utilizzano gli ultimi dispositivi a 64 bit abbiano un'esperienza ottimale.

Dispositivi solo a 64 bit

Se possibile, ti consigliamo di testare l'app in un ambiente 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 per alcuni dispositivi Pixel speciali immagini di sistema in un ambiente rigido solo a 64 bit. Queste immagini solo a 64 bit erano state originariamente fornite in concomitanza con immagini di sistema standard del sistema di fabbrica per le release di anteprima di Android 13 e 14, ma puoi continuare a utilizzarle durante il test della tua app per verificare la compatibilità a 64 bit.

Ottieni un'immagine a 64 bit

Come per le immagini di sistema di fabbrica, puoi eseguire il flashing del tuo dispositivo con un'immagine solo a 64 bit utilizzando Android Flash Tool o eseguire il flashing manuale del dispositivo, come descritto nelle sezioni che seguono.

Esegui il flashing del dispositivo con Android Flash Tool

Lo strumento Android Flash ti consente di eseguire il flashing sicuro di un'immagine di sistema sul 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 del dispositivo; non è necessario installare strumenti, ma devi sbloccare il dispositivo e attivare Debug USB nelle Opzioni sviluppatore. Per istruzioni complete, consulta la documentazione di Android Flash Tool.

Collega il dispositivo tramite USB, quindi, a seconda del tipo di immagine di sistema che desideri flash, accedi ad Android Flash Tool utilizzando uno dei seguenti link e segui le istruzioni sullo schermo:

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

Seleziona il dispositivo che stai tentando di flashare:
Immagini di sistema solo a 64 bit per Android 13 (QPR3 Beta 3.2)

Seleziona il dispositivo che stai tentando di flashare:

Esegui il flashing manuale del dispositivo

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

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

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

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 la compatibilità delle app a 64 bit. Queste configurazioni solo a 64 bit sono destinate esclusivamente all'uso da parte degli sviluppatori.

Dispositivo	Link di download	Checksum SHA-256
Pixel 4a (5G)		`7e6731fab811ae389f5ff882d5c5a2b8b942b8363b22bbcc038b39d7c539e60a`
Pixel 5		`c4da6a19086a02f2cd2fa7a4054e870916954b8e5a61e9a07ee942c537e4b45a`
Pixel 6		`98943384284cbc7323b8867d84c36151757f67ae7633012fb69cb5d6bec2b554`
Pixel 6 Pro		`67ec40be5bd05a40fa5dabc1ce6795aae75d1904193d52e2da00425ed7cb895b`

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

Dispositivo	Link di download	Checksum SHA-256
Pixel 4a (5G)		`b4be40924f62c3c2b3ed20a9f7fa4303aa9c39649d778eb96f86c867fe3ae59a`
Pixel 5		`6e5e027a4f64f9f786db9bb69d50d1a551c3f6aad893ae450e1f8279ea1b761a`
Pixel 6		`becb9b81a5bddad67a4ac32d30a50dcb372b9d083cb7c046e5180510e479a0b8`
Pixel 6 Pro		`b0ef544ed2312ac44dc827f24999281b147c11d76356c2d06b2c57a191c60480`

Torna a una build pubblica

Puoi utilizzare lo strumento Android Flash per eseguire il flashing dell'immagine di fabbrica oppure ottenere un'immagine di sistema con le specifiche del produttore dalla pagina Immagini di fabbrica per dispositivi Nexus e Pixel e quindi eseguire il flashing manuale del dispositivo sul dispositivo.

Emulatore Android

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

Altre opzioni dispositivo

Se non hai uno di questi dispositivi o non puoi utilizzare l'emulatore Android, l'opzione migliore è quella di utilizzare un dispositivo con risoluzione 64 bit, ad esempio Google Pixel o altri dispositivi di prim'ordine di altri produttori.

Installare e testare l'app

Il modo più semplice per testare l'APK è installare l'app utilizzando Android Debug Bridge (adb). Nella maggior parte dei casi, puoi fornire --abi come parametro per indicare quali librerie installare nel dispositivo. In questo modo l'app viene installata solo con le 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 per assicurarti che la qualità corrisponda a quella della versione a 32 bit.

Verificare la presenza di problemi di compatibilità noti

Durante il test, controlla se nella tua app sono presenti i seguenti problemi che interessano le app quando vengono eseguite su dispositivi a 64 bit. Anche se la tua app non dipende direttamente dalle librerie interessate, potrebbero esserci librerie e SDK di terze parti nelle dipendenze della tua app.

SoLoader

Se utilizzi l'SDK del caricatore di codice nativo SoLoader, esegui l'aggiornamento alla versione 0.10.4 o successiva. Se la tua app utilizza SDK che dipendono da SoLoader, assicurati di eseguire l'aggiornamento anche all'ultima versione stabile degli SDK interessati.

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

Per ulteriori informazioni sulla risoluzione di questo e altri problemi causati da SoLoader, consulta la 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 dipendono da OpenSSL, assicurati anche di eseguire l'aggiornamento all'ultima versione dell'SDK che utilizza una versione di OpenSSL più recente. Se non è disponibile, contatta il provider dell'SDK.

ARMv8.3 PAC consente l'integrità del flusso di controllo assistito dall'hardware mediante l'autenticazione dei puntatori in fase di runtime. Le versioni precedenti di OpenSSL non utilizzano queste funzionalità in modo corretto, causando arresti anomali del runtime in tutti i 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 utilizzano le Branch Target Istruzioni (BTI) per contribuire a proteggerti dagli attacchi JOP. Le versioni precedenti degli SDK di offuscamento che si diramano in offset casuali delle librerie create con BTI possono causare l'arresto anomalo delle app. Poiché le istruzioni sono codificate come HINT, questo bug non è osservabile nei dispositivi che non supportano BTI.

Pubblica

Quando ritieni che la tua app sia pronta, pubblicala normalmente. Come sempre, continua a seguire le best practice per il deployment della tua app. Per garantire la qualità costante della tua app, ti consigliamo di sfruttare i canali di test chiusi per l'implementazione per un numero limitato di utenti.

Come quando decidi di implementare un aggiornamento importante, assicurati di aver testato a fondo i dispositivi con funzionalità a 64 bit prima di pubblicarlo per un pubblico più ampio.

Scarica Android 14 factory system image (64-bit-only)

Prima di eseguire il download, devi accettare i seguenti termini e condizioni.

Termini e condizioni

By clicking to accept, you hereby agree to the following:

All use of this development version SDK will be governed by the Android Software Development Kit License Agreement (available at https://developer.android.com/studio/terms and such URL may be updated or changed by Google from time to time), which will terminate when Google issues a final release version.

Your testing and feedback are important part of the development process and by using the SDK, you acknowledge that (i) implementation of some features are still under development, (ii) you should not rely on the SDK having the full functionality of a stable release; (iii) you agree not to publicly distribute or ship any application using this SDK as this SDK will no longer be supported after the official Android SDK is released; and (iv) you agree that Google may deliver elements of the SDK to your devices via auto-update (OTA or otherwise, in each case as determined by Google).

WITHOUT LIMITING SECTION 10 OF THE ANDROID SOFTWARE DEVELOPMENT KIT LICENSE AGREEMENT, YOU UNDERSTAND THAT A DEVELOPMENT VERSION OF A SDK IS NOT A STABLE RELEASE AND MAY CONTAIN ERRORS, DEFECTS AND SECURITY VULNERABILITIES THAT CAN RESULT IN SIGNIFICANT DAMAGE, INCLUDING THE COMPLETE, IRRECOVERABLE LOSS OF USE OF YOUR COMPUTER SYSTEM OR OTHER DEVICE.