android9.0後hide法の反射制限の解析

前の同僚と食事をしていたときに知ったニュースはandroid 9です.0@hideメソッドの使用を制限し始め、反射でもhideメソッドは使用できません.私をびっくりさせて汗をかいて、appの中で各種の反射を使うのは日常茶飯事で、特にframeworkによく知っている場合です.
会社に帰ってandroidの公式ドキュメントを見てください.https://developer.android.com/about/versions/pie/restrictions-non-sdk-interfaces
問題はそれほど深刻ではないことが分かった.そのメカニズムはホワイトリストやブラックリストのフィルタリング方法を使うことで、ホワイトリストは携帯電話メーカーに役立ち、appを書くのに役に立たず、ブラックリストに注目するだけだ.実際には4つのリストがあります.

ホワイトリスト:SDK

グレーリスト:まだアクセス可能な非SDK関数/フィールド.

ダークグレーリスト:

は、ターゲットSDKがAPIレベル28より低いアプリケーションに対して、ダークグレーリストインターフェースを使用することを可能にする.

ターゲットSDKに対してAPI 28以上のアプリケーション:ブラックリストと同じ動作

ブラックリスト:ターゲットSDKに関係なく制限されます.プラットフォームはインタフェースが存在しないように表現されます.たとえば、アプリケーションがインタフェースを使用しようとすると、プラットフォームはNoSuchMethodError/NoSuchFieldExceptionを引き起こし、アプリケーションが特定のカテゴリのフィールド/関数リストを理解したいとしても、プラットフォームにはインタフェースは含まれません.

無節操な国内appプログラマーにとって、現在は本当にブラックリストに注目し、api levelを28に書くのは現実的ではなく、数年後にグレーリストの問題に直面する可能性がある.
ブラックリストはソースコードのplatform/prebuilts/runtime/appcompat/hiddenapi-dark-greylist.txt
ソースコードがなくて、直接ネットを見ることができます:
https://android.googlesource.com/platform/prebuilts/runtime/+/master/appcompat/hiddenapi-blacklist.txt
ブラックリストの核心思想はいくつかのシステム情報と安全なインタフェースに対して制限を行うことであり、他の面、例えばカスタムViewが使用する反射はブラックリストの問題を心配する必要はない.
良心的なappプログラマーとしてブラックリストを心配する必要はありません.