Android 11 ha introdotto nuovi strumenti per sviluppatori a scopo di test e eseguendo il debug della tua app in base ai cambiamenti di comportamento nelle versioni più recenti di Android. completamente gestita. Questi strumenti fanno parte di un framework di compatibilità che consente alle app gli sviluppatori attivano e disattivano singolarmente le modifiche utilizzando o ADB. Sfrutta questa flessibilità mentre ti prepari a scegliere come target stabile dell'API e mentre testi l'app con la versione di anteprima della all'ultima versione di Android.
Quando usi gli strumenti del framework di compatibilità, la piattaforma Android
adatta automaticamente la sua logica interna, così non devi modificare
targetSDKVersion
o ricompilare l'app per eseguire test di base. Poiché
le modifiche possono essere attivate singolarmente, puoi isolare, testare ed eseguire il debug di una
comportamento cambia alla volta o disattivare una singola modifica che causa problemi se
devi prima testare qualcos'altro.
Come identificare quali modifiche sono attivate
L'attivazione di una modifica del comportamento può influire sul modo in cui l'app accede al le API delle piattaforme interessate da questa modifica. Puoi controllare quale comportamento le modifiche vengono abilitate utilizzando le opzioni sviluppatore, logcat o i comandi ADB.
Identificare le modifiche attivate utilizzando le opzioni sviluppatore
![](https://developer.android.com/static/images/guide/app-compatibility/appcompat-dev-options.png?authuser=9&hl=it)
Figura 1. Modifiche relative alla compatibilità delle app schermata in Opzioni sviluppatore.
Puoi vedere quali modifiche sono attivate e attivarle o disattivarle in le opzioni sviluppatore di un dispositivo. Per accedere a queste opzioni, segui questi passaggi:
- Se le opzioni sviluppatore non sono già attivate, attivale.
- Apri l'app Impostazioni del dispositivo e vai a Sistema > Avanzate > Opzioni sviluppatore > Modifiche relative alla compatibilità delle app.
Seleziona la tua app dall'elenco.
In genere, ciascuna modifica del comportamento appartiene a una delle due categorie seguenti:
Modifiche che interessano tutte le app eseguite su quella versione di Android, indipendentemente del valore di
targetSdkVersion
dell'app.Queste modifiche sono abilitate per impostazione predefinita nel framework di compatibilità e sono elencate nella UI nella sezione Modifiche abilitate per impostazione predefinita.
Modifiche che interessano solo le app destinate a determinate versioni di Android. Poiché queste modifiche riguardano solo le app che hanno come target una versione specifica di Android, sono anche chiamate modifiche gestite da
targetSDKVersion
.Queste modifiche sono abilitate per impostazione predefinita nel framework di compatibilità se il tuo l'app ha come target una versione successiva rispetto alla versione API indicata. Ad esempio: un cambiamento del comportamento controllato da
targetSDKVersion
in Android 13 (livello API 33) sarà elencata nell'interfaccia utente con una sezione intitolata Abilitato per targetSdkVersion >=33. In alcune versioni precedenti di Android, questa sezione è intitolata "Abilitata dopo l'SDK API_LEVEL" .
Noterai anche una sezione nella Figura 1 chiamata Modifiche predefinite disattivate. Le modifiche che rientrano in questa sezione possono essere utili per diversi scopi. Prima del giorno attivare queste modifiche, leggi la descrizione della modifica nella di framework per quella versione di Android.
Identificare le modifiche abilitate utilizzando Logcat
A ogni modifica del comportamento, la prima volta durante il processo dell'app chiama l'API interessata, il sistema genera un messaggio logcat come questo:
D CompatibilityChangeReporter: Compat change id reported: 194833441; UID 10265; state: ENABLED
Ogni messaggio logcat include le seguenti informazioni:
- Modifica ID
- Indica la modifica che interessa l'app. Questo valore è mappato a uno dei
modifiche del comportamento elencate nella schermata Modifiche alla compatibilità delle app
(vedi figura 1). In questo esempio,
194833441
viene mappato aNOTIFICATION_PERM_CHANGE_ID
. - UID
- Indica quale app è interessata dalla modifica.
- Stato
Indica se la modifica interessa l'app.
Lo stato può essere uno di questi valori:
Stato Significato ENABLED
La modifica è attiva e influirà sul comportamento dell'app se l'app utilizza le API che sono state modificate. DISABLED
La modifica è disattivata e non influirà sull'app.
Nota: se questa modifica è disattivata a causa del
targetSDKVersion
è al di sotto della soglia richiesta, il sarà attivata per impostazione predefinita quando l'app aumentatargetSDKVersion
per scegliere come target una versione successiva.LOGGED
La modifica viene registrata tramite il framework di compatibilità, ma e non possono essere attivati o disattivati. Sebbene non sia possibile attivare/disattivare questa modifica, potrebbero comunque influire sul comportamento della tua app. Leggi la descrizione del modifica nell'elenco dei framework di compatibilità per quella versione di Android per avere ulteriori informazioni. In molti casi, questi tipi di modifiche sono sperimentali e possono essere ignorati.
Identificare le modifiche abilitate utilizzando ADB
Esegui questo comando ADB per visualizzare il set completo di modifiche (entrambe abilitate e disattivato) sull'intero dispositivo:
adb shell dumpsys platform_compat
Nell'output sono elencate le seguenti informazioni per ogni modifica:
- Modifica ID
- Un identificatore univoco per questa modifica del comportamento. Ad esempio,
194833441
. - Nome
- Il nome di questo comportamento è cambiato. Ad esempio,
NOTIFICATION_PERM_CHANGE_ID
. - Criteri targetSDKVersion
Quale
targetSDKVersion
è soggetto alla modifica (se presente).Ad esempio, se questa modifica viene attivata solo per le app che hanno come target la versione dell'SDK 33 o superiore, viene restituito
enableAfterTargetSdk=32
. Se la modifica non viene controllato datargetSDKVersion
, viene generato l'outputenableAfterTargetSdk=0
.- Override pacchetto
Il nome di ogni pacchetto in cui lo stato predefinito della modifica (attivato o disattivato) è stato sostituito.
Ad esempio, se si tratta di una modifica attiva per impostazione predefinita, pacchetto verrà elencato se hai disattivato la modifica utilizzando opzioni per gli sviluppatori o ADB. In questo caso, l'output sarebbe:
packageOverrides={com.my.package=false}
Le modifiche controllate da
targetSDKVersion
possono essere attivate oppure è disabilitata per impostazione predefinita, quindi l'elenco dei pacchetti può includere istanze ditrue
ofalse
, a seconda dei valoritargetSDKVersion
di ciascuna app. Per esempio:packageOverrides={com.my.package=true, com.another.package=false}
Scopri di più su modifiche specifiche
L'elenco completo delle modifiche del comportamento nel framework di compatibilità è incluso come della documentazione per ogni versione di Android. Consulta i seguenti link per maggiori informazioni, a seconda della versione di Android che stai testando l'app per:
- Android 15 (livello API 35)
- Android 14 (livello API 34)
- Android 13 (livello API 33)
- Android 12 (livelli API 31 e 32)
- Android 11 (livello API 30)
Quando attivare/disattivare le modifiche
Lo scopo principale del framework di compatibilità è fornirti il controllo e flessibilità durante il test dell'app con versioni più recenti di Android. Questo descrive alcune strategie che puoi usare per determinare quando attivare/disattivare attivare o disattivare le modifiche durante il test e il debug dell'app.
Quando disattivare le modifiche
La decisione di disattivare le modifiche in genere dipende dal fatto che la modifica sia
recintato da targetSDKVersion
o meno.
- Modifiche attivate per tutte le app
Le modifiche che interessano tutte le app vengono attivate da predefinita per una specifica versione della piattaforma, indipendentemente dalla
targetSDKVersion
, così potrai scoprire se la tua app è interessata dall'esecuzione di su quella versione della piattaforma.Ad esempio, se ti stai preparando a scegliere come target Android 14 (livello API 34), puoi iniziare installando l'app su un dispositivo in esecuzione Android 14 e testa la tua app con i test standard per i flussi di lavoro. Se la tua app riscontra problemi, puoi disattivare la modifica che è la causa del problema, quindi puoi continuare a eseguire test per altri problemi.
Poiché queste modifiche possono interessare tutte le app indipendentemente da
targetSDKVersion
, di solito è consigliabile testare e aggiornare l'app per queste modifiche prima delle modifiche gestite datargetSDKVersion
. Questo aiuta a garantire che i tuoi utenti non avranno un'esperienza con prestazioni ridotte quando aggiornano il dispositivo a una nuova completamente gestita.Dovresti anche dare la priorità al test di queste modifiche perché non puoi attivare/disattivare le modifiche si disattivano quando viene usata una build di release pubblica di Android. L'ideale è eseguire test su queste modifiche per ogni versione Android mentre la versione è in anteprima.
- Modifiche controllate da
targetSDKVersion
Se la tua app ha come target una specifica
targetSDKVersion
, tutte le modifiche controllate da quella versione vengono abilitate per impostazione predefinita. Quindi, quando cambitargetSDKVersion
dell'app in una nuova la tua app inizierà a essere influenzata da molte nuove modifiche contemporaneamente.Poiché la tua app potrebbe essere interessata da più di una di queste modifiche, potrebbe essere necessario disattivare singolarmente alcune di queste modifiche durante il test eseguire il debug dell'app.
Quando attivare le modifiche
Le modifiche controllate da un criterio targetSDKVersion
specifico sono disattivate per impostazione predefinita
ogni volta che un'app ha come target una versione dell'SDK inferiore rispetto a quella con accesso riservato.
In genere, mentre ti prepari a scegliere come target un nuovo targetSdkVersion
, viene visualizzato un elenco
di cambiamenti di comportamento
per le quali dovrai testare la tua app ed eseguirne il debug.
Ad esempio, potresti testare la tua app rispetto a una serie di modifiche alle piattaforme
entro i prossimi targetSdkVersion
. Con le Opzioni sviluppatore o i comandi ADB,
poter attivare e testare ogni modifica riservata una per volta, anziché modificare
del file manifest dell'app e attivare contemporaneamente tutte le modifiche. Questo controllo aggiuntivo può aiutarti
testare le modifiche in modo isolato ed evitare il debug e l'aggiornamento di più parti
l'app contemporaneamente.
Dopo aver attivato una modifica, puoi testare ed eseguire il debug della tua app utilizzando le dei flussi di lavoro di test. In caso di problemi, controlla i log per determinare la causa del problema. Se non è chiaro se il problema sia causato da una modifica della piattaforma attivata, prova a disattivarla e riprova area della tua app.
Attiva o disattiva le modifiche
Il framework di compatibilità ti consente di attivare o disattivare ogni modifica utilizzando il opzioni sviluppatore o comandi ADB. Perché l'attivazione o disattivazione delle modifiche può causare l'app per arrestarsi in modo anomalo o disattivare importanti modifiche alla sicurezza, limitazioni relative alla possibilità di attivare/disattivare le modifiche.
Attiva/disattiva le modifiche utilizzando le opzioni sviluppatore
Utilizza le Opzioni sviluppatore per attivare o disattivare le modifiche. Per trovare lo sviluppatore segui questi passaggi:
- Se le opzioni sviluppatore non sono già attivate, attivale.
- Apri l'app Impostazioni del dispositivo e vai a Sistema > Avanzate > Opzioni sviluppatore > Modifiche relative alla compatibilità delle app.
- Seleziona la tua app dall'elenco.
Nell'elenco delle modifiche, individua la modifica da attivare o disattivare. e tocca l'opzione.
Attiva/disattiva le modifiche utilizzando ADB
Per attivare o disattivare una modifica utilizzando ADB, esegui uno dei seguenti comandi:
adb shell am compat enable (CHANGE_ID|CHANGE_NAME) PACKAGE_NAME
adb shell am compat disable (CHANGE_ID|CHANGE_NAME) PACKAGE_NAME
Supera CHANGE_ID
(ad es. 194833441
) oppure
CHANGE_NAME
(ad esempio,
NOTIFICATION_PERM_CHANGE_ID
) e la tua app
PACKAGE_NAME
.
Puoi anche utilizzare il seguente comando per ripristinare le impostazioni predefinite di una modifica rimuovendo qualsiasi override che hai impostato utilizzando ADB o le opzioni sviluppatore:
adb shell am compat reset (CHANGE_ID|CHANGE_NAME) PACKAGE_NAME
Limitazioni relative all'attivazione/disattivazione delle modifiche
Per impostazione predefinita, ogni modifica del comportamento può essere attivata o disattivata. Modifiche che
influisce sull'attivazione di tutte le app per impostazione predefinita. Altre modifiche sono controllate da un
targetSdkVersion
. Queste modifiche sono attivate per impostazione predefinita quando un'app ha come target
la versione dell'SDK corrispondente o superiore e disattivata per impostazione predefinita quando un'app viene
che ha come target una versione dell'SDK precedente a quella con accesso riservato. Quando attivi una modifica
se attivata o disattivata, viene eseguito l'override
del suo stato predefinito.
Per evitare che il framework di compatibilità venga utilizzato in modo dannoso, ci sono alcune limitazioni relative a quando puoi attivare/disattivare le modifiche. Se puoi o meno attivare/disattivare una modifica dipende dal tipo di modifica, dall'eventuale debug della tua app o e il tipo di build in esecuzione sul dispositivo. La tabella seguente descrive quando puoi attivare/disattivare diversi tipi di modifiche:
Tipo di build | App non di cui non è possibile eseguire il debug | App di cui è possibile eseguire il debug | |
---|---|---|---|
Tutte le modifiche | Modifiche controllate da targetSDKVersion | Tutte le altre modifiche | |
Anteprima per sviluppatori o build beta | Impossibile attivare/disattivare | Può attivare/disattivare | Può attivare/disattivare |
Build pubblica dell'utente | Impossibile attivare/disattivare | Può attivare/disattivare | Impossibile attivare/disattivare |