A partire da Android 9 (livello API 28), la piattaforma limita le interfacce non SDK che la tua app può utilizzare. Queste limitazioni si applicano ogni volta che un'app fa riferimento a un'interfaccia non SDK o tenta di ottenere il relativo handle utilizzando la riflessione o JNI. Queste limitazioni sono state messe in atto per contribuire a migliorare l'esperienza degli utenti e degli sviluppatori e ridurre i rischi di arresti anomali per gli utenti e di implementazioni di emergenza per gli sviluppatori. Per ulteriori informazioni su questa decisione, consulta Migliorare la stabilità riducendo l'utilizzo di interfacce non SDK.
Distinguere tra interfacce SDK e non SDK
In generale, le interfacce SDK pubbliche sono quelle documentate nell'Indice dei pacchetti del framework Android. La gestione delle interfacce non SDK è un dettaglio di implementazione astratto dall'API, pertanto queste interfacce sono soggette a modifiche senza preavviso.
Per evitare arresti anomali e comportamenti imprevisti, le app devono utilizzare solo le parti delle classi nell'SDK ufficialmente documentate. Ciò significa anche che non devi accedere a metodi o campi non elencati nell'SDK quando interagisci con una classe utilizzando meccanismi come la riflessione.
Elenchi di API non SDK
Con ogni release di Android, vengono limitate altre interfacce non SDK. Sappiamo che queste limitazioni possono influire sul flusso di lavoro di rilascio e vogliamo assicurarci che tu abbia gli strumenti per rilevare l'utilizzo di interfacce non SDK, un'opportunità per inviarci un feedback e il tempo per pianificare e adattarti alle nuove norme.
Per ridurre al minimo l'impatto delle limitazioni non SDK sul flusso di lavoro di sviluppo, le interfacce non SDK sono suddivise in elenchi che definiscono il grado di limitazione del loro utilizzo, a seconda del livello API scelto come target. La tabella seguente descrive ciascuno di questi elenchi:
| Elenco | Tag di codice | Descrizione |
|---|---|---|
| Lista bloccata |
|
Interfacce non SDK che non puoi utilizzare indipendentemente dal livello API target della tua app. Se la tua app tenta di accedere a una di queste interfacce, il sistema genera un errore. |
| Bloccata condizionalmente |
|
A partire da Android 9 (livello API 28), ogni livello API ha interfacce non SDK con limitazioni quando un'app ha come target quel livello API. Questi elenchi sono etichettati in base al livello API
massimo ( Se la tua app tenta di accedere a un'interfaccia limitata per il tuo livello API target, il sistema si comporta come se l'API facesse parte della lista bloccata. |
| Non supportato |
|
Interfacce non SDK senza limitazioni che la tua app può utilizzare. Tieni tuttavia presente che queste interfacce non sono supportate e sono soggette a modifiche senza preavviso. Queste interfacce dovrebbero essere bloccate in modo condizionale nelle future versioni di Android in un elenco max-target-x. |
| SDK |
|
Interfacce che possono essere utilizzate liberamente e ora sono supportate nell'Indice dei pacchetti del framework Android documentato ufficialmente. |
| Testare le API |
|
Interfacce utilizzate per i test di sistema interni, ad esempio API che facilitano i test tramite la suite di test di compatibilità (CTS). Le API di test non fanno parte dell'SDK. A partire da Android 11 (livello API 30), le API di test sono incluse nella lista bloccata, pertanto le app non sono autorizzate a utilizzarle indipendentemente dal livello API target. Tutte le API di test non sono supportate e sono soggette a modifiche senza preavviso, indipendentemente dal livello dell'API della piattaforma. |
Sebbene tu possa utilizzare alcune interfacce non SDK (a seconda del livello dell'API di destinazione della tua app), l'utilizzo di qualsiasi metodo o campo non SDK comporta sempre un rischio elevato di interrompere la tua app. Se la tua app si basa su interfacce non SDK, devi iniziare a pianificare una migrazione alle interfacce SDK o ad altre alternative. Se non riesci a trovare un'alternativa all'utilizzo di un'interfaccia non SDK per una funzionalità nella tua app, devi richiedere una nuova API pubblica.
Determinare a quale elenco appartiene un'interfaccia
Gli elenchi di interfacce non SDK vengono creati all'interno della piattaforma. Consulta le sezioni seguenti per informazioni su ogni release di Android.
Android 16
Per Android 16 (livello API 36), puoi scaricare il seguente file che descrive tutte le interfacce non SDK e i relativi elenchi:
File: hiddenapi-flags.csv
Checksum SHA-256:
9102af02fe6ab68b92464bdff5e5b09f3bd62c65d1130aaf85d3296f17d38074
Per scoprire di più sulle modifiche all'elenco di API non SDK in Android 16, consulta Aggiornamenti alle limitazioni relative alle interfacce non SDK in Android 16.
Android 15
Per Android 15 (livello API 35), puoi scaricare il seguente file che descrive tutte le interfacce non SDK e i relativi elenchi:
File: hiddenapi-flags.csv
Checksum SHA-256:
40134e205e58922a708c453726b279a296e6a1f34a988abd90cec0f3432ea5a9
Per scoprire di più sulle modifiche all'elenco delle API non SDK in Android 15, consulta Aggiornamenti alle limitazioni delle interfacce non SDK in Android 15.
Android 14
Per Android 14 (livello API 34), puoi scaricare il seguente file che descrive tutte le interfacce non SDK e i relativi elenchi:
File: hiddenapi-flags.csv
Checksum SHA-256:
7e00db074cbe51c51ff4b411f7b48e98692951395c5c17d069c822cc1d0eae0f
Per scoprire di più sulle modifiche all'elenco di API non SDK in Android 14, consulta Aggiornamenti alle limitazioni relative alle interfacce non SDK in Android 14.
Android 13
Per Android 13 (livello API 33), puoi scaricare il seguente file che descrive tutte le interfacce non SDK e i relativi elenchi:
File: hiddenapi-flags.csv
Checksum SHA-256:
233a277aa8ac475b6df61bffd95665d86aac6eb2ad187b90bf42a98f5f2a11a3
Per scoprire di più sulle modifiche all'elenco delle API non SDK in Android 13, incluse le alternative di API pubbliche suggerite per le API bloccate in modo condizionale in Android 13, consulta Aggiornamenti alle limitazioni dell'interfaccia non SDK in Android 13.
Android 12
Per Android 12 (livello API 31), puoi scaricare il seguente file che descrive tutte le interfacce non SDK e i relativi elenchi:
File: hiddenapi-flags.csv
Checksum SHA-256:
40674ff4291eb268f86561bf687e69dbd013df9ec9531a460404532a4ac9a761
Per saperne di più sulle modifiche all'elenco di API non SDK in Android 12, incluse le alternative di API pubbliche suggerite per le API bloccate in modo condizionale in Android 12, consulta Modifiche all'elenco per Android 12.
Android 11
Per Android 11 (livello API 30), puoi scaricare il seguente file che descrive tutte le interfacce non SDK e i relativi elenchi:
File: hiddenapi-flags.csv
Checksum SHA-256:
a19d839f4f61dc9c94960ae977b2e0f3eb30f880ba1ffe5108e790010b477a56
Per scoprire di più sulle modifiche all'elenco delle API non SDK in Android 11, incluse le alternative di API pubbliche suggerite per le API bloccate condizionatamente in Android 11, consulta Modifiche all'elenco per Android 11.
Android 10
Per Android 10 (livello API 29), puoi scaricare il seguente file che descrive tutte le interfacce non SDK e i relativi elenchi:
File: hiddenapi-flags.csv
Checksum SHA-256:
f22a59c215e752777a114bd9b07b0b6b4aedfc8e49e6efca0f99681771c5bfeb
Per scoprire di più sulle modifiche all'elenco di API non SDK in Android 10, incluse le alternative di API pubbliche suggerite per le API bloccate condizionatamente in Android 10, consulta Modifiche all'elenco per Android 10.
Android 9
Per Android 9 (livello API 28), il seguente file di testo contiene l'elenco delle API non SDK non soggette a limitazioni (nella lista grigia):
hiddenapi-light-greylist.txt.
La lista bloccata (blacklist) e l'elenco di API bloccate condizionalmente (lista grigio scuro) vengono ricavate in fase di compilazione.
Generare elenchi da AOSP
Quando lavori con AOSP, puoi generare un file hiddenapi-flags.csv che contiene tutte le interfacce non SDK e i relativi elenchi. Per farlo,
scarica il codice sorgente AOSP ed esegui il seguente comando:
m out/soong/hiddenapi/hiddenapi-flags.csv
Puoi trovare il file nella seguente posizione:
out/soong/hiddenapi/hiddenapi-flags.csv
Comportamento previsto quando si accede a interfacce non SDK con limitazioni
La tabella seguente descrive il comportamento che puoi aspettarti se la tua app tenta di accedere a un'interfaccia non SDK che fa parte della lista bloccata.
| Mezzi di accesso | Risultato |
|---|---|
| Istruzione Dalvik che fa riferimento a un campo | NoSuchFieldError lanciato |
| Istruzione Dalvik che fa riferimento a un metodo | NoSuchMethodError lanciato |
Riflessione utilizzando Class.getDeclaredField() o Class.getField() |
NoSuchFieldException lanciato |
Riflessione utilizzando Class.getDeclaredMethod(), Class.getMethod() |
NoSuchMethodException lanciato |
Riflessione utilizzando Class.getDeclaredFields(), Class.getFields() |
Membri non SDK non presenti nei risultati |
Riflessione utilizzando Class.getDeclaredMethods(), Class.getMethods() |
Membri non SDK non presenti nei risultati |
JNI che utilizza env->GetFieldID() |
NULL restituito, NoSuchFieldError lanciato |
JNI che utilizza env->GetMethodID() |
NULL restituito, NoSuchMethodError lanciato |
Eseguire il test dell'app per le interfacce non SDK
Esistono diversi metodi che puoi utilizzare per verificare la presenza di interfacce non SDK nella tua app.
Eseguire il test utilizzando un'app di cui è possibile eseguire il debug
Puoi verificare la presenza di interfacce non SDK compilando ed eseguendo un'app di debug su un dispositivo o un emulatore con Android 9 (livello API 28) o versioni successive. Assicurati che il dispositivo o l'emulatore che utilizzi corrisponda al livello API target della tua app.
Durante l'esecuzione dei test sull'app, il sistema stampa un messaggio di log se l'app accede a determinate interfacce non SDK. Puoi esaminare i messaggi di log della tua app per trovare i seguenti dettagli:
- La classe, il nome e il tipo di dichiarazione (nel formato utilizzato dal runtime Android).
- I mezzi di accesso: collegamento, utilizzo della riflessione o utilizzo di JNI.
- A quale elenco appartiene l'interfaccia non SDK.
Puoi utilizzare adb logcat per accedere a questi messaggi di log, che vengono visualizzati sotto il PID dell'app in esecuzione. Ad esempio, una voce del log potrebbe essere la seguente:
Accessing hidden field Landroid/os/Message;->flags:I (light greylist, JNI)
Eseguire il test utilizzando l'API StrictMode
Puoi anche verificare la presenza di interfacce non SDK utilizzando l'API StrictMode. Utilizza il metodo
detectNonSdkApiUsage per attivare questa opzione. Dopo aver attivato l'API StrictMode, puoi ricevere un callback per ogni utilizzo di un'interfaccia non SDK utilizzando un penaltyListener, in cui puoi implementare il trattamento personalizzato. L'oggetto Violation fornito nel callback deriva da
Throwable e la traccia dello stack inclusa fornisce il contesto dell'utilizzo.
Eseguire il test utilizzando lo strumento Veridex
Puoi anche eseguire lo strumento di analisi statica Veridex sul tuo APK. Lo strumento Veridex analizza l'intera base di codice dell'APK, incluse le eventuali librerie di terze parti, e segnala eventuali utilizzi di interfacce non SDK rilevati.
Le limitazioni dello strumento Veridex includono:
- Non è in grado di rilevare le invocazioni tramite JNI.
- Può rilevare solo un sottoinsieme di invocazioni tramite la riflessione.
- La sua analisi dei percorsi di codice inattivi è limitata ai controlli a livello di API.
- Può essere eseguito solo su macchine che supportano le istruzioni SSE4.2 e POPCNT.
Windows
I binari nativi di Windows non sono forniti, ma puoi eseguire lo strumento Veridex su Windows eseguendo i binari di Linux utilizzando il sottosistema Windows per Linux (WSL). Prima di seguire i passaggi descritti in questa sezione, installa WSL e scegli Ubuntu come distribuzione Linux.
Dopo aver installato Ubuntu, avvia un terminale Ubuntu e segui questi passaggi:
- Scarica lo strumento Veridex dal repository prebuilt del runtime Android.
- Estrai i contenuti del file
appcompat.tar.gz. - Nella cartella estratta, individua il file
veridex-linux.ziped estrailo. Vai alla cartella decompressa ed esegui il seguente comando, dove
your-app.apkè l'APK che vuoi testare:./appcompat.sh --dex-file=your-app.apk
macOS
Per eseguire lo strumento Veridex su macOS:
- Scarica lo strumento Veridex dal repository prebuilt del runtime Android.
- Estrai i contenuti del file
appcompat.tar.gz. - Nella cartella estratta, individua il file
veridex-mac.ziped estrailo. Vai alla cartella decompressa ed esegui il seguente comando, dove
/path-from-root/your-app.apkè il percorso dell'APK che vuoi testare, a partire dalla directory principale del sistema:./appcompat.sh --dex-file=/path-from-root/your-app.apk
Linux
Per eseguire lo strumento Veridex su Linux:
- Scarica lo strumento Veridex dal repository prebuilt del runtime Android.
- Estrai i contenuti del file
appcompat.tar.gz. - Nella cartella estratta, individua il file
veridex-linux.ziped estrailo. Vai alla cartella decompressa ed esegui il seguente comando, dove
your-app.apkè l'APK che vuoi testare:./appcompat.sh --dex-file=your-app.apk
Eseguire il test utilizzando lo strumento lint di Android Studio
Ogni volta che compili l'app in Android Studio, lo strumento lint controlla il codice per individuare potenziali problemi. Se la tua app utilizza interfacce non SDK, potresti visualizzare errori di compilazione o avvisi, a seconda a quale elenco appartengono queste interfacce.
Puoi anche eseguire lo strumento lint dalla riga di comando o eseguire le ispezioni manualmente su un progetto, una cartella o un file specifico.
Eseguire il test utilizzando Play Console
Quando carichi la tua app in un canale di test in Play Console, viene eseguita automaticamente la verifica della presenza di potenziali problemi e viene generato un report pre-lancio. Se la tua app utilizza interfacce non SDK, nel report pre-lancio viene visualizzato un errore o un avviso, a seconda di a quale elenco appartengono queste interfacce.
Per ulteriori informazioni, consulta la sezione sulla compatibilità con Android in Utilizzare i report pre-lancio per identificare i problemi.
Richiedere una nuova API pubblica
Se non riesci a trovare un'alternativa all'utilizzo di un'interfaccia non SDK per una funzionalità nella tua app, puoi richiedere una nuova API pubblica creando una richiesta di funzionalità nel nostro issue tracker.
Quando crei una richiesta di funzionalità, fornisci le seguenti informazioni:
- L'API non supportata in uso, incluso il descrittore completo visualizzato nel messaggio logcat
Accessing hidden .... - Perché devi utilizzare queste API, inclusi dettagli sulla funzionalità di alto livello per la quale è necessaria l'API, non solo dettagli di basso livello.
- Perché le API SDK pubbliche correlate non sono sufficienti per le tue finalità.
- Eventuali altre alternative che hai provato e perché non hanno funzionato.
Fornendo questi dettagli nella richiesta di funzionalità, aumenti la probabilità che venga concessa una nuova API pubblica.
Altre domande
Questa sezione include alcune risposte ad altre domande frequenti poste dagli sviluppatori:
Domande di carattere generale
In che modo Google può essere sicura di poter soddisfare le esigenze di tutte le app tramite il tracker dei problemi?
Abbiamo creato gli elenchi iniziali per Android 9 (livello API 28) tramite un'analisi statica delle app, che è stata integrata utilizzando i seguenti metodi:
- test manuale delle app più popolari di Play e non di Play
- report interni
- raccolta automatica dei dati da parte degli utenti interni
- report di anteprima per gli sviluppatori
- un'analisi statica aggiuntiva progettata per includere in modo conservativo più falsi positivi
Durante la valutazione degli elenchi per ogni nuova release, prendiamo in considerazione l'utilizzo dell'API nonché il feedback degli sviluppatori tramite il tracker dei problemi.
Come faccio ad attivare l'accesso alle interfacce non SDK?
Puoi abilitare l'accesso alle interfacce non SDK sui dispositivi di sviluppo utilizzando i comandi adb per modificare il criterio di applicazione delle API. I comandi che utilizzi variano in base al livello dell'API. Questi comandi non richiedono un dispositivo rooted.
- Android 10 (livello API 29) o versioni successive
Per abilitare l'accesso, utilizza il seguente adb
command:
adb shell settings put global hidden_api_policy 1
Per reimpostare il criterio di applicazione dell'API sulle impostazioni predefinite, utilizza il seguente comando:
adb shell settings delete global hidden_api_policy
- Android 9 (livello API 28)
Per abilitare l'accesso, utilizza i seguenti comandi adb:
adb shell settings put global hidden_api_policy_pre_p_apps 1adb shell settings put global hidden_api_policy_p_apps 1Per reimpostare il criterio di applicazione dell'API sulle impostazioni predefinite, utilizza i seguenti comandi:
adb shell settings delete global hidden_api_policy_pre_p_appsadb shell settings delete global hidden_api_policy_p_apps
Puoi impostare l'intero nel criterio di applicazione dell'API su uno dei seguenti valori:
- 0: disattiva tutto il rilevamento delle interfacce non SDK. L'utilizzo di questa impostazione disattiva tutti i messaggi di log per l'utilizzo di interfacce non SDK e ti impedisce di testare la tua app utilizzando l'API
StrictMode. Questa impostazione non è consigliata. - 1: abilita l'accesso a tutte le interfacce non SDK, ma stampa messaggi di log con avvertimenti per qualsiasi utilizzo di interfacce non SDK. L'utilizzo di questa impostazione ti consente inoltre di
testare la tua app utilizzando l'API
StrictMode. - 2: non consentire l'utilizzo di interfacce non SDK che appartengono alla lista bloccata o sono bloccate condizionatamente per il tuo livello API target.
Domande sugli elenchi di interfacce non SDK
Dove posso trovare gli elenchi di API non SDK nell'immagine di sistema?
Sono codificati nei bit di flag di accesso a campi e metodi nei file dex della piattaforma. Nell'immagine di sistema non è presente un file separato contenente questi elenchi.
Gli elenchi di API non SDK sono gli stessi su dispositivi OEM diversi con le stesse versioni di Android?
Gli OEM possono aggiungere le proprie interfacce alla lista bloccata (lista nera), ma non possono rimuovere le interfacce dagli elenchi di API non SDK di AOSP. Il CDD impedisce queste modifiche e i test CTS assicurano che il runtime Android applichi l'elenco.
Domande sulla compatibilità delle app correlate
Esistono limitazioni per le interfacce non NDK nel codice nativo?
L'SDK Android include interfacce Java. La piattaforma ha iniziato a limitare l'accesso alle interfacce non NDK per il codice C/C++ nativo in Android 7 (livello API 26). Per ulteriori informazioni, consulta Migliorare la stabilità con le limitazioni dei simboli C/C++ privati in Android N.
È previsto di limitare la manipolazione dei file DEX o dex2oat?
Non abbiamo piani attivi per limitare l'accesso al file binario dex2oat, ma non intendiamo che il formato file DEX sia stabile o un'interfaccia pubblica oltre alle parti specificate pubblicamente nel formato eseguibile Dalvik. Ci riserviamo il diritto di modificare o eliminare dex2oat e le parti non specificate del formato DEX in qualsiasi momento. Tieni inoltre presente che i file derivati prodotti da dex2oat come ODEX (noto anche come OAT), VDEX e CDEX sono tutti formati non specificati.
Cosa succede se un SDK di terze parti fondamentale (ad esempio un offuscatore) non può evitare di utilizzare interfacce non SDK, ma si impegna a mantenere la compatibilità con le versioni future di Android? In questo caso, Android può rinunciare ai suoi requisiti di compatibilità?
Non prevediamo di rinunciare ai requisiti di compatibilità in base all'SDK. Se un sviluppatore SDK può mantenere la compatibilità solo facendo affidamento sulle interfacce negli elenchi non supportati (in precedenza grigi), deve iniziare a pianificare una migrazione alle interfacce SDK o ad altre alternative e richiedere una nuova API pubblica ogni volta che non riesce a trovare un'alternativa all'utilizzo di un'interfaccia non SDK.
Le limitazioni relative all'interfaccia non SDK si applicano a tutte le app, incluse quelle di sistema e proprietarie, non solo a quelle di terze parti?
Sì, tuttavia, sono esenti le app firmate con la chiave della piattaforma e alcune app di immagini di sistema. Tieni presente che queste esenzioni si applicano solo alle app che fanno parte dell'immagine di sistema (o alle app di immagini di sistema aggiornate). L'elenco è destinato solo alle app che vengono compilate in base alle API di piattaforma private, anziché alle API SDK (dove LOCAL_PRIVATE_PLATFORM_APIS := true).