2012-08-14 10 views
8

Hay algunas partes de la estructura que no están del todo claro para mí todavía. Soy muy conocido con el flujo de un evento de entrada (Kernel -> Eventhub -> InputReader -> InputDispatcher -> ...).Manipulación Android Key (marco)

Situación

(Requisitos: Mango. Teclas de entrada sin cambiar el marco Android) que quiero para controlar los eventos clave procedentes de un dispositivo (teclado/gamepad/controlador/...) pero hay son algunos requisitos Por un lado, no quiero cambiar el marco de Android. Esto significa, no quiero que se extiende a la WindowManagerPolicy y sus funciones como interceptKeyBeforeDispatching donde se está manejando la tecla de inicio. Esto daría como resultado el envío del evento clave a la capa de aplicación, lo que está bien. La desventaja es que tengo otro requisito difícil aquí. Ejemplo: Cuando estoy jugando Angry Birds y presiono mi GoToAlpha-botón en el dispositivo de entrada conectado, el alfa-aplicación tiene que empezar. Angry Birds no tiene ni idea de qué botón es GoToAlpha, no lo manejará/reconocerá y, por ejemplo, no se emitirá ningún intento para iniciar mi aplicación Alpha.

Pregunta

¿Hay una manera de manejar mi (personalizado) evento clave después de que se envió, a sabiendas de que la aplicación en primer plano no puede manejar la llave?

Mi (no) soluciones

  • Crear un servicio que se encargará de los eventos clave. Esto no es posible porque una aplicación como Angry Birds no se vinculará a mi servicio y el evento clave no será capturado dentro de mi servicio. Si me equivoco, proporcione más información :).

  • Crear una biblioteca externa, donde dejo que las actividades de mi aplicación a heredar de mi propia ActivityBase. Todos los eventos clave y su comportamiento predeterminado se pueden manejar aquí. A la baja, las aplicaciones existentes no admitirán mis eventos de clave personalizados porque no usan la biblioteca.

  • ampliar el marco estaría en mis ojos la solución más limpia, sino que dará lugar a no cumplir con mi obligación.

Cualquier ayuda o información útil sería apreciada

extra

Si la primera pregunta podría ser resuelto en una forma u otra .. Quiero personalizar mi Intent detrás del botón GoToAlpha. Esto significa .. Por por defecto se iniciará el Alfa-aplicación, pero después de que el usuario ha había modificado, la beta-aplicación se inició a partir de ahora .. Cualquier pensamientos?

Gracias

+0

¿No sería raro si es posible capturar eventos clave de otras aplicaciones? Supongo que esto sería un riesgo de seguridad – Boy

+0

Verdadero. Una vez que el evento clave deja el marco, se dirige a una sola aplicación y se maneja allí. Si no, se devuelve al marco. Esto significaría que no hay una solución que satisfaga mis dos requisitos. – DroidBender

+0

En mi opinión, probablemente no haya forma, solo por el problema de seguridad: manejar eventos clave mientras su aplicación no tiene foco. Tal vez la única forma sería si implementa un teclado Android (no tengo conocimiento de eso)? Esto debería ser capaz de manejar eventos clave (y los usuarios también apuntan a este riesgo de seguridad cuando seleccionas un teclado de terceros) – Boy

Respuesta

3

Gracias por el comentario Victor.

Usar el InputMethodService no me proporcionará suficiente libertad y funcionalidad para manejar mis problemas.

Mi Solución/Compromiso

Dentro del marco de Android, hay una PhoneWindowManager que es responsable de manejar InputEvents. El WindowManagerService que inició el SystemServer, es propietario de este administrador y crea una instancia.

Al crear mi propio WindowManager personalizado y dejarlo heredar de PhoneWindowManager de Android, no pierdo ninguna funcionalidad predeterminada y esto me permite agregar mi propia implementación dentro de esta clase. Esto resulta en agregar un nuevo archivo al marco y cambiar solo una línea dentro de Android Framework: WindowManagerService no creará un PhoneWindowManager, pero creará un CustomPhoneWindowManager (extiende PhoneWindowManager).

Si alguien ve una solución mejor o tiene alguna idea específica sobre mi compromiso, no dude en comentar. :)

+0

Una idea más. Escuché sobre eso en alguna parte, pero no recuerdo dónde y cuáles fueron los resultados. Puede intentar crear una ventana transparente que se ubicará en la parte superior de todas las ventanas, por lo que recibirá todos los clics/tecleos del teclado. Y ahora, deberá enviarlo a la aplicación que está justo detrás del suyo. De esta forma, puede cambiar su problema de "recibir todas las entradas" a enviar clics a otra aplicación. –

+1

Ese es un enfoque bastante peligroso Victor, ¿no chocaría eso con algunos estándares de seguridad :)? Otro problema es que hay 'InputEvents' (similar a KEYCODE_HOME) que están atrapados dentro del Framework y no se envían a la capa de aplicación. Estos eventos ni siquiera llegarían a la ventana invisible.¡Gracias por su apoyo! – DroidBender

+0

Oh ... sí ... es peligroso :) Sin embargo, creo que el valor del negocio supera las preocupaciones de seguridad el 80% del tiempo. Tengo una visión muy limitada en todo el InputMethodService (solo sé sobre su existencia). –

0

que duda de que es posible con la API pública (muchacho y Martijn señaló los problemas de seguridad).

La mayoría, como sus mejores apuestas (si no desea personalizar Android) sería

a) Trate de usar InputMethodService (http://developer.android.com/reference/android/inputmethodservice/InputMethodService .html)

No ofrece el tipo de control que desea, pero podría ser suficiente para algunas necesidades.

b) Intente pasar por la pila completa (desde Kernel a Application) y encuentre algunas vulnerabilidades para usar.

Esto definitivamente llevará mucho tiempo y no garantiza traer frutas.