Skip to content

Most visited

Recently visited

navigation

Cambios en Android 6.0

Además de nuevas funciones y capacidades, en Android 6.0 (nivel de API 23) se incluyen diversos cambios en el sistema y modificaciones en los comportamientos de la API. En este documento, se destacan algunos de los cambios claves que debes comprender y contemplar en tus apps.

Si publicaste anteriormente una app para Android, ten en cuenta que estos cambios en la plataforma afectan a tu app.

Permisos de tiempo de ejecución

En esta versión se presenta un nuevo modelo de permisos en el cual los usuarios ahora pueden administrar directamente los permisos de la app durante el tiempo de ejecución. Este modelo proporciona a los usuarios mayor visibilidad y control sobre los permisos y, al mismo tiempo, simplifica 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 aquellas de tus apps que estén orientadas a Android 6.0 (nivel de API 23) o versiones posteriores, asegúrate de comprobar y solicitar los permisos en tiempo de ejecución. Para determinar si se concedió un permiso a tu app, llama al nuevo método checkSelfPermission(). Para solicitar un permiso, llama al nuevo método requestPermissions(). Incluso cuando tu app no tenga como objetivo Android 6.0 (nivel de API 23), debes probarla de acuerdo con el nuevo modelo de permisos.

Si deseas obtener información detallada sobre la compatibilidad del nuevo modelo de permisos de tu app, consulta Trabajar con permisos del sistema. Para obtener consejos sobre cómo evaluar el impacto en tu app, consulta Prácticas recomendadas para permisos.

Modos Descanso y App Standby

En esta versión se presentan nuevas optimizaciones de ahorro de energía para apps y dispositivos inactivos. Estas funciones afectan a todas las apps, por lo que debes asegurarte de probarlas en estos modos nuevos.

Para obtener más información sobre estos cambios en el ahorro de energía, consulta Optimización 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 y se orienta a Android 2.3 (nivel de API 9) o una versión posterior, usa en su lugar la clase HttpURLConnection. Esta API es más eficaz porque reduce el uso de la red mediante una compresión y un almacenamiento de respuesta en caché transparentes, y minimiza el consumo de energía. Para continuar usando las Apache HTTP API, primero debes declarar la siguiente dependencia de tiempo de compilación de tu archivo build.gradle:

android {
    useLibrary 'org.apache.http.legacy'
}

BoringSSL

Actualmente, Android atraviesa una migración de la biblioteca OpenSSL a BoringSSL. Si usas el NDK de Android en tu app, no vincules bibliotecas criptográficas que no formen parte de la NDK API, como libcrypto.so y libssl.so. Estas bibliotecas no son API públicas y se pueden modificar o interrumpir sin aviso en todas las versiones y todos los dispositivos. A su vez, puedes exponerte a vulnerabilidades de seguridad. Como alternativa, modifica tu código nativo para llamar a las API de criptografía de Java a través de JNI o vincular estáticamente una biblioteca criptográfica que elijas.

Acceso al identificador de hardware

Para brindar una mejor protección de datos a los usuarios, a partir de esta versión, en Android se quita el acceso por programación al identificador de hardware local del dispositivo para apps que usen las Wi-Fi y Bluetooth API. Los métodos WifiInfo.getMacAddress() y BluetoothAdapter.getAddress() ahora muestran un valor constante de 02:00:00:00:00:00.

Para acceder a los identificadores de hardware de dispositivos externos cercanos por medio de escaneos de Bluetooth y Wi-Fi, ahora tu app debe tener los permisos ACCESS_FINE_LOCATION o ACCESS_COARSE_LOCATION:

Nota: Cuando un dispositivo con Android 6.0 (nivel de API 23) inicia un escaneo de Wi-Fi o Bluetooth en segundo plano, la operación es visible para dispositivos externos como si proviniera de una dirección MAC aleatoria.

Notificaciones

En esta versión se quita el método Notification.setLatestEventInfo(). Usa la clase Notification.Builder, en lugar de crear notificaciones. Para actualizar una notificación de manera repetida, reutiliza la instancia de Notification.Builder. Llama al método build() para obtener instancias de Notification actualizadas.

El comando adb shell dumpsys notification ya no imprime el texto de tu notificación. Usa el comando adb shell dumpsys notification --noredact en su lugar para imprimir el texto en un objeto de notificación.

Cambios en AudioManager

Ya no se admitirán las funciones de ajustar el volumen de forma directa o silenciar transmisiones específicas por medio de la clase AudioManager. El método setStreamSolo() es obsoleto, por lo que debes llamar al método requestAudioFocus() en su lugar. Del mismo modo, el método setStreamMute() es obsoleto; en su lugar, llama al método adjustStreamVolume() y pasa los valores de dirección ADJUST_MUTE o ADJUST_UNMUTE.

Selección de texto

Ahora, cuando los usuarios seleccionan texto en tu app, 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 de la barra de acciones contextuales, como se describe en Habilitación del 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 tus apps existentes:

  1. En tu objeto View o Activity, cambia tus llamadas ActionMode de startActionMode(Callback) a startActionMode(Callback, ActionMode.TYPE_FLOATING).
  2. Toma tu implementación existente de ActionMode.Callback y, como alternativa, haz que extienda ActionMode.Callback2.
  3. Anula el método onGetContentRect() para proporcionar las coordenadas del objeto Rect de contenido (como un rectángulo de selección de texto) en la vista.
  4. Si el posicionamiento del rectángulo ya no es válido y este es el único elemento que debe invalidarse, llama al método invalidateContentRect().

Si usas la biblioteca Android Support Library versión 22.2, ten en cuenta que las barras de herramientas flotantes no son compatibles con versiones anteriores y que appcompat toma el control de los objetos ActionMode de forma predeterminada. Esto impide que se muestren las barras de herramientas flotantes. Para permitir la compatibilidad de ActionMode en AppCompatActivity, llama a getDelegate(); luego, llama a setHandleNativeActionModesEnabled() en el objeto AppCompatDelegate mostrado y fija el parámetro de entrada en false. Esta llamada devuelve el control de los objetos ActionMode al framework. En los dispositivos con Android 6.0 (nivel de API 23), eso permite que el framework sea compatible con los modos de barras de herramientas flotantes o ActionBar, mientras que en los dispositivos con Android 5.1 (nivel de API 22) o versiones anteriores solo se admiten los modos ActionBar.

Cambios en marcadores de navegadores

Esta versión elimina la compatibilidad con marcadores globales. Se quitaron los métodos android.provider.Browser.getAllBookmarks() y android.provider.Browser.saveBookmark(). También se quitaron los permisos READ_HISTORY_BOOKMARKS y WRITE_HISTORY_BOOKMARKS. Si tu app está orientada a Android 6.0 (nivel de API 23) o versiones posteriores, no accedas a los marcadores desde el proveedor global ni uses los permisos de marcadores. Tu app debe guardar datos de marcadores internamente.

Cambios en Android Keystore

Con esta versión, el proveedor de Android Keystore ya no es compatible con DSA. ECDSA aún es compatible.

Las claves que no requieran encriptación de datos estáticos ya no se borrarán cuando se restablezca o inhabilite la pantalla bloqueada segura (por ejemplo, cuando lo haga el usuario o el administrador del dispositivo). Las claves que requieran encriptación de datos estáticos se borrarán 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.

Cambios en el servicio de cámara

En esta versión, el modelo para acceder a los recursos compartidos en el servicio de cámara se cambió del modelo de acceso anterior “por orden de llegada” a un modelo de acceso en el que se favorecen los procesos de prioridad alta. Entre los cambios en el comportamiento del servicio se incluyen los siguientes:

Tiempo de ejecución

El tiempo de ejecución ART ahora implementa correctamente reglas de acceso para el método newInstance(). Este cambio soluciona el problema por el cual Dalvik comprobaba las reglas de acceso incorrectamente en versiones anteriores. Si tu app usa el método newInstance() y deseas anular las comprobaciones de acceso, llama al método setAccessible() con el parámetro de entrada fijado en true. Si tu app usa la biblioteca appcompat v7 o la biblioteca recyclerview v7, debes actualizarla para usar las versiones más recientes de estas bibliotecas. De lo contrario, asegúrate de que las clases personalizadas a las que se haga referencia desde el XML estén actualizadas, de modo 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 reconoce la diferencia entre soname de una biblioteca y su ruta de acceso ( error público 6670), y ahora se implementa la búsqueda por soname. Las apps que anteriormente funcionaban y que tenían entradas DT_NEEDED incorrectas (generalmente, rutas de acceso absolutas en el sistema de archivos del equipo de compilación) pueden generar un error al cargarse.

Ahora se implementa correctamente el indicador dlopen(3) RTLD_LOCAL. Ten en cuenta que RTLD_LOCAL es el valor predeterminado, por lo que se verán afectadas las llamadas a dlopen(3) que no usen RTLD_LOCAL explícitamente (salvo que tu app use RTLD_GLOBAL explícitamente). Con RTLD_LOCAL, los símbolos no estarán disponibles para las bibliotecas cargadas por llamadas posteriores a dlopen(3) (a diferencia de lo que sucede al hacer referencia mediante entradas DT_NEEDED).

En versiones anteriores de Android, si tu app solicitaba al sistema que cargara una biblioteca compartida con reubicaciones de texto, el sistema mostraba una advertencia, pero de todas formas permitía la carga de 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 posterior. Para ayudarte a detectar si una biblioteca falló en la carga, tu app debe registrar la falla dlopen(3) e incluir el texto de la descripción del problema que muestra la llamada dlerror(3). Para obtener más información sobre el manejo de reubicaciones de texto, consulta esta guía.

Validación de APK

Ahora la plataforma realiza validaciones más estrictas de APK. El APK se considera dañado si un archivo se declara en el manifiesto y no está presente en el propio APK. Si se quita contenido, se debe volver a firmar el APK.

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. A fin de acceder al dispositivo y a su contenido por conexión USB, los usuarios deben conceder el permiso explícitamente para tales interacciones. Si tu app admite interacciones del usuario con el dispositivo a través de un puerto USB, ten en cuenta que la interacción debe habilitarse de manera explícita.

Cambios en Android for Work

En esta versión se incluyen los siguientes cambios en los comportamientos para Android for Work:

This site uses cookies to store your preferences for site-specific language and display options.

Hooray!

This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a one-minute survey?
Help us improve Android tools and documentation.