アノテーションによるコード検査の改善

lint などのコード インスペクション ツールは問題の検出とコードの改善に役立ちますが、インスペクション ツールが推論できる範囲は限られています。たとえば、文字列、グラフィック、カラーなどのリソースタイプを識別するための Android リソース ID はすべて int であるため、カラーリソースを指定すべきところで文字列リソースを指定していても、インスペクション ツールは問題を認識しません。つまり、コード インスペクション ツールを使用しても、アプリが適切にレンダリングできなかったり、実行に失敗したりする可能性があります。

アノテーションを使用すると、lint などのコード インスペクション ツールにヒントを提供できます。これは、見落としやすいコードの問題を検出するのに役立ちます。アノテーションはメタデータタグとして追加されます。これを変数、パラメータ、戻り値に付加することで、メソッドの戻り値、渡されたパラメータ、ローカル変数、フィールドを検査できます。コード インスペクション ツールでアノテーションを使用すると、null ポインタ例外やリソースタイプの競合などの問題を検出できます。

Android は、Jetpack Annotations ライブラリを通じて、さまざまなアノテーションをサポートしています。このライブラリにアクセスするには、androidx.annotation パッケージを使用します。

注: モジュールがアノテーション プロセッサに依存している場合、その依存関係を追加するには、Kotlin 用の kapt か ksp の依存関係構成を使用するか、Java 用の annotationProcessor 依存関係構成を使用する必要があります。

プロジェクトにアノテーションを追加する

プロジェクトでアノテーションを有効にするには、ライブラリまたはアプリに androidx.annotation:annotation 依存関係を追加します。追加したすべてのアノテーションは、コード インスペクションまたは lint タスクを実行したときにチェックされます。

Jetpack Annotations ライブラリの依存関係を追加する

Jetpack Annotations ライブラリは、Google の Maven リポジトリで公開されています。プロジェクトに Jetpack Anotations ライブラリを追加するには、build.gradle または build.gradle.kts ファイルの dependencies ブロックに次の行を挿入します。

Kotlin

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

Groovy

dependencies {
    implementation 'androidx.annotation:annotation:1.9.1'
}
次に、ツールバーまたは表示された同期通知で、[Sync Now] をクリックします。

独自のライブラリ モジュールでアノテーションを使用する場合、アノテーションは XML 形式の Android Archive（AAR）アーティファクトの一部として、annotations.zip ファイルに含まれます。androidx.annotation 依存関係を追加しても、ライブラリのダウンストリーム ユーザーに対して依存関係は適用されません。

注: 他の Jetpack ライブラリを使用している場合は、androidx.annotation の依存関係を追加する必要はありません。他の多くの Jetpack ライブラリはアノテーション ライブラリに依存しているため、すでにアノテーションにアクセスできる可能性があります。

Jetpack リポジトリに含まれているアノテーションの一覧については、Jetpack Annotations ライブラリのリファレンスをご覧ください。また、予測入力機能を使用して、import androidx.annotation. ステートメントで使用可能なオプションを表示することもできます。

コード インスペクションを実行する

Android Studio で、アノテーションの検証と自動 lint チェックを含むコード インスペクションを開始するには、メニューから [Analyze] > [Inspect Code] を選択します。Android Studio は、競合メッセージを表示して、コードとアノテーションが競合する潜在的な問題があることを警告し、有効な解決策を提案します。

コマンドラインから lint タスクを実行して、アノテーションを適用することもできます。lint タスクは、継続的インテグレーション サーバーでの問題報告に役立つ場合がありますが、次のセクションで説明するように null 可能性アノテーションは適用しない（Android Studio のみが適用する）ことに注意してください。lint インスペクションの有効化と実行の詳細については、lint チェックでコードを改善するをご覧ください。

アノテーションが競合すると警告が生成されますが、警告が生成されてもアプリのコンパイルは可能です。

null 可能性アノテーション

null 可能性アノテーションは、Java コードで値を null にできるかどうかを適用するのに便利です。Kotlin には、コンパイル時に適用される null 可能性ルールが組み込まれているため、Kotlin コードではあまり役に立ちません。

特定の変数、パラメータ、戻り値の null 可能性をチェックするには、@Nullable アノテーションと @NonNull アノテーションを追加します。@Nullable アノテーションは null 値が許容される変数、パラメータ、戻り値を示します。@NonNull は null 値が許容されない変数、パラメータ、戻り値を示します。

たとえば、null 値を含むローカル変数がパラメータとしてメソッドに渡された場合、そのパラメータに @NonNull アノテーションが付いていると、コードをビルドしたときに非 null 競合を示す警告が生成されます。また、@Nullable としてマークされたメソッドの結果を、あらかじめ null かどうかをチェックせずに参照しようとすると、null 可能性警告が生成されます。メソッドを使用するたびに明示的に null チェックを実施する必要がある場合に限り、メソッドの戻り値に @Nullable を使用してください。

次の例は、実際の null 可能性を示しています。Kotlin のコード例では、@NonNull アノテーションを利用しません。null 値非許容型が指定されると、生成されたバイトコードにこのアノテーションが自動的に追加されるためです。Java のコード例では、context パラメータと attrs パラメータで @NonNull アノテーションを利用して、渡されたパラメータ値が null 以外かどうかをチェックします。また、onCreateView() メソッド自身の戻り値が 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) {
      ...
      }
...

null 可能性分析

Android Studio では、自動的に推論して null 可能性アノテーションをコードに挿入する null 可能性分析がサポートされています。null 可能性分析により、コード内のメソッド階層全体のコントラクトがスキャンされ、以下が検出されます。

  • null を返すことができる呼び出しメソッド。
  • null を返すべきでないメソッド。
  • null 値が許容されるフィールド、ローカル変数、パラメータなどの変数。
  • null 値が許容されないフィールド、ローカル変数、パラメータなどの変数。

この分析を行うと、分析により検出された箇所に、適切な null アノテーションが自動的に挿入されます。

Android Studio で null 可能性分析を実行するには、[Analyze] > [Infer Nullity] を選択します。これにより、コード内の検出された箇所に Android の @Nullable アノテーションと @NonNull アノテーションが挿入されます。null 可能性分析を実行した後で、挿入されたアノテーションを検証することをおすすめします。

注: null 可能性アノテーションを追加する際、予測入力は、Android の null アノテーションの代わりに IntelliJ の @Nullable および @NotNull アノテーションを候補として使用し、対応するライブラリを自動インポートすることがあります。ただし、Android Studio の lint チェッカーは、Android の null アノテーションのみを検索します。アノテーションを検証する際は、プロジェクトで Android の null アノテーションを使用していることを確認してください。これにより、コード インスペクションの際に lint チェッカーが適切な通知を行うことが可能になります。

リソース アノテーション

Android では、ドローアブル リソースや文字列リソースなどのリソースへの参照は整数として渡されるため、リソースタイプの検証が効果的です。

パラメータが String などの特定の型のリソースを参照すると想定しているコードには、想定される参照型である int が渡されることもありますが、実際に参照されるのは、R.string リソースなど、別の型のリソースであることがあります。

たとえば、リソース パラメータに R.string 参照が含まれているかどうかをチェックするには、次のように @StringRes アノテーションを追加します。

Kotlin

abstract fun setTitle(@StringRes resId: Int)

Java

public abstract void setTitle(@StringRes int resId)

コード インスペクションの際に、R.string 参照がパラメータに渡されないと、アノテーションによって警告が生成されます。

@DrawableRes、@DimenRes、@ColorRes、@InterpolatorRes など、他のリソースタイプ用のアノテーションも、同じアノテーション形式で追加して、コード インスペクションの際に実行できます。

パラメータで複数のリソースタイプをサポートする場合は、パラメータに複数のリソースタイプ アノテーションを指定できます。アノテーション付きのパラメータが、どのタイプの R リソースにも対応できることを示すには、@AnyRes を使用します。

@ColorRes を使用してパラメータをカラーリソースとして指定することもできますが、カラー整数（RRGGBB 形式または AARRGGBB 形式）はカラーリソースとして認識されません。パラメータがカラー整数でなければならないことを示すには、@ColorInt アノテーションを使用します。カラー整数ではなく、android.R.color.black などのカラーリソース ID をアノテーション付きメソッドに渡すコードは、ビルドツールにより不適切なコードと判断され、警告が生成されます。

スレッド アノテーション

スレッド アノテーションは、メソッドが特定のタイプのスレッドから呼び出されているかどうかをチェックします。以下のスレッド アノテーションがサポートされています。

ビルドツールは @MainThread アノテーションと @UiThread アノテーションを交換可能なものとして扱うので、@MainThread メソッドから @UiThread メソッドを呼び出すことも、その逆も可能です。ただし、異なるスレッドに複数のビューがあるシステムアプリの場合は、UI スレッドがメインスレッドと異なる可能性があります。したがって、アプリのビュー階層に関連付けられているメソッドには @UiThread アノテーションを付け、アプリのライフサイクルに関連付けられているメソッドにのみ @MainThread アノテーションを付ける必要があります。

1 つのクラスに含まれるすべてのメソッドが同じスレッド要件を共有している場合は、そのクラスに単一のスレッド アノテーションを追加することで、クラス内のすべてのメソッドが同じタイプのスレッドから呼び出されるかどうかを検証できます。

スレッド アノテーションの一般的な用途は、@WorkerThread アノテーションの付いたメソッドやクラスが適切なバックグラウンド スレッドからしか呼び出されないことを検証することです。

値制約アノテーション

渡されたパラメータの値を検証するには、@IntRange、@FloatRange、@Size の各アノテーションを使用します。@IntRange と @FloatRange は、ユーザーが誤った範囲を設定する可能性があるパラメータに適用すると、非常に効果的です。

@IntRange アノテーションは、int 型または long 型のパラメータ値が、指定された範囲内にあるかどうかを検証します。次の例は、alpha パラメータが 0～255 の整数値を含む必要があることを示しています。

Kotlin

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

Java

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

@FloatRange アノテーションは、float 型または double 型のパラメータ値が、指定された浮動小数点値の範囲内にあるかどうかをチェックします。次の例は、alpha パラメータが 0.0～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) {...}

@Size アノテーションは、コレクションまたは配列のサイズと、文字列の長さをチェックします。@Size アノテーションにより、以下の性質を検証できます。

  • 最小サイズ（@Size(min=2) など）
  • 最大サイズ（@Size(max=2) など）
  • 特定のサイズ（@Size(2) など）
  • サイズを倍数にする必要がある数（@Size(multiple=2) など）

たとえば、@Size(min=1) はコレクションが空でないかをチェックし、@Size(3) は配列にちょうど 3 個の値が含まれているかどうかを検証します。

次の例は、location 配列が少なくとも 1 つの要素を含む必要があることを示しています。

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);
}

権限アノテーション

メソッドの呼び出し元の権限を検証するには、@RequiresPermission アノテーションを使用します。有効な権限のリストのうち、いずれか 1 つの権限があるかどうかをチェックするには、anyOf 属性を使用します。権限のセットがあるかどうかをチェックするには、allOf 属性を使用します。以下の例では、setWallpaper() メソッドにアノテーションを付けて、このメソッドの呼び出し元に 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;

以下の例では、copyImageFile() メソッドの呼び出し元に、外部ストレージへの読み取りアクセス権と、コピーされた画像内の位置情報メタデータへの読み取りアクセス権の両方を要求しています。

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) {
    //...
}

インテントの権限の場合は、インテント アクション名を定義する文字列フィールドに権限要件を指定します。

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";

読み取りアクセスと書き込みアクセスに別々の権限を必要とするコンテンツ プロバイダの権限の場合は、@RequiresPermission.Read アノテーションと @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");

間接権限

メソッドのパラメータに渡される特定の値に権限が依存している場合は、特定の権限をリストせずに、パラメータ自体に @RequiresPermission を使用します。たとえば、以下の startActivity(Intent) メソッドでは、このメソッドに渡されるインテントに間接権限を使用しています。

Kotlin

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

Java

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

間接権限を使用した場合、ビルドツールはデータフロー分析を実行して、メソッドに渡された引数に @RequiresPermission アノテーションがあるかどうかをチェックします。次に、パラメータの既存のアノテーションをメソッド自体に適用します。startActivity(Intent) の例では、適切な権限のないインテントがメソッドに渡されると、Intent クラスのアノテーションによって、startActivity(Intent) の使用が無効であることを示す警告が生成されます（図 1 を参照）。

図 1. startActivity(Intent) メソッドの間接権限アノテーションにより生成された警告

ビルドツールは、Intent クラスの対応するインテント アクション名のアノテーションから、startActivity(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";

メソッドのパラメータにアノテーションを付ける場合、必要に応じて、@RequiresPermission.Read または @RequiresPermission.Write の代わりに、@RequiresPermission を使用できます。ただし、間接権限では、@RequiresPermission は読み取り権限アノテーションと書き込み権限アノテーションのどちらとも併用できません。

戻り値アノテーション

メソッドの結果（戻り値）が実際に使用されているかどうかを検証するには、@CheckResult アノテーションを使用します。すべての非 void メソッドに @CheckResult アノテーションを付けるのではなく、紛らわしいメソッドの結果を明確にするためにアノテーションを追加します。

たとえば、経験の浅い Java 開発者は、<String>.trim() が元の文字列から空白を削除すると勘違いしていることがあります。このメソッドに @CheckResult アノテーションを付けると、呼び出し元が <String>.trim() メソッドの戻り値を一切使用していない場合に警告が生成されます。

以下の例では、checkPermissions() メソッドにアノテーションを付けて、メソッドの戻り値が実際に参照されているかを確認しています。また、デベロッパーに候補として提示する代用メソッドとして enforcePermission() メソッドを指定しています。

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);

CallSuper アノテーション

オーバーライドする側のメソッドがメソッドの super 実装を呼び出しているかどうかを検証するには、@CallSuper アノテーションを使用します。

以下の例では、onCreate() メソッドにアノテーションを付けて、オーバーライド側のメソッドの実装が super.onCreate() を呼び出すことを保証しています。

Kotlin

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

Java

@CallSuper
protected void onCreate(Bundle savedInstanceState) {
}

Typedef アノテーション

Typedef アノテーションは、特定のパラメータ、戻り値、またはフィールドが特定の定数のセットを参照しているかを確認します。さらに、コード補完により、使用できる定数が自動的に提示されるようになります。

整数セットと文字列セットの列挙型アノテーションを作成して他の型のコード参照を検証するには、@IntDef アノテーションと @StringDef アノテーションを使用します。

Typedef アノテーションは、@interface を使用して新しい列挙型のアノテーション タイプを宣言します。@IntDef アノテーションと @StringDef アノテーションは、@Retention と一緒に使用して、新しいアノテーションを付けることができます。これらのアノテーションは列挙型を定義するために必要です。@Retention(RetentionPolicy.SOURCE) アノテーションは、列挙型アノテーションのデータを .class ファイルに保存しないようコンパイラに通知します。

以下の例は、メソッド パラメータとして渡される値が、定義済みの定数のいずれか 1 つを参照することを確認するアノテーションを作成する方法を示しています。

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);
}

このコードをビルドすると、mode パラメータが定義済みの定数（NAVIGATION_MODE_STANDARD、NAVIGATION_MODE_LIST、NAVIGATION_MODE_TABS）のいずれも参照していない場合、警告が生成されます。

@IntDef と @IntRange を組み合わせると、整数が指定された定数セットまたは範囲内の値になることを明示できます。

フラグによる定数の結合を有効にする

使用できる定数をユーザーがフラグ（|、&、^ など）で結合できる場合、flag 属性を使用したアノテーションを定義して、パラメータまたは戻り値が有効なパターンを参照しているかどうかをチェックできます。

以下の例では、有効な DISPLAY_ 定数のリストを使用した DisplayOptions アノテーションを作成しています。

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 {}

...

アノテーション フラグを使用したコードをビルドすると、修飾パラメータまたは戻り値が有効なパターンを参照していない場合、警告が生成されます。

Keep アノテーション

@Keep アノテーションを使用すると、ビルド時にコードが圧縮されても、アノテーション付きのクラスまたはメソッドが削除されないことを保証できます。通常、このアノテーションはリフレクションを介してアクセスされるメソッドとクラスに付けられ、コンパイラがコードを未使用と判断するのを防ぎます。

注意: @Keep アノテーションを付けたクラスとメソッドは、アプリのロジック内で参照されていなくても、常にアプリの APK に組み込まれます。

アプリのサイズを小さくするには、アプリ内の個々の @Keep アノテーションを保持する必要があるかどうかを検討します。リフレクションを使用してアノテーション付きのクラスまたはメソッドにアクセスする場合は、ProGuard ルールで -if 条件を使用し、リフレクション呼び出しを行うクラスを指定します。

コードを圧縮し、削除すべきでないコードを指定する方法については、アプリの圧縮、難読化、最適化をご覧ください。

コード可視性アノテーション

メソッド、クラス、フィールド、パッケージなど、コードの特定の部分の可視性を示すには、次のアノテーションを使用します。

コードをテスト用に表示する

@VisibleForTesting アノテーションは、コードをテストしやすくするために、アノテーション付きのメソッドの可視性を通常必要なレベルより高めていることを示します。このアノテーションにはオプションの otherwise 引数があり、テスト用にメソッドを表示する必要がない場合の可視性を指定できます。lint は、otherwise 引数を使用して、意図された可視性を適用します。

次の例では、myMethod() は通常 private ですが、テストでは package-private です。VisibleForTesting.PRIVATE が指定されていることにより、このメソッドが private アクセスで許可されているコンテキストの外部（別のコンパイル単位など）から呼び出されると、lint はメッセージを表示します。

Kotlin

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

Java

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

メソッドがテストのためだけに存在することを示すために、@VisibleForTesting(otherwise = VisibleForTesting.NONE) を指定することもできます。この形式は @RestrictTo(TESTS) を使用する場合と同じです。これらは両方とも同じ lint チェックを実行します。

API を制限する

@RestrictTo アノテーションは、アノテーション付き API（パッケージ、クラス、またはメソッド）へのアクセスが以下のように制限されていることを示します。

サブクラス

アノテーション形式 @RestrictTo(RestrictTo.Scope.SUBCLASSES) は、API アクセスをサブクラスのみに制限します。

この場合、この API にアクセスできるのは、アノテーション付きクラスを拡張するクラスだけです。Java の protected 修飾子は、同じパッケージ内の無関係なクラスからのアクセスを許可するので、制限が不十分です。また、将来の柔軟性のためにメソッドを public のままにしておきたいが（一度 protected にしてオーバーライドしたメソッドは二度と public にできないため）、本来そのクラスはクラス内部またはサブクラスのみでの使用を意図していることを示唆したい場合にも使用できます。

ライブラリ

アノテーション形式 @RestrictTo(RestrictTo.Scope.LIBRARY_GROUP_PREFIX) は、API アクセスを自分のライブラリのみに制限します。

この場合、アノテーション付き API にアクセスできるのは、自分のライブラリ コードだけです。これにより、必要に応じてパッケージ階層別にコードを分類できるだけでなく、関連ライブラリのグループ間でコードを共有することもできます。このオプションは、外部使用を目的としない実装コードを多数含む Jetpack ライブラリではそのまま利用できますが、さまざまな補助 Jetpack ライブラリ間でコードを共有するには public であることが必要です。

テスト

アノテーション形式 @RestrictTo(RestrictTo.Scope.TESTS) を使用すると、他のデベロッパーが自分のテスト API にアクセスすることを防止できます。

この場合、アノテーション付き API にアクセスできるのは、テストコードだけです。これにより、テストのみを目的とする開発用 API を他のデベロッパーが使用するのを防ぐことができます。