Manteniendo un poco de control a pesar de que Android 6.0 Marshmallow sigue el concepto de Open Source, Google ha publicado las guías de como los manufactureros pueden tener las funciones netas que trae Marshmallow como novedad en la plataforma de Android.
Para que Google considere un equipo hábil para tener a Android 6.0 Marshmallow, el hardware del equipo tiene que tener ciertas configuraciones para que pueda ser técnicamente viable tener un upgrade y es muy seguro que esto Google se asegurará mediante el despliegue de Google Play Service y las guías son las siguientes:
Encripción del almacenamiento
Para implementaciones de soporte a dispositivos con encriptación de disco completo y con Advanced Encryption Standard (AES) para rendimiento arriba de los 50MB/seg, la encriptación del disco completo debe ser activada por defecto en el momento en que el usuario active el equipo por primera vez.
Doze Mode
Las aplicaciones que están en “stand-by” o Doze Mode, tienen que estar visibles para el usuario TODO el tiempo y aunque el manufacturero puede modificar los algoritmos de mantenimiento y “wakeup” de aplicaciones, NO pueden desviarse de las guías del Android Open Source Project.
Sensor de Huellas Dactilares
El manufacturero tiene y SERA responsable de crear APIs para terceros para crear funciones de seguridad con el sensor de huellas dactilares y el hardware TIENE que incluir el sensor físicamente y la siguiente es una lista de los requerimientos de las capacidades nativas del sensor de huellas dactilares:
- Debe tener una función llamando a android.hardware.fingerprint.
- No habrá excepciones de que el manufacturero debe seguir el API al pie de la letra descrito en las documentaciones del SDK de Android.
- Margen de error de escaneo no puede superar el 0.002%.
- El equipo no debe aceptar más del 10% de intentos fallidos y la pantalla no debe tardar más de un segundo en reaccionar a desbloquearse cuando pase al menos 1 segundo desde que el usuario retira su dedo.
- Debe haber un periodo de espera de 30 segundos luego de 5 intentos fallidos.
- Debe haber una implementación Trusted Execution Environment (TEE) para un seguro a nivel de hardware.
- Los datos de huellas dactilares deben cumplir y no salirse de los parámetros documentados del Trusted Execution Environment (TEE), lo que significa que las huellas estarán encriptadas y no podrá ser leídas externamente.
- La registración inicial de la huella dactilar no puede comenzar a menos que el usuario se registre como el principal en el equipo bajo Trusted Execution Environment (TEE).
- Aplicaciones de tercero NO pueden distinguir entre diferentes huellas en un mismo equipo.
- El equipo tiene que cumplir y activar el DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT cuando aplique.
- Las actualizaciones futuras de Android deben incluir completa lectura de datos de huellas de versiones anteriores y no deben pedirle al usuario de tener que volverse a registrar.
- Android Fingerprint tiene su icono y los manufactureros tienen que usar el que se provee en el Android Open Source Project.
Audio Profesional
Algo que debo admitir como usuario de Android, Android es la plataforma con un gran avance en el soporte directo de Audio, más bien para los que hagan funciones como procesamiento de señales y frecuencias para la creación de sonido y música pero tienen un viaje largo si lo comparamos con iOS, pero esto no significa que Google se va a quedar de brazos cruzados y si, Google implemento guías de compatibilidad para los que quieran usar las capacidades de procesamiento de Audio y las mismas son las siguientes:
- featurehardware.audio.low_latency debe ser invocado para realizar reportes.
- El ciclo de latencia de audio TIENE que ser 20 milisegundos o menos y hasta 10 milisegundos o menos para una salida.
- Lo anterior aplica también para audífonos con conectores de 3.5mm.
- El puerto USB del equipo tiene que soportar Host Mode y Peripheral Mode.
- El USB Host Mode tiene que implementar el USB Audio Class.
- Mínimo de output para HDMI tiene que ser full-estéreo con 8 canales a profundidad de 20 a 24 bit y a frecuencia de 192KHz sin pérdida de bit o que haya necesidad de re muestreo.
- Soporte de featuresoftware.midi es obligatorio.
- Si hay 4 jacks de audífonos de 3.5mm, las reglas del Wired Audio Headset Specification (v1.1) aplican.
Permisos
Uno de las funciones estrella para mí lo es que ahora los permisos serán específicos a nivel de usuarios para controlar mejor el comportamiento de las aplicaciones y para lograr esto, Google necesita que los manufactureros cumplan con:
- Debe haber una interface para el usuario donde se pueda controlar el tiempo de corrida de una aplicación y se pueda solicitar modificaciones también.
- Solo una implementación por equipo.
- NO DEBE conceder los permisos de ejecución a aplicaciones preinstaladas menos que el consentimiento del usuario puede sea obtenido antes de la activación inicial de la aplicación o los permisos de ejecución se asocia con un patrón de intención para que la aplicación preinstalada se establece como el controlador predeterminado.
No está nada mal estos controles para asegurar la experiencia que Google quiere brindar con esta nueva versión de Android 6.0 Marshmallow y demás está decir y como ya se mencionó, es probable que Google fiscalice a los manufactureros a través del mismo Google Play Service, que es prácticamente el corazón de la experiencia de Android, a menos claro está que uses un fork o un derivado altamente diseñado.
[button color=”red” size=”medium” link=”https://static.googleusercontent.com/media/source.android.com/en//compatibility/android-cdd.pdf” icon=”” target=”false”]Documentación de Google (PDF)[/button]
