8

Actualmente estamos trabajando en un conjunto de pruebas de instrumentación que se ejecuta en nuestro servidor de compilación, pero mientras las pruebas pasan a un equipo de desarrollo usando un emulador normal de Android, las construcciones fallan en el servidor de compilación ya que solo ejecutamos un emulador sin -no-window bandera.¿Cómo enviar eventos clave a un emulador sin cabeza en una prueba de instrumentación?

La falla se produce al intentar invocar el método InstrumentationTestCase.sendKeys() para abrir el menú de opciones mediante programación. El error es:

Permiso denegado: inyectar evento clave de PID 646 uid 10026 para ventana Ventana {43d55100 pausa = false} propiedad de UID 1000

continuación, descubrimos que hay un permiso INJECT_EVENTS, pero establecerlo en el manifiesto no tuvo ningún efecto. De hecho, en el registro que vimos esta salida:

No conceder permisos para empaquetar android.permission.INJECT_EVENTS com.qype.radar (ProtectionLevel = 2 banderas = 0x6644)

¿Eso significa que este permiso es inútil?

También intentamos que la aplicación de prueba de instrumentación y la aplicación bajo prueba compartan la misma ID de usuario de Linux usando android:sharedUserId y se ejecuten en el mismo proceso (android:process - no estábamos seguros si ese era el caso), pero Todavía no hay suerte.

¿Esto significa que actualmente es imposible ejecutar instrumentaciones que contengan eventos clave en un emulador sin cabeza, o nos falta algo?

+2

'INJECT_EVENTS' es un permiso perfectamente válido, pero que solo puede ser retenido por firmware, no por aplicaciones SDK. – CommonsWare

+0

bummer. Entonces, ¿cuál es nuestra mejor apuesta? ¿Google no pensó en ejecutar pruebas en un servidor de compilación? – Matthias

+0

Acabo de reiniciar el emulador usando el indicador -wipe-data, luego la compilación pasó UNA VEZ, luego el emulador se colgó, lo reinicié nuevamente, ahora la compilación está fallando de nuevo ... todo esto es tan escamoso :-( – Matthias

Respuesta

1

Tuve un problema similar con mi prueba en el servidor de Hudson. En mi caso, el problema lo resolví por sugerencia de Android SDK: http://developer.android.com/guide/topics/testing/testing_android.html#UITestTroubleshooting

Importante era que también tenía que habilitar los permisos para la aplicación principal.

+0

hey great, ¿Cómo podríamos perder eso? Creemos que el problema es en realidad el bloqueo de teclas: impide que sendKeys() funcione correctamente. – Matthias

+3

¿Cuál fue la solución? La sección ha sido eliminada de esa página :( –

+1

Si no recuerdo mal, la solución era para deshabilitar programáticamente el bloqueo de teclas, ya que estará activo después de cada arranque de emulador/teléfono. Eche un vistazo a este fragmento: http://pastebin.com/v0deQGpT Por supuesto, querrá eliminar este código de una aplicación de producción; el bloqueador de teclas permanentemente hasta el siguiente arranque. – Matthias

17

Ejecuto el emulador sin -no-window en máquinas sin cabeza ejecutando primero una instancia de Xvnc (es decir, servidor X falso) y luego iniciando el emulador en ese DISPLAY.

Más exactamente, obtengo los plugins Jenkins Xvnc y Android Emulator para hacer esto por mí.

Por desgracia, el desbloqueo de la pantalla sigue siendo una preocupación antes de inyectar eventos de interfaz de usuario, pero esto es (hackily) resolvió mediante la ejecución automática de un comando como este (similar a this other answer you've seen):
echo "event send EV_KEY:KEY_MENU:1 EV_KEY:KEY_MENU:0" | nc -q1 localhost 5554


Editar :
he descubierto que este método es mucho más fiable:
adb shell input keyevent 82

Some info sobre el código clave 82.

+0

que suena realmente interesante, lo comprobaremos, ¡gracias! – Matthias

Cuestiones relacionadas