Además de nuevas funciones y capacidades, Android 6.0 (nivel de API 23) incluye una variedad de cambios en el sistema y en el comportamiento de las APIs. En este documento se destaca algunos de los cambios clave que debes comprender y justificar en tus apps.
Si publicaste anteriormente una aplicación para Android, ten en cuenta que estos cambios en la de la plataforma afectan tu app.
Permisos de tiempo de ejecución
En esta versión se presenta un nuevo modelo de permisos en el que los usuarios ahora pueden administrar directamente permisos de la app durante el tiempo de ejecución. Este modelo brinda a los usuarios mayor visibilidad y control sobre y, al mismo tiempo, optimizar los procesos de instalación y actualización automática para los desarrolladores de apps. Los usuarios pueden conceder o revocar permisos de forma individual para las apps instaladas.
En las apps que se orientan a Android 6.0 (nivel de API 23) o versiones posteriores, asegúrate de verificar y solicitar
permisos durante el tiempo de ejecución. Para determinar si se concedió un permiso a tu app, llama al
nuevo checkSelfPermission()
. Para solicitar un permiso, llama al nuevo
requestPermissions()
. Incluso si tu app no está orientada a Android 6.0 (nivel de API 23), debes probarla de acuerdo con lo siguiente:
el nuevo modelo de permisos.
Para obtener detalles sobre la compatibilidad del nuevo modelo de permisos en tu app, consulta Cómo trabajar con permisos del sistema Para obtener sugerencias sobre cómo evaluar el impacto en tu app, consulta las Notas de uso de permisos.
Descanso y App Standby
En esta versión se presentan nuevas optimizaciones de ahorro de energía para apps y dispositivos inactivos. Estos afectan a todas las apps, así que asegúrate de probarlas en estos modos nuevos.
- Descanso: Si un usuario desconecta un dispositivo y lo deja quieto, con la pantalla apagada, durante un tiempo, el dispositivo entra en el modo Descanso, en el que intenta mantener el sistema en estado de suspensión. En este modo, los dispositivos reanudan periódicamente el funcionamiento normal durante períodos breves para que se pueda sincronizar la aplicación y el sistema pueda realizar las operaciones pendientes.
- App Standby: Esta función permite que el sistema determine que una app está inactiva. cuando el usuario no lo usa activamente. El sistema hace esta determinación cuando el usuario no tocar la aplicación durante cierto período de tiempo. Si el dispositivo está desenchufado, el sistema inhabilita la red accederá y suspende las sincronizaciones y los trabajos de las apps que considere inactivas.
Para obtener más información sobre estos cambios en el ahorro de energía, consulta Cómo optimizar para Descanso y App Standby.
Eliminación del cliente HTTP de Apache
En la versión de Android 6.0 se elimina la compatibilidad con el cliente HTTP de Apache. Si tu app usa este cliente
se orienta a Android 2.3 (nivel de API 9) o versiones posteriores, usa la clase HttpURLConnection
.
en su lugar. Esta API es más eficiente porque reduce el uso de la red mediante una compresión transparente
y el almacenamiento en caché de respuestas
y minimiza el consumo de energía. Para seguir usando las APIs de HTTP de Apache, puedes
primero debes declarar la siguiente dependencia en tiempo de compilación en tu archivo build.gradle
:
android { useLibrary 'org.apache.http.legacy' }
BoringSSL
Android está migrando de OpenSSL a la
BoringSSL.
biblioteca. Si usas el NDK de Android en tu app, no vincules bibliotecas criptográficas.
que no forman parte de la API del NDK, como libcrypto.so
y libssl.so
. Estos
las bibliotecas no son APIs públicas y se pueden modificar o interrumpir sin previo aviso en todas las versiones y dispositivos.
A su vez, puedes exponerte a vulnerabilidades de seguridad. En cambio, modifica tu
código nativo para llamar a las APIs de criptografía de Java a través de JNI o vincular estáticamente una
biblioteca de criptografía de tu elección.
Acceso al identificador de hardware
Para brindar a los usuarios una mayor protección de datos, a partir de esta versión, Android
quita el acceso programático al identificador de hardware local del dispositivo para
apps que usan las APIs de Wi-Fi y Bluetooth. El
WifiInfo.getMacAddress()
y las
BluetoothAdapter.getAddress()
métodos
ahora muestra un valor constante de 02:00:00:00:00:00
.
Para acceder a los identificadores de hardware de dispositivos externos cercanos por medio de búsquedas de Bluetooth y Wi-Fi, haz lo siguiente:
tu app ahora debe tener el objeto ACCESS_FINE_LOCATION
o
Permisos de ACCESS_COARSE_LOCATION
:
Nota: Cuando un dispositivo con Android 6.0 (nivel de API 23) inicia una búsqueda de Wi-Fi o Bluetooth en segundo plano, la operación es visible para dispositivos externos como que provienen de una dirección MAC aleatoria.
Notificaciones
En esta versión, se quita el método Notification.setLatestEventInfo()
. Usa el
Notification.Builder
para crear notificaciones. Para actualizar un
varias veces, vuelve a usar la instancia de Notification.Builder
. Llama al
build()
para obtener
actualizó Notification
instancia.
El comando adb shell dumpsys notification
ya no imprime el texto de la notificación.
En su lugar, usa el comando adb shell dumpsys notification --noredact
para imprimir el texto.
en un objeto de notificación.
Cambios en AudioManager
Establecer el volumen directamente o silenciar transmisiones específicas con el AudioManager
ya no se admite. El método setStreamSolo()
dejó de estar disponible. Deberías llamar al
requestAudioFocus()
en su lugar. De forma similar, el
El método setStreamMute()
es
obsoleto; en su lugar, llama al método adjustStreamVolume()
y pasa el valor de dirección
ADJUST_MUTE
o
ADJUST_UNMUTE
Selección de texto
Cuando los usuarios seleccionan texto en tu app, ahora puedes mostrar acciones de selección de texto, como Cortar, Copiar y Pegar en una barra de herramientas flotante. La implementación de la interacción del usuario es similar a la para la barra de acciones contextuales, como se describe en Habilitar el modo de acción contextual para vistas individuales
Si deseas implementar una barra de herramientas flotante para selección de texto, realiza los siguientes cambios en tu archivo apps:
- En el objeto
View
oActivity
, cambia laActionMode
llamadas destartActionMode(Callback)
astartActionMode(Callback, ActionMode.TYPE_FLOATING)
. - Toma tu implementación existente de
ActionMode.Callback
y ajústalaActionMode.Callback2
en su lugar. - Anula el
onGetContentRect()
para proporcionar las coordenadas del objetoRect
de contenido (como un rectángulo de selección de texto) en la vista. - Si el posicionamiento del rectángulo ya no es válido y este es el único elemento que se invalidará,
Llama al método
invalidateContentRect()
.
Si utilizas
Android Support Library versión 22.2, ten en cuenta que las barras de herramientas flotantes
retrocompatible, y appcompat toma el control de los objetos ActionMode
de forma predeterminada. Esto impide que se muestren las barras de herramientas flotantes. Para habilitar
Compatibilidad con ActionMode
en un
AppCompatActivity
, llamada
getDelegate()
y, luego, llama
setHandleNativeActionModesEnabled()
en los artículos que se devuelven
AppCompatDelegate
y configura la entrada
parámetro en false
. Esta llamada devuelve el control de los objetos ActionMode
a
en el framework. En dispositivos con Android 6.0 (nivel de API 23), eso permite que el framework admita
Modos ActionBar
o de barra de herramientas flotante, en dispositivos en ejecución
Para Android 5.1 (nivel de API 22) o versiones anteriores, solo se admiten los modos ActionBar
no es compatible.
Cambios en marcadores de navegadores
Esta versión elimina la compatibilidad con marcadores globales. El
android.provider.Browser.getAllBookmarks()
y android.provider.Browser.saveBookmark()
se quitaron métodos. Del mismo modo, READ_HISTORY_BOOKMARKS
y WRITE_HISTORY_BOOKMARKS
se quitan los permisos. Si tu app está orientada a Android 6.0 (nivel de API 23) o versiones posteriores, no accedas
los favoritos del proveedor global o usar los permisos de favoritos. En cambio, tu app debe almacenar
los datos de los marcadores internamente.
Cambios en Android Keystore
Con este lanzamiento, la El proveedor de Android Keystore ya no admite. DSA. ECDSA aún es compatible.
Las claves que no requieran encriptación en reposo ya no se borrarán cuando la pantalla de bloqueo sea segura se inhabilite o restablezca (por ejemplo, por el usuario o un administrador del dispositivo). Claves que requieren la encriptación en reposo se borrará durante estos eventos.
Cambios en las funciones de red y Wi-Fi
En esta versión se presentan los siguientes cambios de comportamiento en las API de redes y Wi-Fi.
- Ahora tus apps pueden cambiar el estado de los objetos
WifiConfiguration
únicamente si tú creaste estos objetos. No tienes permiso para modificar ni borrar ObjetosWifiConfiguration
creados por el usuario o por otras apps -
Anteriormente, si una app forzaba al dispositivo a conectarse a una red Wi-Fi específica mediante
enableNetwork()
con el ConfiguracióndisableAllOthers=true
, el dispositivo se desconectó de otras redes, como datos móviles. En esta versión, el dispositivo ya no se desconecta de otras redes como estas. Si LatargetSdkVersion
de tu app es de“20”
o inferior, y se fija a la Red Wi-Fi. Si latargetSdkVersion
de tu app es“21”
o superior, usa la APIs de redes múltiples (comoopenConnection()
,bindSocket()
y la nuevabindProcessToNetwork()
) para garantizar que el tráfico de red se envíe a la red seleccionada.
Cambios en el servicio de cámara
En esta versión, se cambió el modelo para acceder a los recursos compartidos en el servicio de cámara. del modelo de acceso anterior “por orden de llegada” a un modelo de acceso en el que la prioridad los procesos de análisis se favorecen. Entre los cambios en el comportamiento del servicio se incluyen los siguientes:
- El acceso a los recursos del subsistema de la cámara, lo que incluye abrir y configurar un dispositivo de cámara, está otorgarse en función de la “prioridad” del proceso de solicitud del cliente. Los procesos de aplicación con Por lo general, las actividades en primer plano o visibles para el usuario reciben una prioridad más alta, lo que hace que los recursos de la cámara que la adquisición y el uso sean más confiables.
- Los clientes con cámara activa para apps de menor prioridad pueden ser “expulsados” cuando una prioridad más alta.
cuando la aplicación intenta usar la cámara. En la API de
Camera
obsoleta, esto da como resultadoonError()
es solicitado al cliente expulsado. En la API deCamera2
, da como resultadoonDisconnected()
que se llama en nombre del cliente expulsado. - En los dispositivos con el hardware de cámara correcto, procesos independientes de la aplicación pueden abrir y usar dispositivos de cámara separados al mismo tiempo. Sin embargo, el uso de varios procesos casos en los que el acceso simultáneo causa una degradación significativa del rendimiento cualquiera de los dispositivos de cámara abiertos, ahora son detectados y inhabilitados por el servicio de cámara. Este cambio puede generar “expulsiones” de clientes de menor prioridad, incluso cuando ninguna otra aplicación esté directamente intenta acceder al mismo dispositivo de cámara.
- Cambiar el usuario actual genera clientes de cámara activos en apps que pertenecen a la cuenta de usuario anterior. expulsarse. El acceso a la cámara se limita a perfiles de usuario que pertenezcan al usuario actual del dispositivo. En la práctica, esto significa que una cuenta de "invitado", por ejemplo, no podrá dejar de ejecutar procesos que usan el subsistema de la cámara cuando el usuario cambia a otra cuenta.
Tiempo de ejecución
El tiempo de ejecución de ART ahora implementa correctamente las reglas de acceso para el
newInstance()
. Esta
Solución de cambios soluciona el problema por el que Dalvik comprobaba las reglas de acceso incorrectamente en versiones anteriores.
Si tu app usa
newInstance()
y tú
si quieres anular las comprobaciones de acceso, llama al
Método setAccessible()
con la entrada
configurado en true
. Si tu app usa
biblioteca appcompat v7 o
Biblioteca recyclerview v7
debes actualizar tu app para usar las versiones más recientes de estas bibliotecas. De lo contrario, asegúrate de que
Las clases personalizadas a las que se hace referencia desde XML se actualizan para que se pueda acceder a sus constructores de clases.
En esta versión se actualiza el comportamiento del vinculador dinámico. El vinculador dinámico ahora entiende
Diferencia entre un soname
de una biblioteca y su ruta de acceso
()
error público 6670) y la búsqueda por soname
ahora es
cuando se implementa un plan. Apps que anteriormente funcionaban y que tenían entradas DT_NEEDED
incorrectas
(por lo general, rutas de acceso absolutas en el sistema de archivos de la máquina de compilación) pueden fallar cuando se carga.
Ahora se implementó correctamente la marca dlopen(3) RTLD_LOCAL
. Ten en cuenta que
RTLD_LOCAL
es la opción predeterminada, por lo que las llamadas a dlopen(3)
que no se usaron de forma explícita
Se verá afectada RTLD_LOCAL
(a menos que tu app haya usado explícitamente RTLD_GLOBAL
). Con
RTLD_LOCAL
, los símbolos no estarán disponibles para las bibliotecas cargadas por llamadas posteriores a
dlopen(3)
(en lugar de que se haga referencia a las entradas DT_NEEDED
).
En versiones anteriores de Android, si tu app solicitaba que el sistema cargara una biblioteca compartida con
de texto, el sistema mostraba una advertencia, pero permitía cargar la biblioteca.
A partir de esta versión, el sistema rechaza esta biblioteca si la versión del SDK de destino de tu app es la 23.
o una superior. Para ayudarte a detectar si se produjo un error al cargar una biblioteca, tu app debe registrar el
Error de dlopen(3)
e incluye el texto de descripción del problema que dlerror(3)
que muestra la llamada. Para obtener más información sobre cómo manejar las reubicaciones de texto, consulta este
guía.
Validación de APK
Ahora la plataforma realiza validaciones más estrictas de APK. Un APK se considera dañado si se declarado en el manifiesto, pero que no están presentes en el APK en sí. Se debe volver a firmar un APK si alguno de los el contenido del proyecto.
Conexión USB
Las conexiones del dispositivo a través del puerto USB ahora están configuradas de manera predeterminada para el modo de solo carga. Cómo acceder el dispositivo y su contenido a través de una conexión USB, los usuarios deben otorgar permiso explícitamente para el interacciones. Si la aplicación admite interacciones del usuario con el dispositivo a través de un puerto USB, ten en cuenta lo siguiente: consideración de que la interacción debe habilitarse explícitamente.
Cambios en Android for Work
En esta versión se incluyen los siguientes cambios en los comportamientos para Android for Work:
- Contactos de trabajo en contextos personales. Google Dialer
El Registro de llamadas ahora muestra los contactos de trabajo cuando el usuario ve las llamadas anteriores.
Parámetro de configuración
setCrossProfileCallerIdDisabled()
paratrue
oculta los contactos del perfil de trabajo en el Registro de llamadas de Google Dialer. Los contactos de trabajo pueden junto con los contactos personales en los dispositivos a través de Bluetooth solo si establecesetBluetoothContactSharingDisabled()
enfalse
. De forma predeterminada, se establece entrue
. - Eliminación de la configuración de Wi-Fi: Parámetros de configuración de Wi-Fi agregados por un propietario de perfil.
(por ejemplo, mediante llamadas a la
addNetwork()
) si se borra ese perfil de trabajo. - Bloqueo de la configuración de Wi-Fi: Cualquier configuración de Wi-Fi creada por
un Propietario del dispositivo activo ya no puede ser modificado ni borrado si
WIFI_DEVICE_OWNER_CONFIGS_LOCKDOWN
no es cero. El usuario aún puede crear y modificar sus propias configuraciones de Wi-Fi. Dispositivo activo Los propietarios tienen el privilegio de editar o quitar configuraciones de Wi-Fi, incluidas los que no crearon. - Descarga del controlador de política de dispositivo a través de la incorporación de una Cuenta de Google: Cuando un usuario cuenta que requiere administración mediante una app de controlador de política de dispositivo (DPC) se agrega a un dispositivo fuera de un contexto administrado, el flujo para agregar cuentas ahora le solicita al usuario que instale el el WPC apropiado. Este comportamiento también se aplica a las cuentas agregadas a través de Configuración > Cuentas y en el asistente de configuración inicial del dispositivo.
- Cambios en comportamientos específicos de la API de
DevicePolicyManager
:- Llamar al
setCameraDisabled()
afecta a la cámara solo para el usuario que lo llama; llamarlo desde el perfil administrado no afectan las apps de cámara que se ejecutan en el usuario principal. - Además, el
setKeyguardDisabledFeatures()
ya está disponible para los propietarios de perfiles y de dispositivos. - Un propietario de perfil puede configurar estas restricciones de protección de seguridad:
KEYGUARD_DISABLE_TRUST_AGENTS
yKEYGUARD_DISABLE_FINGERPRINT
, que afectan al configuración de bloqueo del teclado para el usuario principal del perfil.KEYGUARD_DISABLE_UNREDACTED_NOTIFICATIONS
, que solo afecta a las notificaciones que generan las aplicaciones del perfil administrado.
- Se dieron de baja los métodos
DevicePolicyManager.createAndInitializeUser()
yDevicePolicyManager.createUser()
. - El
setScreenCaptureDisabled()
ahora también bloquea la estructura de asistencia cuando una aplicación del usuario determinado se ejecuta en primer plano. EXTRA_PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM
el valor predeterminado ahora es SHA-256. SHA-1 aún es compatible con versiones anteriores, pero se quitará en el futuro.EXTRA_PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM
ahora solo acepta SHA-256.- Las API de inicializador de dispositivo que existían en Android 6.0 (nivel de API 23) ahora se han quitado.
- Se quitó
EXTRA_PROVISIONING_RESET_PROTECTION_PARAMETERS
, por lo que se produjo un cambio de NFC el aprovisionamiento no puede desbloquear de forma programática un dispositivo con restablecimiento de la configuración de fábrica protegido. - Ahora puedes usar
EXTRA_PROVISIONING_ADMIN_EXTRAS_BUNDLE
adicional para pasar datos a la app del propietario del dispositivo durante el aprovisionamiento de NFC del dispositivo administrado. - Las API de Android for Work están optimizadas para los permisos de tiempo de ejecución de M, incluidos los perfiles de trabajo,
capa de asistencia y otros. Las nuevas APIs de permisos
DevicePolicyManager
no afectan a las apps anteriores a M. - Cuando los usuarios abandonan la parte síncrona del flujo de configuración que se inició a través de un
ACTION_PROVISION_MANAGED_PROFILE
oACTION_PROVISION_MANAGED_DEVICE
, el sistema ahora muestra un código de resultadoRESULT_CANCELED
.
- Llamar al
- Cambios en otras APIs:
- Uso de datos: Se cambió el nombre de la clase
android.app.usage.NetworkUsageStats
NetworkStats
- Uso de datos: Se cambió el nombre de la clase
- Cambios en la configuración global:
- Estos parámetros de configuración ya no se pueden establecer mediante
setGlobalSettings()
:BLUETOOTH_ON
DEVELOPMENT_SETTINGS_ENABLED
MODE_RINGER
NETWORK_PREFERENCE
WIFI_ON
- Esta configuración global ahora se puede establecer a través de
setGlobalSettings()
:
- Estos parámetros de configuración ya no se pueden establecer mediante