android - Android システムによるバインダー トークンの使用

Question

このブログ投稿で、Android システム内での Binder トークンの使用について読んでいます。トークンを使用して同じアプリケーションからの後続のリクエストを識別するウェイクロックに関連する例を見ました。

Android システムでUIDは、アプリケーションからの後続のリクエストを追跡するのに、呼び出し元のアプリケーションの が十分でないのはなぜですか? アプリケーションを識別するという点で、UID ができないことをバインダー トークンが満たす必要はありますか?

Answer 1

Binder トークンは、 のようにアプリケーションを識別しませんuid。トークンは機能またはチケットであり、所有が重要であることを意味します。つまり、バインダー トークンを使用すると、トークンを所有しているかどうかだけが重要であり、あなたが誰であるかは関係ありません。この最後の部分が重要です。Android フレームワークには、セキュリティ上の理由から区別する必要がある多くのオブジェクトがありますが、それらはすべて同じ(プロセス空間内のオブジェクトなど) を持っているか、真のオブジェクトを識別していません。件名 (例: Binder RPC のローカル側で実行されるコード)。uidsystem_serveruid

とのこの違いuidにより、簡単には実現できない、または では実現できない機能が可能になりますuid。良い例は、参照したブログ投稿にあります。

アプリケーションはInputMethodManager、メソッドを呼び出してソフト キーボードを非表示にするように要求できますhideSoftInputFromWindow(IBinder windowToken, int flags) が、要求の一部としてウィンドウ トークンを提供する必要があります。トークンが、現在入力を受け付けているウィンドウに属するウィンドウ トークンと一致しない場合、InputMethodManagerは要求を拒否します。これにより、悪意のあるアプリケーションが、別のアプリケーションによって開かれたソフト キーボードを強制的に閉じることができなくなります。

ここでトークンを使用する主な理由は、ウィンドウ オブジェクトがuid. 確かに、それは があるプロセスの一部ですが、それuidが何であれ、ソフト キーボードを非表示にしようとしているアプリケーションuidの ではありません。uidしたがって、リクエスタが現在入力を受け付けているウィンドウを所有していることを確認する唯一の方法はWindowManager、ウィンドウが最初に作成されたときに与えられたトークンをアプリケーションに提供させることです。