¿Cómo implementa Android la supervisión en segundo plano de eventos clave?
Para realizar la supervisión del teclado, no es realista desarrollar un método de entrada desde cero. La operación general es agregar devoluciones de llamada de interfaz al mecanismo del método de entrada del sistema. Sabemos que la devolución de llamada para obtener la clave en la aplicación suele ser la interfaz que escucha onKeyDown, como se muestra a continuación:
onKeyDown booleano público (int keyCode, evento KeyEvent)
Desarrolladores can Se pueden determinar eventos específicos en función de los parámetros del método de devolución de llamada, keyCode y KeyEvent. Sin embargo, dado que el mecanismo de devolución de llamada de eventos se ejecuta en su propio entorno limitado, la devolución de llamada del evento de la aplicación actual no se puede obtener en otras aplicaciones.
Luego, echemos un vistazo detallado al mecanismo de entrega de eventos de arriba a abajo. Como se muestra en la figura siguiente, después de que el usuario hace clic, el controlador de entrada del teclado virtual o tecla física generará una interrupción y escribirá un semáforo correspondiente en /dev/input/event*. El sistema operativo Android leerá los eventos en un bucle y luego los distribuirá a WindowManagerServer. WindowManagerServer distribuye los eventos a diferentes ViewGroups y Views según la fuente, generando así diferentes OnClick, OnKeyDown, OnTouch y otros eventos.
En este momento, es natural pensar que si los piratas informáticos quieren monitorear el teclado, definitivamente agregarán eventos personalizados a la capa inferior de Linux. Aquí usamos getevent en Linux para obtener los eventos informados por el dispositivo /dev/input/eventX. Este comando también generará la información básica de todos los dispositivos de eventos. Incluye pantalla táctil, botones, inserción de auriculares y más.
Su uso básico es el siguiente:
Uso: getevent [-t] [-n] [-sswitchmask] [-S] [-v [mask]] [-d] [-p] [- i] [-l] [-q] [-c recuento] [-r] [dispositivo]
? -t: mostrar marcas de tiempo
-n: ¿no? imprimir nuevas líneas
? -s: imprimir estados de cambio para bits dados
? -S: imprimir todos los estados de cambio
-v: máscara de detalle (errs= 1, dev=2, nombre=4, info=8, vers=16, pos. events=32, props=64)
? -d: muestra el descriptor HID, si está disponible
? -p: muestra posibles eventos (errs, dev, nombre, pos. eventos)
-i: muestra toda la información del dispositivo y posibles eventos
-l: etiqueta tipos de eventos y nombres en texto plano
? -q: silencio (máscara de detalle clara)
-c: imprime el número dado de eventos y luego sale
? -r: se reciben eventos de velocidad de impresión
Después de escribir getevent, podemos ver algunas columnas de información del controlador de hardware de entrada en el dispositivo. También habrá muchas señales de comando de entrada a continuación. Normalmente, estos semáforos se vacían en la pantalla. , como se muestra a continuación:
No podemos comprender directamente la representación de estos semáforos. Ingrese getevent –l para agregar etiquetas y podremos ver algunas etiquetas agregadas, como se muestra a continuación:
De hecho. , estas etiquetas se han definido en su archivo de encabezado input.h, donde el tipo se define de la siguiente manera:
/*
* Tipos de eventos
*/
? #definir EV_SYN ?0x00
? #definir EV_KEY ?0x01
? #definir EV_ABS ? 0x03
? #definir EV_MSC ?0x04
? #definir EV_SW ? EV_SND ?0x12
? #definir EV_REP ?0x14
? #definir EV_FF ? #definir EV_FF_STATUS
? 0x17
? #define EV_MAX ?0x1f
? #define EV_CNT (EV_MAX 1)
En términos generales, los más utilizados son EV_KEY, EV_REL, EV_ABS. , EV_SYN corresponde a teclas del teclado, coordenadas relativas, coordenadas absolutas y eventos de sincronización, respectivamente. EV_SYN indica que se ha completado un conjunto completo de eventos y debe procesarse. El código de EV_SYN define el tipo de distribución de eventos.