今日の驚くべき発見：Android上のJNIを使用すると、Javaのルールに従って、想定外のオブジェクトフィールドにアクセスできます。
アクセス制限を回避するこの機能はどこかに文書化されていますか？これは公式のJNIの動作ですか、それともJNIのAndroidフレーバーに固有のものですか？これは未定義の動作ですか？OOP警察は今すぐ私のために来ますか？
未公開のオブジェクトフィールドに依存することは本質的に危険であり、いつでも壊れることがあることを理解しています。それはここでの問題ではありません。
更新：API28をターゲットとするアプリケーションにはこの機能がなくなったようです。
この問題は、2006年に公開された記事、またはむしろ提案で説明され、対処されています。
JavsはSecurityManagerクラスを定義しますが、すべてのJNI呼び出しをセキュリティ違反と見なすため、 「ドライバー/サービスをインストールするだけで管理者に昇格できるのはなぜですか？」などの質問は、セキュリティ違反の観点からは問題になりません。。
しかし、Androidでは、状況はさらに明確になります。公式ドキュメントでは、このクラスについて次の序文で説明しています。
レガシーセキュリティコード。使ってはいけません。
セキュリティマネージャは、信頼できないコードを実行するための安全な環境を提供していません。信頼できないコードをDalvikVM内で安全に分離することはできません。
（強調は彼らのものです）
次のバージョンのAndroidでJNIからのネイティブフィールドとメソッドへのアクセスが失われないことを保証するより強力な単語を探している場合は、幸運を祈ります。
一方、Androidの将来のバージョンでは、一部のプライベートフィールドとメソッドの名前または署名が変更される可能性が高くなります。さらに、ファイルが残るように実装を変更できますが、別の方法で使用する必要があります。
最後に、これらの考慮事項はすべて、プライベートメソッドまたはパッケージプライベートメソッドだけでなく、公式ドキュメントに含まれていないパブリックメソッドおよびフィールドにも適用されることに注意してください。
今日の驚くべき発見：Android上のJNIを使用すると、Javaのルールに従って、想定外のオブジェクトフィールドにアクセスできます。
略語JNIは、この質問への動的に生成されたリンクを除いて、リンクした質問と回答のどこにも表示されません。
これはどこかに文書化されていますか？
Java開発に関するまともな本は、、などをカバーする必要がありpublicますprivate。
これは公式のJNI動作ですか、それともAndroid固有ですか？
ない。
Android固有のものはandroid、一部の、、、javaおよびjavaxパッケージにコードを追加することを困難にするコンパイル時の手順です。
これは未定義の動作ですか？
それは、代名詞「this」に結び付ける基礎となる名詞または概念によって異なります。
「これ」が「プライベートなどへのアクセス」である場合、動作は未定義ではありません。
「これ」が「Androidフレームワーク内の特定のプライベートなどにアクセスする」場合、それは未定義です。Androidには多くのバージョンがあり、フレームワーククラスには多くのバージョンがあります。それらの内部実装は同一ではありません。Android SDKを介して公開されていないものはすべて、Google、デバイスメーカー、ROMmodメンテナーなどによる変更の対象となります。