getCallingUid/getCallingPid return current uid y pid en Handler.handleMessage

Question

Tengo una clase que se extiende android.os.Handler. Se pasa una instancia de este controlador al constructor de un Messenger. Messenger 's IBinder de getBinder se pasa como resultado de onBind eventos en mi servicio. Los mensajes enviados a través de la carpeta desde aplicaciones remotas van al método handleMessage del controlador, sin embargo las llamadas a Binder.getCallingUid y Binder.getCallingPid dentro de handleMessage siempre devuelven el uid y pid del proceso del servicio (que definitivamente no es el mismo proceso que la aplicación remota). handleMessage es definitivamente parte de una transacción IPC, ¿no es así? Entonces, ¿dónde me he equivocado? Necesito que esto funcione para la autenticación de aplicaciones de conexión.

Gracias de antemano.

Editar

OK. Tengo la horrible sensación de que handleMessage no forma parte de la transacción IPC, porque eso sucede en hilos separados para AIDL que pone mensajes en una cola para el Messenger. ¿Hay alguna otra forma de obtener la identificación de usuario y la identificación del proceso de la persona que llama?

Answer 1

Hacer una clase personalizada Handler y anular sendMessageAtTime (este es el único método de contabilización reemplazable en la clase Handler), y luego lo usan para crear un Messenger regresaron de onBind.

En el método sendMessageAtTime, puede obtener el pid/uid de la aplicación remota que llama por getCallingPid y getCallingUid.

Pero, en IPC usando Messenger, en contraposición al uso de AIDL, getCallingPid siempre devolverá 0 porque el envío de mensajes por aplicaciones remotas es asincrónico; transacciones con IBinder.FLAG_ONEWAY. Por lo tanto, el uid es la única información disponible.

Answer 2

El código que maneja el mensaje no está involucrado en ningún IPC, en su lugar debe mirar el código que está publicando el mensaje en el controlador.

Answer 3

He encontrado lo que creo que es una buena manera de arreglar esto. Todos los mensajes que vienen a través de IPC se reconstruyen a partir de un paquete usando Message.CREATOR.createFromParcel. Así que he creado una clase Java Dynamic Proxy (código extraído directamente del docs) que detecta las llamadas a createFromParcel y agrega la identificación del proceso y la identificación del usuario como elementos adicionales en el paquete del mensaje antes de devolver el resultado. Se garantiza que el mensaje se creará dentro de una transacción, mirando la fuente de Messenger, por lo que los ID son correctos. Luego uso el reflejo para reemplazar la variable estática final Message.CREATOR con un proxy propio. A continuación, los identificadores se eliminan de los mensajes más allá de las transacciones cuando se requiere autenticación.

Hasta ahora, esto funciona exactamente como se esperaba.

Anteriormente yo estaba tratando de crear una versión alternativa de Messenger, y el uso de la reflexión para acceder IMessenger, pero aún no maneja MessengerMessage s antes de fin de transacciones. Un proxy es mucho menos trabajo y menos propenso a errores involucrados en la conversión de diferentes implementaciones de IMessenger.