Migliora l'ispezione del codice con le annotazioni

L'utilizzo di strumenti di ispezione del codice, come lint, può aiutarti a trovare problemi e migliorare il codice, ma gli strumenti di ispezione possono dedurre solo fino a un certo punto. Ad esempio, gli ID risorsa Android utilizzano un int per identificare stringhe, elementi grafici, colori e altri tipi di risorse, pertanto gli strumenti di ispezione non possono capire quando hai specificato una risorsa stringa dove avresti dovuto specificare un colore. In questa situazione, l'app potrebbe non essere visualizzata correttamente o non riuscire a funzionare, anche se utilizzi l'ispezione del codice.

Le annotazioni ti consentono di fornire suggerimenti agli strumenti di ispezione del codice, come lint, per rilevare questi problemi di codice più sottili. Le annotazioni vengono aggiunte come tag dei metadati che colleghi a variabili, parametri e valori restituiti per ispezionare i valori restituiti dei metodi, i parametri passati, le variabili locali e i campi. Se utilizzate con gli strumenti di ispezione del codice, le annotazioni possono aiutarti a rilevare problemi come eccezioni di puntatore nullo e conflitti di tipo di risorsa.

Android supporta una serie di annotazioni tramite la libreria Jetpack Annotations. Puoi accedere alla raccolta tramite il androidx.annotation package.

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

Aggiungere annotazioni al progetto

Per attivare le annotazioni nel progetto, aggiungi la dipendenza androidx.annotation:annotation alla tua libreria o app. Le annotazioni aggiunte vengono controllate quando esegui un'ispezione del codice o un'attività lint.

Aggiungi la dipendenza della libreria Jetpack Annotations

La libreria Jetpack Annotations è pubblicata nel Repository Maven di Google. Per aggiungere la libreria Jetpack Annotations al progetto, includi la seguente riga nel blocco dependencies del file build.gradle o build.gradle.kts:

Kotlin

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

Groovy

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

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

Se utilizzi le annotazioni nel tuo modulo della libreria, queste vengono incluse nell'elemento Android Archive (AAR) in formato XML nel file annotations.zip. L'aggiunta della dipendenza androidx.annotation non introduce una dipendenza per gli utenti a valle della tua libreria.

Nota: se utilizzi altre librerie Jetpack, potrebbe non essere necessario aggiungere la dipendenza androidx.annotation. Poiché molte altre librerie Jetpack dipendono dalla libreria di annotazioni, potresti già avere accesso alle annotazioni.

Per un elenco completo delle annotazioni incluse nel repository di Jetpack, consulta la documentazione di riferimento della libreria di annotazioni di Jetpack o utilizza la funzionalità di completamento automatico per visualizzare le opzioni disponibili per l'istruzione import androidx.annotation..

Esegui ispezioni del codice

Per avviare un'ispezione del codice da Android Studio, che include la convalida delle annotazioni e il controllo automatico di lint, seleziona Analizza > Controlla codice dal menu. Android Studio mostra messaggi di conflitto per segnalare potenziali problemi in cui il codice è in conflitto con le annotazioni e per suggerire possibili soluzioni.

Puoi anche applicare le annotazioni eseguendo il compito lint utilizzando la riga di comando. Sebbene questa operazione possa essere utile per segnalare problemi con un server di integrazione continua, il task lint non applica le annotazioni di nullità (descritte nella sezione seguente); solo Android Studio lo fa. Per ulteriori informazioni sull'attivazione e sull'esecuzione delle ispezioni di lint, consulta Migliorare il codice con i controlli lint.

Anche se i conflitti di annotazioni generano avvisi, questi avvisi non impediscono la compilazione dell'app.

Annotazioni di nullità

Le annotazioni di nullità possono essere utili nel codice Java per stabilire se i valori possono essere null. Sono meno utili nel codice Kotlin, in quanto Kotlin ha regole di nullità integrate che vengono applicate al compilazione.

Aggiungi le annotazioni @Nullable e @NonNull per verificare l'assenza di valore di una determinata variabile, parametro o valore restituito. L'annotazione @Nullable indica una variabile, un parametro o un valore restituito che può essere null. @NonNull indica una variabile, un parametro o un valore restituito che non può essere null.

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

L'esempio seguente mostra la nullabilità in azione. Il codice di esempio Kotlin non sfrutta l'annotazione @NonNull perché viene aggiunto automaticamente al bytecode generato quando viene specificato un tipo non null. L'esempio Java sfrutta l'annotazione @NonNull sui parametri context e attrs per verificare che i valori parametro passati non siano null. Verifica 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 dell'annullabilità

Android Studio supporta l'esecuzione di un'analisi di nullità per dedurre automaticamente e inserire annotazioni di nullità nel codice. Un'analisi della nullabilità analizza i contratti nelle gerarchie dei metodi nel codice per rilevare:

• Chiamata di metodi che possono restituire null.
• Metodi che non devono restituire null.
• Variabili, come campi, variabili locali e parametri, che possono essere null.
• Variabili, come campi, variabili locali e parametri, che non possono contenere un valore nullo.

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

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

Nota:quando aggiungi annotazioni di nullità, il completamento automatico potrebbe suggerire le annotazioni IntelliJ @Nullable e @NotNull anziché le annotazioni null di Android e potrebbe importare automaticamente la libreria corrispondente. Tuttavia, il controllo lint di Android Studio cerca solo le annotazioni null di Android. Quando verifichi le annotazioni, accertati che il progetto utilizzi le annotazioni null di Android in modo che lo strumento di controllo lint possa inviarti una notifica corretta durante l'ispezione del codice.

Annotazioni delle risorse

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

Il codice che si aspetta che un parametro faccia riferimento a un tipo specifico di risorsa, ad esempio String, può essere passato al tipo di riferimento previsto int, ma in realtà fa riferimento a un tipo diverso di risorsa, ad esempio una risorsa R.string.

Ad esempio, aggiungi annotazioni @StringRes per verificare se un parametro della risorsa contiene un riferimento R.string, come mostrato di seguito:

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 non viene passato un riferimento R.string nel parametro.

Le annotazioni per altri tipi di risorse, come @DrawableRes, @DimenRes, @ColorRes e @InterpolatorRes, possono essere aggiunte utilizzando lo stesso formato di annotazione ed eseguite durante l'ispezione del codice.

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

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

Annotazioni thread

Le annotazioni dei thread controllano se un metodo viene chiamato da un tipo specifico di thread. Sono supportate le seguenti annotazioni del thread:

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

Gli strumenti di compilazione trattano le annotazioni @MainThread e @UiThread come intercambiabili, quindi puoi chiamare metodi @UiThread dai metodi @MainThread e viceversa. Tuttavia, è possibile che un thread dell'interfaccia utente sia diverso dal thread principale, nel caso di app di sistema con più visualizzazioni su thread diversi. Pertanto, devi annotare i metodi associati alla gerarchia delle visualizzazioni di un'app con @UiThread e solo i metodi associati al ciclo di vita di un'app con @MainThread.

Se tutti i metodi di una classe condividono lo stesso requisito di threading, puoi aggiungere una singola annotazione del thread alla classe per verificare che tutti i metodi della classe vengano chiamati dallo stesso tipo di thread.

Un uso comune delle annotazioni dei thread è convalidare che i metodi o le classi annotati con @WorkerThread vengano chiamati solo da un thread di background appropriato.

Annotazioni dei vincoli di valore

Utilizza le annotazioni @IntRange, @FloatRange e @Size per convalidare i valori dei parametri passati. Sia @IntRange che @FloatRange sono più utili se applicati a parametri in cui gli utenti potrebbero commettere errori nell'intervallo.

L'annotazione @IntRange convalida che un valore parametro intero o lungo rientri in un intervallo specificato. Il seguente esempio indica che il parametro 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 un valore del parametro float o double rientra in un intervallo specificato di valori con virgola mobile. L'esempio seguente indica che il parametro alpha deve contenere un valore float 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 di un array 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) convalida 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 sulle autorizzazioni

Utilizza l'annotazione @RequiresPermission per convalidare le autorizzazioni dell'autore di chiamata di un metodo. Per verificare la presenza di una singola autorizzazione da un elenco di autorizzazioni valide, utilizza l'attributo anyOf. Per verificare la presenza di un insieme di autorizzazioni, utilizza l'attributo allOf. Nell'esempio seguente viene annotato il metodo setWallpaper() per indicare che il chiamante del metodo deve disporre dell'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 che il chiamante del metodo copyImageFile() abbia sia accesso in lettura allo spazio di archiviazione esterno sia accesso in lettura ai metadati della posizione 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 di stringa che definisce il nome dell'azione dell'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 l'accesso in lettura e scrittura, racchiudi ogni requisito di autorizzazione in un'annotazione @RequiresPermission.Read o @RequiresPermission.Write:

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, il metodo startActivity(Intent) utilizza un'autorizzazione indiretta sull'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 compilazione eseguono l'analisi del flusso di dati per verificare se l'argomento passato al metodo contiene annotazioni @RequiresPermission. Quindi, applicano eventuali annotazioni esistenti del parametro al metodo stesso. Nell'esempiostartActivity(Intent), le annotazioni nella classe startActivity(Intent) causano gli avvisi risultanti sugli utilizzi non validi di startActivity(Intent) quando un intent senza le autorizzazioni appropriate viene passato al metodo, come mostrato nella figura 1.Intent

Figura 1. L'avviso generato da un'annotazione delle autorizzazioni indirette sul metodo startActivity(Intent).

Gli strumenti di compilazione generano l'avviso su startActivity(Intent) dall'annotazione sul nome dell'azione di 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 quando annoti il parametro di un metodo. Tuttavia, per le autorizzazioni indirette @RequiresPermission non deve essere utilizzato in combinazione con le annotazioni delle autorizzazioni di lettura o scrittura.

Annotazioni del valore restituito

Utilizza l'annotazione @CheckResult per verificare che il risultato o il valore restituito di un metodo venga effettivamente utilizzato. Anziché annotare ogni metodo non vuoto con @CheckResult, aggiungi l'annotazione per chiarire i risultati di metodi potenzialmente confusi.

Ad esempio, i nuovi sviluppatori Java spesso pensano erroneamente che <String>.trim() rimuovi gli spazi dalla stringa originale. Annotare il metodo con gli indicatori @CheckResult indica gli utilizzi di <String>.trim() in cui il chiamante non fa nulla con il valore restituito del metodo.

L'esempio seguente annota il metodo checkPermissions() per verificare se viene effettivamente fatto riferimento al valore restituito del metodo. Inoltre, indica il enforcePermission() metodo come metodo da suggerire allo sviluppatore come sostituto:

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 l'implementazione super del metodo.

L'esempio seguente annota il metodo onCreate() per assicurarsi che eventuali implementazioni del metodo che lo sostituiscono chiamino super.onCreate():

Kotlin

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

Java

@CallSuper
protected void onCreate(Bundle savedInstanceState) {
}

Annotazioni typedef

Le annotazioni typedef controllano se un determinato parametro, valore restituito o campo fa riferimento a un insieme specifico di costanti. Inoltre, consentono al completamento del codice di offrire automaticamente le costanti consentite.

Utilizza le annotazioni @IntDef e @StringDef per creare annotazioni enumerate di insiemi di numeri interi e stringhe per convalidare altri tipi di riferimenti di codice.

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

L'esempio seguente mostra i passaggi per creare un'annotazione che verifica se un valore passato come parametro di metodo 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 generi questo codice, viene generato un avviso se il parametro mode non fa riferimento a una delle costanti definite (NAVIGATION_MODE_STANDARD,NAVIGATION_MODE_LIST o NAVIGATION_MODE_TABS).

Combina @IntDef e @IntRange per indicare che un intero può essere un determinato insieme di costanti o un valore compreso in un intervallo.

Consenti la combinazione di costanti con flag

Se gli utenti possono combinare le costanti consentite con un flag (ad esempio |, &, ^ e così via), puoi definire un'annotazione con un attributo 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 costanti DISPLAY_ valide:

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 il 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

L'annotazione @Keep assicura che un metodo o una classe annotati non vengano rimossi quando il codice viene minimizzato in fase di compilazione. In genere, questa annotazione viene aggiunta ai metodi e alle classi a cui si accede tramite la riflessione per impedire al compilatore di trattare il codice come inutilizzato.

Attenzione: le classi e i metodi annotati utilizzando @Keep vengono sempre visualizzati nell'APK della tua app, anche se non fai mai riferimento a queste classi e metodi all'interno della logica della tua app.

Per mantenere ridotte le dimensioni dell'app, valuta se è necessario conservare ogni annotazione @Keep nell'app. Se utilizzi la riflessione per accedere a un metodo o a una classe annotata, utilizza un'istruzione condizionale -if nelle regole di ProGuard, specificando la classe che esegue le chiamate di riflessione.

Per ulteriori informazioni su come ridurre il codice e specificare quale codice non deve essere rimosso, consulta Riduci, offusca e ottimizza l'app.

Annotazioni sulla visibilità del codice

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

Rendere il codice visibile per i test

L'annotazione @VisibleForTesting indica che un metodo annotato è più visibile del normale per renderlo testabile. Questa annotazione ha un argomento facoltativo otherwise che ti consente di designare la visibilità del metodo se non fosse necessario 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 la designazione VisibleForTesting.PRIVATE, lint visualizza un messaggio se questo metodo viene chiamato dall'esterno del 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 è uguale all'utilizzo di @RestrictTo(TESTS). Entrambi eseguono lo stesso controllo lint.

Limitare un'API

L'annotazione @RestrictTo 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 l'accesso all'API solo ai sottoinsiemi.

Solo le classi che estendono la classe annotata possono accedere a questa API. Il modificatore Java protected non è abbastanza restrittivo, perché consente l'accesso da classi non correlate all'interno dello stesso pacchetto. Inoltre, in alcuni casi potresti voler lasciare un metodo public per una maggiore flessibilità futura, perché non puoi mai creare un metodo public precedente e un metodo public sostituito, ma vuoi fornire un suggerimento che indichi che la classe è destinata all'utilizzo solo all'interno della classe o da sottoclassi.protected

Biblioteche

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

Solo il codice della libreria può accedere all'API annotata. In questo modo, non solo puoi organizzare il codice nella gerarchia del pacchetto che preferisci, ma anche condividerlo con un gruppo di librerie correlate. Questa opzione è già disponibile per le librerie di Jetpack che contengono molto codice di implementazione non destinato all'uso esterno, ma che deve essere public per poter essere condiviso tra le varie librerie Jetpack complementari.

Test

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

Solo il codice di test può accedere all'API annotata. In questo modo, altri sviluppatori non potranno utilizzare le API per lo sviluppo che intendi utilizzare solo a scopo di test.