Android 8.0 Oreo: límites al segundo plano

Android 8.0 Oreo es la versión que le puso correa al trabajo en segundo plano. Las apps con target API 26 ya no pueden ejecutar servicios libremente desde el segundo plano ni escuchar la mayoría de los broadcasts implícitos desde su manifest, y cada notificación tiene que pertenecer a un canal que controla el usuario. Por debajo, Project Treble separó el framework de Android del código del fabricante, para que un teléfono pudiera actualizarse sin que el fabricante del chip tuviera que rehacer su trabajo primero.

De un vistazo

La primera developer preview salió el 21 de marzo de 2017, para Nexus 5X, Nexus 6P, Nexus Player, Pixel, Pixel XL y Pixel C; las cuatro developer previews son las partes que siguen a esta vista general. Google congeló la API el 8 de junio de 2017 y ese mismo día abrió Play a las apps con target API 26. El 21 de agosto publicó el código en AOSP, actualizó los dispositivos de Android Beta y anunció que las versiones para Pixel, Nexus 5X, Nexus 6P, Pixel C y Nexus Player estaban en pruebas con los operadores. Las primeras etiquetas públicas de AOSP para esos dispositivos llevan parches de seguridad de agosto de 2017.

El nombre se anunció ese mismo día, durante el eclipse solar, con galletas Oreo temáticas de Android que Nabisco hizo para el evento de lanzamiento.

Qué trajo

• Límites en segundo plano. Es el cambio que define la versión; está detallado más abajo, en “Qué cambió para tu app”.
• Canales de notificación. Cada notificación pertenece a un canal que la app crea con NotificationChannel. El usuario elige sonido, vibración e importancia por canal; Ajustes los llama “categories”. Una vez creado el canal, la app ya no puede cambiar su comportamiento, solo su nombre y su descripción.
• Más controles de notificación. Puntos de notificación en los íconos del launcher, posponer notificaciones, setTimeoutAfter() para las que se cancelan solas, setColorized() para tareas en curso como la navegación o una llamada, y un MessagingStyle que muestra más contenido contraído.
• Picture-in-picture en teléfonos. Hasta 8.0 era una función de Android TV. Una actividad se suma con android:supportsPictureInPicture y entra con enterPictureInPictureMode(PictureInPictureParams). En PiP queda pausada pero visible, así que la reproducción debe detenerse en onStop(), no en onPause().
• Framework de autocompletado. Los gestores de contraseñas reciben una API del sistema para llenar formularios de acceso y de pago en cualquier app. Las vistas de entrada estándar funcionan con él sin código; el usuario elige el servicio en Ajustes.
• Íconos adaptables. Un ícono tiene dos capas, primer plano y fondo, de 108×108 dp cada una. La máscara del fabricante recorta la forma, y solo los 66×66 dp centrales se ven siempre.
• Fuentes como recursos. Las fuentes van en res/font/ y se usan en los layouts por nombre. Las fuentes descargables permiten compartir una fuente desde un proveedor en lugar de incluirla en el APK; el mismo mecanismo entrega emoji actualizados. La Support Library 26 lleva ambas cosas a versiones anteriores.
• Otros añadidos. TextView con tamaño automático, accesos directos y widgets anclados (requestPinShortcut()), color de gama amplia por actividad, Wi-Fi Aware, soporte de LDAC y Bluetooth 5, TextClassifier para la selección inteligente de texto, java.time, java.nio.file y java.lang.invoke de OpenJDK, y cuotas de caché por app (getCacheQuotaBytes()). WebView suma APIs de Safe Browsing, de versión, de terminación del renderer y de importancia del renderer; una actividad puede pasar de una pantalla a otra, y la app puede elegir en cuál se abre; el emparejamiento de dispositivos complementarios permite personalizar el diálogo de emparejamiento por Bluetooth, BLE y Wi-Fi.
• Los usuarios vieron una app de Ajustes reorganizada, un set de emoji rediseñado con más de 60 emoji nuevos de Unicode 10 (las caras redondas reemplazaron a los emoji “blob” de Google) y un arranque que Google describió como hasta el doble de rápido en el Pixel.

Seguridad y privacidad

• Project Treble. Una interfaz estable con el fabricante se ubica ahora entre el framework de Android y el código propio del dispositivo, escrito sobre todo por los fabricantes de chips. La valida la Vendor Test Suite, como CTS valida la API de las apps. Google dijo que llegaría a todo dispositivo nuevo lanzado con Android 8.0; Ars Technica informó que era opcional para los dispositivos actualizados.
• Instalar apps desconocidas. Desaparece el interruptor global “Unknown sources”. Ahora el usuario autoriza por separado cada app que instala, en “Install unknown apps”. Google lo justificó por el “hostile downloader”: una app que engaña al usuario para instalar malware disfrazado de actualización.
• Sandbox. Un filtro seccomp se aplica a todas las apps y limita las llamadas al sistema a las que expone bionic. WebView renderiza por defecto en un proceso separado y aislado. Treble llevó muchos componentes de hardware a sandboxes más estrictas.
• Kernel y espacio de usuario. Hardened usercopy, emulación de PAN, read-only after init y KASLR en el kernel; integridad del flujo de control (CFI) en el stack multimedia. Las superposiciones de apps ya no pueden tapar ventanas críticas del sistema.
• Arranque y claves. Llegó Android Verified Boot (AVB), con protección contra rollback en el código del bootloader. La atestación de claves pasó a ser obligatoria en todo dispositivo que sale con 8.0, y la credencial de la pantalla de bloqueo puede verificarse en hardware resistente a manipulaciones.
• Identificadores. ANDROID_ID ahora es distinto para cada clave de firma, usuario y dispositivo. Build.SERIAL queda obsoleto en favor de Build.getSerial(), que exige READ_PHONE_STATE. net.hostname está vacío y el cliente DHCP ya no envía un nombre de host.
• TLS. SSLv3 desaparece, y HttpsURLConnection ya no retrocede a una versión anterior de TLS cuando un servidor negocia mal.
• Actualizaciones. Las actualizaciones A/B por streaming se instalan aunque el dispositivo tenga poco espacio. Solo funcionan en dispositivos con particiones A/B.

Permisos

• Nuevos. ANSWER_PHONE_CALLS y READ_PHONE_NUMBERS, ambos peligrosos y del grupo PHONE; MANAGE_OWN_CALLS, un permiso normal para apps de VoIP que gestionan sus propias llamadas con un ConnectionService autogestionado.
• Instalar apps desconocidas. REQUEST_INSTALL_PACKAGES ya existía, pero una app con target API 26 ahora debe declararlo para enviar al usuario al instalador de paquetes. Su nivel de protección es signature|appop: el usuario lo concede por app en Ajustes, no en un diálogo en ejecución. Lleva al usuario a esa pantalla con ACTION_MANAGE_UNKNOWN_APP_SOURCES y compruébalo con canRequestPackageInstalls().
• Otorgamiento por grupo corregido. Antes de 8.0, conceder un permiso también concedía todos los demás de su grupo que la app declaraba. En las apps con target API 26 solo se concede el que se pidió. Una solicitud posterior del mismo grupo se sigue aprobando sin diálogo.
• Cuentas. GET_ACCOUNTS ya no basta para que una app con target API 26 vea las cuentas del usuario. Usa AccountManager.newChooseAccountIntent() o el método propio del autenticador.
• Ventanas de alerta. Las apps con SYSTEM_ALERT_WINDOW y target API 26 deben dibujar con TYPE_APPLICATION_OVERLAY. Esas ventanas quedan debajo de la barra de estado y del teclado, y el usuario puede bloquearlas desde el panel de notificaciones.

Qué cambió para tu app

Todas las apps en Android 8.0

Apps con target API 26

Los receivers del manifest siguen recibiendo los broadcasts enviados solo a la propia app (como ACTION_MY_PACKAGE_REPLACED), los que exigen un permiso de firma y una lista publicada de broadcasts implícitos exentos. Los cambios de permisos para apps con target API 26 (instalaciones, cuentas, ventanas de alerta, otorgamiento por grupo) están en Permisos.

Qué perduró

• Los límites en segundo plano siguieron apretando. Android 9 agregó el permiso FOREGROUND_SERVICE, y las apps con target Android 12 ya no pueden iniciar servicios en primer plano desde segundo plano, salvo en unos pocos casos.
• Los canales de notificación siguen siendo obligatorios. Android 13 sumó encima el permiso en ejecución POST_NOTIFICATIONS.
• Los íconos adaptables son hoy el formato de ícono. Android 13 agregó una capa monocromática para los íconos temáticos.
• Treble rindió frutos en Android 9: los dispositivos lanzados con 9 o posterior pueden ejecutar una imagen genérica del sistema (adb shell getprop ro.treble.enabled lo indica). Las interfaces HIDL de esa época hoy están obsoletas en favor de AIDL para las capas de abstracción de hardware.
• El número de serie y el IMEI fueron más lejos en Android 10: Build.getSerial() exige READ_PRIVILEGED_PHONE_STATE, que las apps de Play no pueden tener.
• Instalar apps desconocidas se sigue concediendo por app.
• La regla de target API de Play empezó con esta versión: API 26 para apps nuevas en agosto de 2018 y para actualizaciones en noviembre de 2018. Desde 2019 el mínimo sube cada año, dentro del año siguiente a cada versión de Android.

Para saber

• El Easter egg es un pulpo. Toca “Android version” en “About phone”, mantén presionada la “O” que aparece y un pulpo flota en la pantalla. AOSP llama Ocquarium a la actividad, y las patas se mueven con SpringAnimation, del paquete de física de la support library.
• Los IDs de compilación de Android 8.0 empiezan con OPR (la primera etiqueta de AOSP, para el Pixel C, es la compilación OPR6.170623.010), y esa cadena aparece en el user agent. Google advirtió que la detección de navegadores que busca /OPR/ puede confundir cualquier navegador con Opera.
• El CDD de 8.0 exige que cada clave de atestación la compartan suficientes dispositivos como para que no identifique a ninguno. La forma que sugiere: una clave por cada 100 000 unidades de un modelo.
• En Build.java de AOSP, SERIAL se inicializa a propósito con una llamada a función, “to prevent its value being inlined in the app during compilation”, porque el sistema lo fija según el target SDK de la app.
• Un bucle de reinicios activa ahora “Rescue Party”. Cuando system_server se reinicia cinco veces en cinco minutos, o una app persistente del sistema falla cinco veces en 30 segundos, el sistema restablece ajustes en tres pasos cada vez más amplios. El cuarto arranca en recovery y ofrece restablecer el dispositivo de fábrica. En 8.0, una compilación userdebug conectada por USB lo omite.