lint などのコード インスペクション ツールは問題の検出とコードの改善に役立ちますが、インスペクション ツールが推論できる範囲は限られています。たとえば、文字列、グラフィック、カラーなどのリソースタイプを識別するための Android リソース ID はすべて int
であるため、カラーリソースを指定すべきところで文字列リソースを指定していても、インスペクション ツールは問題を認識しません。つまり、コード インスペクション ツールを使用しても、アプリが適切にレンダリングできなかったり、実行に失敗したりする可能性があります。
アノテーションを使用して、lint などのコード インスペクション ツールにヒントを提供すると、見落としやすいコードの問題の検出に役立ちます。アノテーションはメタデータタグとして追加されます。これを変数、パラメータ、戻り値に付加することで、メソッドの戻り値、渡されたパラメータ、ローカル変数、フィールドを検査できます。コード インスペクション ツールでアノテーションを使用すると、null ポインタ例外やリソースタイプの競合などの問題を検出できます。
Android は、アノテーション サポート ライブラリを通じて、さまざまなアノテーションをサポートしています。このライブラリにアクセスするには、android.support.annotation
パッケージを使用します。
注: モジュールがアノテーション プロセッサに依存している場合、その依存関係を追加するには「annotationProcessor」依存関係構成を使用する必要があります。詳細については、アノテーション プロセッサの依存関係コ構成の使用をご覧ください。
プロジェクトにアノテーションを追加する
プロジェクトでアノテーションを有効にするには、ライブラリまたはアプリに support-annotations
依存関係を追加します。そうすることで、追加したすべてのアノテーションが、コード インスペクションまたは lint
タスクを実行したときにチェックされるようになります。
Support Annotations ライブラリ依存関係を追加する
Support Annotations ライブラリは、Google の Maven リポジトリで公開されています。プロジェクトに Support Annotations ライブラリを追加するには、build.gradle
ファイルの dependencies
ブロックに次の行を挿入します。
dependencies { implementation 'com.android.support:support-annotations:28.0.0' }次に、ツールバーまたは表示された同期通知で、[Sync Now] をクリックします。
独自のライブラリ モジュールでアノテーションを使用する場合、アノテーションは XML 形式の Android Archive(AAR)アーティファクトの一部として、annotations.zip
ファイルに含まれます。support-annotations
依存関係を追加しても、ライブラリのダウンストリーム ユーザーに対して依存関係は適用されません。
注: appcompat
ライブラリを使用している場合は、support-annotations
依存関係を追加する必要はありません。appcompat
ライブラリはすでにアノテーション ライブラリに依存しているため、アノテーションにアクセスできます。
サポート リポジトリに含まれているアノテーションの一覧については、Support Annotations ライブラリのリファレンスをご覧ください。また、オートコンプリート機能を使用して、import android.support.annotation.
ステートメントで使用可能なオプションを表示することもできます。
コード インスペクションを実行する
Android Studio で、アノテーションの検証と自動 lint チェックを含むコード インスペクションを開始するには、メニューバーから [Analyze] > [Inspect Code] を選択します。Android Studio は、競合メッセージを表示して、コードとアノテーションが競合する潜在的な問題があることを警告し、有効な解決策を提案します。
コマンドラインから lint
タスクを実行して、アノテーションを適用することもできます。lint
タスクは、継続的インテグレーション サーバーの問題の報告に役立つ場合がありますが、null 可能性アノテーションは適用しない(Android Studio のみが適用する)ことにご注意ください。lint インスペクションの有効化と実行の詳細については、lint チェックでコードを改善するをご覧ください。
アノテーションが競合すると警告が生成されますが、警告が生成されてもアプリのコンパイルは可能です。
null 可能性アノテーション
特定の変数、パラメータ、戻り値の null 可能性をチェックするには、@Nullable
アノテーションと @NonNull
アノテーションを追加します。@Nullable
アノテーションは null 値が許容される変数、パラメータ、戻り値を示し、@NonNull
アノテーションは null 値が許容されない変数、パラメータ、戻り値を示します。
たとえば、null 値を含むローカル変数がパラメータとしてメソッドに渡された場合、そのパラメータに @NonNull
アノテーションが付いていると、コードをビルドしたときに非 null 競合を示す警告が生成されます。一方、@Nullable
としてマークされたメソッドの結果を、あらかじめ null かどうかをチェックせずに参照しようとすると、null 可能性警告が生成されます。メソッドを使用するたびに明示的に null チェックを実施する必要がある場合に限り、メソッドの戻り値に @Nullable
を使用してください。
以下の例では、@NonNull
アノテーションを context
および attrs
パラメータに付けて、渡されたパラメータ値が null でないことを確認しています。また、onCreateView()
メソッド自身の戻り値が null でないことも確認しています。なお、Kotlin では、@NonNull
アノテーションを使用する必要はありません。これは、null 値が許容されない型を指定すると、生成されたバイトコードにアノテーションが自動的に追加されるためです。
Kotlin
import android.support.annotation.NonNull ... /** Add support for inflating the <fragment> tag. **/ fun onCreateView( name: String?, context: Context, attrs: AttributeSet ): View? { ... } ...
Java
import android.support.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 では、ドローアブル リソースや文字列リソースなどのリソースへの参照は整数として渡されるため、リソースタイプの検証が効果的です。パラメータがドローアブルなどの特定の型のリソースを参照すると想定しているコードには、想定される参照型である 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
など、他のリソースタイプ用のアノテーションも、同じアノテーション形式で追加して、コード インスペクションの際に実行できます。パラメータが複数のリソースタイプに対応している場合は、1 つのパラメータにこれらのアノテーションを複数指定できます。アノテーション付きのパラメータが、どのタイプの R
リソースにも対応できることを示すには、@AnyRes
を使用します。
@ColorRes
を使用して、あるパラメータをカラーリソースとして指定することもできますが、カラー整数(RRGGBB
形式または AARRGGBB
形式)はカラーリソースとして認識されません。パラメータがカラー整数でなければならないことを示すには、@ColorInt
アノテーションを使用します。カラー整数ではなく、android.R.color.black
などのカラーリソース ID をアノテーション付きメソッドに渡すコードは、ビルドツールにより不適切なコードと判断され、警告が生成されます。
スレッド アノテーション
スレッド アノテーションは、メソッドが特定のタイプのスレッドから呼び出されているかどうかをチェックします。以下のスレッド アノテーションがサポートされています。
注: ビルドツールは @MainThread
アノテーションと @UiThread
アノテーションを交換可能なものとして扱うので、@MainThread
メソッドから @UiThread
メソッドを呼び出すことも、その逆も可能です。ただし、異なるスレッドに複数のビューがあるシステムアプリの場合は、UI スレッドがメインスレッドと異なる可能性があります。したがって、アプリのビュー階層に関連付けられているメソッドには @UiThread
アノテーションを付け、アプリのライフサイクルに関連付けられているメソッドにのみ @MainThread
アノテーションを付ける必要があります。
1 つのクラスに含まれるすべてのメソッドが同じスレッド要件を共有している場合は、そのクラスに単一のスレッド アノテーションを追加することで、クラス内のすべてのメソッドが同じタイプのスレッドから呼び出されるかどうかを検証できます。
一般的に、スレッド アノテーションは、AsyncTask クラスにおけるメソッドのオーバーライドの検証に使用されます。このクラスはバックグラウンド オペレーションを実行し、UI スレッド上でのみ結果を公開するからです。
値制約アノテーション
渡されたパラメータの値を検証するには、@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
@SdkConstant(SdkConstantType.ACTIVITY_INTENT_ACTION) @RequiresPermission(Manifest.permission.CALL_PHONE) const val ACTION_CALL = "android.intent.action.CALL"
Java
@SdkConstant(SdkConstantType.ACTIVITY_INTENT_ACTION) @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 アノテーション
整数セットと文字列セットの列挙型アノテーションを作成して他の型のコード参照を検証するには、@IntDef
アノテーションと @StringDef
アノテーションを使用します。Typedef アノテーションは、特定のパラメータ、戻り値、またはフィールドが特定の定数のセットを参照することを保証します。さらに、コード補完により、使用できる定数が自動的に提示されるようになります。
Typedef アノテーションは、@interface
を使用して新しい列挙型のアノテーション タイプを宣言します。@IntDef
アノテーションと @StringDef
アノテーションは、@Retention
と一緒に使用して、新しいアノテーションを付けることができます。これらのアノテーションは列挙型を定義するために必要です。@Retention(RetentionPolicy.SOURCE)
アノテーションは、列挙型アノテーションのデータを .class
ファイルに保存しないようコンパイラに通知します。
以下の例は、メソッド パラメータとして渡される値が、定義済みの定数のいずれか 1 つを参照することを保証するアノテーションを作成する方法を示しています。
Kotlin
import android.support.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 android.support.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 android.support.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 android.support.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.GROUP_ID)
は、API アクセスを自分のライブラリのみに制限します。
この場合、アノテーション付き API にアクセスできるのは、自分のライブラリ コードだけです。これにより、必要に応じてパッケージ階層別にコードを分類できるだけでなく、関連ライブラリのグループ間でコードを共有することもできます。このオプションは、外部使用を目的としない実装コードを多数含むサポート ライブラリではそのまま利用できますが、さまざまな補助サポート ライブラリ間でコードを共有するには public
であることが必要です。
注: Android サポート ライブラリのクラスとパッケージには、現在 @RestrictTo(GROUP_ID)
アノテーションが付けられています。そのため、誤ってこれらの実装クラスを使用すると、lint は使用しないように警告します。
テスト
アノテーション形式 @RestrictTo(RestrictTo.Scope.TESTS)
を使用すると、他のデベロッパーが自分のテスト API にアクセスすることを防止できます。
この場合、アノテーション付き API にアクセスできるのは、テストコードだけです。これにより、テストのみを目的とする開発用 API を他のデベロッパーが使用するのを防ぐことができます。