Migliora l'ispezione del codice con le annotazioni

L'utilizzo di strumenti di ispezione del codice come lint può aiutarti a individuare risolvere problemi e migliorare il codice, ma gli strumenti di ispezione possono dedurre solo molto. ID risorsa Android, ad esempio, utilizza int per identificare stringhe, grafica, colori e altri tipi di risorse, in modo che gli strumenti di ispezione non siano in grado di capire quando hai specificato una risorsa stringa in cui ha specificato un colore. Ciò significa che l'app potrebbe non essere visualizzata correttamente o non essere eseguita. anche se usi l'ispezione del codice.

Le annotazioni consentono di fornire suggerimenti agli strumenti di ispezione del codice, come lint, per contribuire a rilevare questi più sottili problemi di codice. Le annotazioni vengono aggiunte come tag di metadati che attribuisci alle variabili, e restituiscono valori per controllare i valori restituiti dal metodo, i parametri trasmessi, le variabili locali e campi. Se utilizzate in combinazione con gli strumenti di ispezione del codice, le annotazioni possono aiutarti a rilevare problemi quali con eccezioni e conflitti tra i tipi di risorsa e null.

Android supporta una serie di annotazioni tramite Raccolta di annotazioni Jetpack. Puoi accedere alla libreria tramite androidx.annotation pacchetto.

Nota: se un modulo ha una dipendenza da un processore di annotazione, devi utilizzare la configurazione delle dipendenze kapt o ksp per Kotlin o la configurazione delle dipendenze annotationProcessor per Java per aggiungerlo la dipendenza.

Aggiungi annotazioni al progetto

Per attivare le annotazioni nel tuo progetto, aggiungi androidx.annotation:annotation alla libreria o all'app. Tutte le annotazioni che aggiungi vengono controllate quando esegui un codice l'ispezione o l'attività lint.

Aggiungi la dipendenza dalla libreria di annotazioni Jetpack

La raccolta di annotazioni Jetpack è pubblicata su Repository Maven di Google. Per aggiungere la libreria Jetpack Anotations al tuo progetto, includi quanto segue riga nel blocco dependencies di build.gradle o File build.gradle.kts:

Kotlin

dependencies {
    implementation("androidx.annotation:annotation:1.8.2")
}

Alla moda

dependencies {
    implementation 'androidx.annotation:annotation:1.8.2'
}

Quindi, fai clic su Sincronizza ora nella barra degli strumenti o nella notifica di sincronizzazione visualizzata.

Se utilizzi le annotazioni nel tuo modulo della biblioteca, queste verranno incluse come parte del Artefatto Android Archive (AAR) in formato XML nel file annotations.zip. L'aggiunta del parametro La dipendenza androidx.annotation non introduce una dipendenza per nessun utente downstream della tua raccolta.

Nota: se utilizzi altre librerie Jetpack, potrebbe non essere necessario aggiungere la dipendenza androidx.annotation. Perché molti altri Le librerie Jetpack dipendono dalla libreria delle annotazioni, potresti avere già accesso ai annotazioni.

Per un elenco completo delle annotazioni incluse nel repository Jetpack, vedi Libreria di annotazioni Jetpack riferimento oppure utilizza la funzionalità di completamento automatico per visualizzare le opzioni disponibili Informativa import androidx.annotation..

Esegui ispezioni del codice

Per avviare un'ispezione del codice da Android Studio, che include la convalida di annotazioni e controllo automatico lint, seleziona Analizza > Ispeziona il codice dalla o dal menu Fogli Google. Android Studio mostra messaggi di conflitto per segnalare potenziali problemi nei punti in cui il codice sono in conflitto con le annotazioni e suggerendo possibili risoluzioni.

Puoi anche applicare le annotazioni eseguendo il comando lint utilizzando la riga di comando. Questo potrebbe essere utile per segnalare problemi con un server di integrazione continua, l'attività lint non applica il valore nullo annotazioni (descritte nella sezione seguente); solo Android Studio. Per ulteriori informazioni informazioni sull'abilitazione e l'esecuzione del lint ispezioni, consulta Migliorare il codice con lint controlli.

Sebbene i conflitti di annotazioni generino avvisi, questi avvisi non impediscono alla tua app la compilazione.

Annotazioni nullità

Le annotazioni di nullità possono essere utili nel codice Java per stabilire se i valori possono essere nulli. Sono meno utili nel codice Kotlin, in quanto Kotlin ha delle regole incorporate nei valori null che vengono applicate durante la compilazione.

Aggiungi @Nullable e @NonNull annotazioni per verificare la nullità di una determinata variabile, parametro o valore restituito. @Nullable L'annotazione indica una variabile, un parametro o un valore restituito che può essere nullo. @NonNull indica una variabile, un parametro o un valore restituito che non può essere nullo.

Ad esempio, se una variabile locale contenente un valore nullo viene passata come parametro a un metodo con l'annotazione @NonNull associata a tale parametro, la creazione del codice genera che indica un conflitto diverso da null. Inoltre, il tentativo di fare riferimento al risultato di contrassegnato da @Nullable senza prima verificare se il risultato è nullo genera con un avviso di nullità. Utilizza solo @Nullable sul valore restituito di un metodo se ogni utilizzo del metodo deve essere sottoposto a controllo esplicito di null.

L'esempio seguente mostra l'uso di valori null in azione. Il codice di esempio Kotlin non sfrutta l'annotazione @NonNull perché viene aggiunta automaticamente al bytecode generato quando viene specificato un tipo che non supporta i valori null. L'esempio Java utilizza l'annotazione @NonNull sui parametri context e attrs per verificare che i valori dei parametri passati non sono nulli. Controlla inoltre che il metodo onCreateView() stesso non restituisca null:

Kotlin

...
    /** Annotation not used because of the safe-call operator(?)**/
    override fun onCreateView(
            name: String?,
            context: Context,
            attrs: AttributeSet
    ): View? {
        ...
    }
...

Java

import androidx.annotation.NonNull;
...
    /** Add support for inflating the <fragment> tag. **/
    @NonNull
    @Override
    public View onCreateView(String name, @NonNull Context context,
      @NonNull AttributeSet attrs) {
      ...
      }
...

Analisi di nullità

Android Studio supporta l'esecuzione di un'analisi dei valori NULL per l'inferenza automatica e inserisci annotazioni di nullità nel codice. Un'analisi dei dati con supporto nullo i contratti in tutte le gerarchie di metodi nel codice per rilevare:

• Metodi di chiamata che possono restituire un valore nullo.
• Metodi che non devono restituire un valore nullo.
• Variabili come campi, variabili locali e parametri, che possono essere null.
• Variabili, ad esempio campi, variabili locali e parametri, che non possono con un valore nullo.

L'analisi inserisce quindi automaticamente le annotazioni null appropriate le località rilevate.

Per eseguire un'analisi dei valori null in Android Studio, seleziona Analyze > Deduci nullità. Android Studio inserisce le annotazioni @Nullable e @NonNull di Android posizioni rilevate nel codice. Dopo aver eseguito un'analisi dei valori null, è buona norma verificare annotazioni inserite.

Nota: quando aggiungi annotazioni di nullità, il completamento automatico potrebbe suggerisci l'IntelliJ @Nullable e @NotNull annotazioni anziché annotazioni null Android e importare automaticamente la libreria corrispondente. Tuttavia, Android Studio La funzionalità di controllo pelucchi cerca solo le annotazioni null Android. Durante la verifica del , verifica che il tuo progetto utilizzi le annotazioni Android null in modo che lo strumento di controllo pelucchi può avvisarti in modo adeguato durante l'ispezione del codice.

Annotazioni per le risorse

La convalida dei tipi di risorse può essere utile perché i riferimenti Android alle risorse, ad esempio le risorse drawable e string, vengono passati come numeri interi.

Codice che prevede che un parametro faccia riferimento a un tipo specifico di risorsa, ad esempio String, può essere passato al tipo di riferimento previsto di int, ma in realtà fa riferimento a un altro e un tipo di risorsa, ad esempio una risorsa R.string.

Ad esempio, aggiungi annotazioni @StringRes a verifica se un parametro risorsa contiene un riferimento R.string, come mostrato qui:

Kotlin

abstract fun setTitle(@StringRes resId: Int)

Java

public abstract void setTitle(@StringRes int resId)

Durante l'ispezione del codice, l'annotazione genera un avviso se un riferimento R.string non viene passato nel parametro.

È possibile aggiungere annotazioni per altri tipi di risorse, ad esempio @DrawableRes, @DimenRes, @ColorRes e @InterpolatorRes vengono aggiunti utilizzando lo stesso formato di annotazione ed eseguiti durante l'ispezione del codice.

Se il tuo parametro supporta più tipi di risorse, puoi inserire più di un'annotazione del tipo di risorsa . Usa @AnyRes per indicare che il parametro annotato può essere qualsiasi tipo di risorsa R.

Sebbene sia possibile usare @ColorRes per specificare che deve essere una risorsa colore, un numero intero colore (nei valori RRGGBB o AARRGGBB) non è riconosciuto come risorsa di colore. Utilizza invece l'annotazione @ColorInt per indicano che un parametro deve essere un numero intero di colore. Gli strumenti di creazione contrassegneranno il codice errato che trasmette un ID risorsa colore come android.R.color.black, anziché un numero intero colore, ai metodi annotati.

Annotazioni dei thread

Le annotazioni dei thread controllano se un metodo viene chiamato da un tipo specifico di thread. Il seguente thread le annotazioni sono supportate:

• @MainThread
• @UiThread
• @WorkerThread
• @BinderThread
• @AnyThread

Gli strumenti di creazione trattano @MainThread @UiThread annotazioni intercambiabili, quindi puoi chiamare @UiThread dei metodi @MainThread e viceversa. Tuttavia, è possibile che una UI il thread sia diverso dal thread principale nel caso di app di sistema con più visualizzazioni su diversi thread. Di conseguenza, devi annotare i metodi associati alla gerarchia delle visualizzazioni di un'app con @UiThread e annota solo i metodi associati al ciclo di vita di un'app con @MainThread.

Se tutti i metodi in una classe condividono lo stesso requisito di organizzazione dei thread, puoi aggiungere un singolo thread un'annotazione per la classe per verificare che tutti i metodi nella classe siano chiamati dallo stesso tipo di .

Un uso comune delle annotazioni nei thread è quello di convalidare metodi o classi annotati con @WorkerThread vengono chiamati solo da un thread appropriato in background.

Annotazioni dei vincoli di valore

Usa @IntRange, @FloatRange e @Size annotazioni in convalidare i valori dei parametri trasmessi. Sia @IntRange che @FloatRange sono più utili quando vengono applicati a parametri per i quali è probabile che l'intervallo sia errato.

L'annotazione @IntRange convalida che un parametro intero o lungo è compreso in un intervallo specificato. L'esempio seguente indica che alpha deve contenere un valore intero compreso tra 0 e 255:

Kotlin

fun setAlpha(@IntRange(from = 0, to = 255) alpha: Int) { ... }

Java

public void setAlpha(@IntRange(from=0,to=255) int alpha) { ... }

L'annotazione @FloatRange verifica se è presente un parametro in virgola mobile o doppio rientra in un intervallo specificato di valori in virgola mobile. L'esempio seguente indica che Il parametro alpha deve contenere un valore in virgola mobile compreso tra 0,0 e 1,0:

Kotlin

fun setAlpha(@FloatRange(from = 0.0, to = 1.0) alpha: Float) {...}

Java

public void setAlpha(@FloatRange(from=0.0, to=1.0) float alpha) {...}

L'annotazione @Size controlla le dimensioni di una raccolta o o la lunghezza di una stringa. L'annotazione @Size può essere utilizzata per verificare le seguenti qualità:

• Dimensioni minime, ad esempio @Size(min=2)
• Dimensioni massime, ad esempio @Size(max=2)
• Dimensioni esatte, ad esempio @Size(2)
• Un numero di cui la dimensione deve essere un multiplo, ad esempio @Size(multiple=2)

Ad esempio, @Size(min=1) controlla se una raccolta non è vuota e @Size(3) verifica che un array contenga esattamente tre valori.

L'esempio seguente indica che L'array location deve contenere almeno un elemento:

Kotlin

fun getLocation(button: View, @Size(min=1) location: IntArray) {
    button.getLocationOnScreen(location)
}

Java

void getLocation(View button, @Size(min=1) int[] location) {
    button.getLocationOnScreen(location);
}

Annotazioni relative alle autorizzazioni

Usa @RequiresPermission per convalidare le autorizzazioni del chiamante per un metodo. Per verificare la presenza di una singola autorizzazione da un elenco di autorizzazioni valide, usa l'attributo anyOf. Per verificare l'esistenza di un insieme di autorizzazioni, usa l'attributo allOf. L'esempio seguente annota le setWallpaper() per indicare che il chiamante del metodo deve avere il metodo Autorizzazione permission.SET_WALLPAPERS:

Kotlin

@RequiresPermission(Manifest.permission.SET_WALLPAPER)
@Throws(IOException::class)
abstract fun setWallpaper(bitmap: Bitmap)

Java

@RequiresPermission(Manifest.permission.SET_WALLPAPER)
public abstract void setWallpaper(Bitmap bitmap) throws IOException;

L'esempio seguente richiede il chiamante del metodo copyImageFile() avere accesso in lettura alla memoria esterna e in lettura alla posizione metadati nell'immagine copiata:

Kotlin

@RequiresPermission(allOf = [
    Manifest.permission.READ_EXTERNAL_STORAGE,
    Manifest.permission.ACCESS_MEDIA_LOCATION
])
fun copyImageFile(dest: String, source: String) {
    ...
}

Java

@RequiresPermission(allOf = {
    Manifest.permission.READ_EXTERNAL_STORAGE,
    Manifest.permission.ACCESS_MEDIA_LOCATION})
public static final void copyImageFile(String dest, String source) {
    //...
}

Per le autorizzazioni per gli intent, inserisci il requisito di autorizzazione nel campo stringa che definisce la nome azione intent:

Kotlin

@RequiresPermission(android.Manifest.permission.BLUETOOTH)
const val ACTION_REQUEST_DISCOVERABLE = "android.bluetooth.adapter.action.REQUEST_DISCOVERABLE"

Java

@RequiresPermission(android.Manifest.permission.BLUETOOTH)
public static final String ACTION_REQUEST_DISCOVERABLE =
            "android.bluetooth.adapter.action.REQUEST_DISCOVERABLE";

Per le autorizzazioni per i fornitori di contenuti che richiedono autorizzazioni separate per la lettura e la scrittura l'accesso, racchiudi ogni requisito di autorizzazione in una @RequiresPermission.Read o @RequiresPermission.Write annotazione:

Kotlin

@RequiresPermission.Read(RequiresPermission(READ_HISTORY_BOOKMARKS))
@RequiresPermission.Write(RequiresPermission(WRITE_HISTORY_BOOKMARKS))
val BOOKMARKS_URI = Uri.parse("content://browser/bookmarks")

Java

@RequiresPermission.Read(@RequiresPermission(READ_HISTORY_BOOKMARKS))
@RequiresPermission.Write(@RequiresPermission(WRITE_HISTORY_BOOKMARKS))
public static final Uri BOOKMARKS_URI = Uri.parse("content://browser/bookmarks");

Autorizzazioni indirette

Quando un'autorizzazione dipende dal valore specifico fornito al parametro di un metodo, utilizza @RequiresPermission sul parametro stesso senza elencare le autorizzazioni specifiche. Ad esempio, startActivity(Intent) utilizza un'autorizzazione indiretta per l'intent passato al metodo:

Kotlin

abstract fun startActivity(@RequiresPermission intent: Intent, bundle: Bundle?)

Java

public abstract void startActivity(@RequiresPermission Intent intent, @Nullable Bundle)

Quando utilizzi le autorizzazioni indirette, gli strumenti di creazione eseguono l'analisi del flusso di dati per verificare se l'argomento passato nel metodo ha annotazioni @RequiresPermission. Quindi applicare in modo forzato le annotazioni esistenti dal parametro sul metodo stesso. Nella startActivity(Intent) esempio, le annotazioni nella classe Intent causano gli avvisi risultanti sugli utilizzi non validi di startActivity(Intent) quando un intent senza l'appropriata autorizzazioni vengono passate al metodo, come mostrato nella figura 1.

Figura 1. L'avviso generato da una risposta indiretta annotazione relativa alle autorizzazioni sul metodo startActivity(Intent).

Gli strumenti di creazione generano l'avviso su startActivity(Intent) dall'annotazione sul nome dell'azione per intent corrispondente nella classe Intent:

Kotlin

@RequiresPermission(Manifest.permission.CALL_PHONE)
const val ACTION_CALL = "android.intent.action.CALL"

Java

@RequiresPermission(Manifest.permission.CALL_PHONE)
public static final String ACTION_CALL = "android.intent.action.CALL";

Se necessario, puoi sostituire @RequiresPermission con @RequiresPermission.Read o @RequiresPermission.Write durante l'annotazione parametro di un metodo. Tuttavia, per le autorizzazioni indirette @RequiresPermission deve non può essere utilizzato insieme alle annotazioni delle autorizzazioni di lettura o di scrittura.

Annotazioni per i valori restituiti

Utilizza l'annotazione @CheckResult per verificare che il risultato o il valore restituito di un metodo sia effettivamente utilizzato. Invece di annotare ogni non void con @CheckResult, aggiungi l'annotazione per chiarire i risultati di metodi che potrebbero generare confusione.

Ad esempio, i nuovi sviluppatori Java spesso pensano erroneamente che <String>.trim() rimuove gli spazi vuoti dalla stringa originale. Annotazione il metodo con flag @CheckResult utilizza di <String>.trim() in cui il chiamante non fa nulla con il valore restituito del metodo.

L'esempio seguente annota checkPermissions() per verificare se il valore restituito del metodo è a cui viene fatto riferimento. Denomina anche enforcePermission() quale metodo da suggerire allo sviluppatore in sostituzione:

Kotlin

@CheckResult(suggest = "#enforcePermission(String,int,int,String)")
abstract fun checkPermission(permission: String, pid: Int, uid: Int): Int

Java

@CheckResult(suggest="#enforcePermission(String,int,int,String)")
public abstract int checkPermission(@NonNull String permission, int pid, int uid);

Annotazioni CallSuper

Utilizza l'annotazione @CallSuper per verificare che un metodo di override chiami la super-implementazione del metodo.

Le seguenti esempio annota il metodo onCreate() per garantire che qualsiasi metodo di override le implementazioni richiamano super.onCreate():

Kotlin

@CallSuper
override fun onCreate(savedInstanceState: Bundle?) {
}

Java

@CallSuper
protected void onCreate(Bundle savedInstanceState) {
}

Annotazioni Typedef

Le annotazioni Typedef controllano se un particolare parametro, un valore restituito o un campo fa riferimento a un insieme specifico di costanti. Consentono inoltre al completamento del codice che offrano le costanti consentite.

Utilizza @IntDef e @StringDef annotazioni per creare annotazioni enumerate di set di numeri interi e stringhe per convalidare altre tipi di riferimenti al codice.

Le annotazioni Typedef utilizzano @interface per dichiarare il nuovo tipo di annotazione enumerata. Le annotazioni @IntDef e @StringDef, insieme a @Retention, annotano la nuova annotazione e sono necessari per definire la enumerato. L'annotazione @Retention(RetentionPolicy.SOURCE) indica al compilatore non archiviare i dati delle annotazioni enumerate nel file .class.

L'esempio seguente mostra i passaggi per creare un'annotazione che verifica se un valore è stato passato come metodo, il parametro fa riferimento a una delle costanti definite:

Kotlin

import androidx.annotation.IntDef
//...
// Define the list of accepted constants and declare the NavigationMode annotation.
@Retention(AnnotationRetention.SOURCE)
@IntDef(NAVIGATION_MODE_STANDARD, NAVIGATION_MODE_LIST, NAVIGATION_MODE_TABS)
annotation class NavigationMode

// Declare the constants.
const val NAVIGATION_MODE_STANDARD = 0
const val NAVIGATION_MODE_LIST = 1
const val NAVIGATION_MODE_TABS = 2

abstract class ActionBar {

    // Decorate the target methods with the annotation.
    // Attach the annotation.
    @get:NavigationMode
    @setparam:NavigationMode
    abstract var navigationMode: Int

}

Java

import androidx.annotation.IntDef;
//...
public abstract class ActionBar {
    //...
    // Define the list of accepted constants and declare the NavigationMode annotation.
    @Retention(RetentionPolicy.SOURCE)
    @IntDef({NAVIGATION_MODE_STANDARD, NAVIGATION_MODE_LIST, NAVIGATION_MODE_TABS})
    public @interface NavigationMode {}

    // Declare the constants.
    public static final int NAVIGATION_MODE_STANDARD = 0;
    public static final int NAVIGATION_MODE_LIST = 1;
    public static final int NAVIGATION_MODE_TABS = 2;

    // Decorate the target methods with the annotation.
    @NavigationMode
    public abstract int getNavigationMode();

    // Attach the annotation.
    public abstract void setNavigationMode(@NavigationMode int mode);
}

Quando crei questo codice, viene generato un avviso se il parametro mode non corrisponde fare riferimento a una delle costanti definite (NAVIGATION_MODE_STANDARD, NAVIGATION_MODE_LIST o NAVIGATION_MODE_TABS).

Combina @IntDef e @IntRange per indicare che un un numero intero può essere un insieme dato di costanti o un valore all'interno di un intervallo.

Attiva la combinazione di costanti e flag

Se gli utenti possono combinare le costanti consentite con un flag (ad esempio |, &, ^ e così via), puoi definire un'annotazione con un flag per verificare se un parametro o un valore restituito fa riferimento a un pattern valido.

L'esempio seguente crea l'annotazione DisplayOptions con un elenco di valori validi Costanti DISPLAY_:

Kotlin

import androidx.annotation.IntDef
...

@IntDef(flag = true, value = [
    DISPLAY_USE_LOGO,
    DISPLAY_SHOW_HOME,
    DISPLAY_HOME_AS_UP,
    DISPLAY_SHOW_TITLE,
    DISPLAY_SHOW_CUSTOM
])
@Retention(AnnotationRetention.SOURCE)
annotation class DisplayOptions
...

Java

import androidx.annotation.IntDef;
...

@IntDef(flag=true, value={
        DISPLAY_USE_LOGO,
        DISPLAY_SHOW_HOME,
        DISPLAY_HOME_AS_UP,
        DISPLAY_SHOW_TITLE,
        DISPLAY_SHOW_CUSTOM
})
@Retention(RetentionPolicy.SOURCE)
public @interface DisplayOptions {}

...

Quando crei un codice con un flag di annotazione, viene generato un avviso se il parametro decorato o il valore restituito non fa riferimento a un pattern valido.

Mantieni annotazione

@Keep annotazione garantisce che una classe o un metodo annotato non venga rimosso quando il codice viene minimizzato al momento della creazione. Questa annotazione è in genere a metodi e classi a cui si accede attraverso la riflessione per impedire al compilatore trattando il codice come inutilizzato.

Attenzione : le classi e i metodi a cui aggiungi annotazioni che utilizzano @Keep vengono sempre visualizzati nell'APK dell'app, anche se non fare riferimento a queste classi e a questi metodi nella logica della tua app.

Per contenere le dimensioni dell'app, valuta se è necessario mantenere ogni annotazione @Keep nella tua app. Se usi la riflessione per per accedere a una classe o a un metodo annotati, utilizza condizionale -if nelle regole di ProGuard, specificando la classe che genera il richiamo della riflessione.

Per ulteriori informazioni su come minimizzare il codice e specificare quale codice non deve essere rimosso, consulta Ridurre, offuscare e ottimizzare l'app.

Annotazioni sulla visibilità del codice

Utilizza le seguenti annotazioni per indicare la visibilità di parti specifiche del codice, come metodi, classi, campi o pacchetti.

Rendi visibile il codice per i test

La @VisibleForTesting l'annotazione indica che un metodo annotato è più visibile del solito necessario per testabile. Questa annotazione ha un argomento facoltativo otherwise che ti consente indicare la visibilità del metodo se non per la necessità di renderlo visibile per i test. Lint utilizza l'argomento otherwise per applicare la visibilità prevista.

Nell'esempio seguente, myMethod() è normalmente private, ma è package-private per i test. Con VisibleForTesting.PRIVATE designazione, lint visualizza un messaggio se questo metodo viene chiamato dall'esterno contesto consentito dall'accesso private, ad esempio da un'unità di compilazione diversa.

Kotlin

@VisibleForTesting(otherwise = VisibleForTesting.PRIVATE)
fun myMethod() {
    ...
}

Java

@VisibleForTesting(otherwise = VisibleForTesting.PRIVATE)
void myMethod() { ... }

Puoi anche specificare @VisibleForTesting(otherwise = VisibleForTesting.NONE) per indicare che un metodo esiste solo per i test. Questo modulo equivale all'utilizzo @RestrictTo(TESTS). Entrambi eseguono lo stesso controllo del lint.

Limita un'API

@RestrictTo l'annotazione indica che l'accesso all'API annotata (pacchetto, classe o metodo) è limitato, come segue:

Sottoclassi

Utilizza il modulo di annotazione @RestrictTo(RestrictTo.Scope.SUBCLASSES) per limitare Accesso API solo alle sottoclassi.

Solo le classi che estendono la classe annotata possono accedere a questa API. Java Il modificatore protected non è abbastanza restrittivo perché consente l'accesso da classi non correlate all'interno dello stesso pacchetto. Inoltre, ci sono casi in cui vuoi abbandonare una metodo public per flessibilità futura, perché non sarà mai possibile protected e il metodo di cui è stato eseguito l'override public, ma vuoi fornire un valore suggerisce che la classe è destinata solo agli utilizzi all'interno della classe o solo dalle sottoclassi.

Biblioteche

Utilizza il modulo di annotazione @RestrictTo(RestrictTo.Scope.LIBRARY_GROUP_PREFIX) per limitare l'accesso API solo alle tue librerie.

Solo il tuo codice libreria può accedere all'API annotata. Questo ti consente non solo di organizzare il codice nella gerarchia di pacchetti desiderata, ma anche condividere il codice in un gruppo di librerie correlate. Questa opzione è già disponibile per il Jetpack contenenti una grande quantità di codice di implementazione che non è destinato all'uso esterno, ma che deve essere public per condividerlo tra le varie librerie Jetpack complementari.

Test

Utilizza il modulo di annotazione @RestrictTo(RestrictTo.Scope.TESTS) per impedire ad altri agli sviluppatori di accedere alle API di test.

Solo il codice di test può accedere all'API annotata. Questo impedisce ad altri sviluppatori di non utilizzare le API per lo sviluppo contenuto solo a scopo di test.