page.title=Cambios en los comportamientos page.keywords=versión preliminar,sdk,compatibilidad sdk.platform.apiLevel=MNC @jd:body
Además de nuevas características y capacidades, M Developer Preview incluye diversos cambios en el sistema y cambios en los comportamientos de la API. En este documento, se destacan algunos de los cambios principales que debe comprender y justificar en sus aplicaciones.
Si publicó anteriormente una aplicación para Android, tenga en cuenta que su aplicación podría verse afectada por estos cambios en la plataforma.
Esta versión preliminar introduce un nuevo modelo de permisos en el que los usuarios ahora pueden administrar directamente los permisos de la aplicación en tiempo de ejecución. Este modelo les 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 aplicaciones. Los usuarios pueden conceder o revocar permisos de forma individual para las aplicaciones instaladas.
En sus aplicaciones que tienen como destino la versión preliminar de Android M, asegúrese de comprobar y solicitar los permisos en tiempo de ejecución. Para determinar si se concedió un permiso a su aplicación, llame al nuevo método {@code Context.checkSelfPermission()}. Para solicitar un permiso, llame al nuevo método {@code Activity.requestPermission()}. Incluso si su aplicación no tiene como destino la versión preliminar de Android M, debería probar su aplicación de acuerdo con el nuevo modelo de permisos.
Para obtener detalles sobre la compatibilidad del nuevo modelo de permisos en su aplicación, consulte la página Permisos de la versión preliminar para desarrolladores. Para obtener consejos sobre cómo evaluar el impacto en su aplicación, consulte la Guía de prueba.
Esta versión preliminar introduce nuevas optimizaciones de ahorro de energía para aplicaciones y dispositivos inactivos.
Si un dispositivo está desconectado y permanece quieto con la pantalla apagada durante un período determinado, pasará al modo Doze, en el que el dispositivo intenta mantener el sistema en estado de suspensión. En este modo, los dispositivos reanudan periódicamente el funcionamiento normal durante períodos breves, de manera que la aplicación se pueda sincronizar y el sistema pueda realizar las operaciones pendientes.
Durante el modo Doze, se aplican las siguientes restricciones a sus aplicaciones:
Al salir del modo Doze, el dispositivo ejecuta los trabajos y las sincronizaciones pendientes.
Para probar esta característica, conecte un dispositivo que esté ejecutando la versión preliminar de Android M a su equipo de desarrollo y llame a los siguientes comandos:
$ adb shell dumpsys battery unplug $ adb shell dumpsys deviceidle step $ adb shell dumpsys deviceidle -h
Nota: La próxima versión de Google Cloud Messaging le permite designar mensajes de prioridad alta. Si su aplicación recibe mensajes de GCM de prioridad alta, se le concede un breve acceso a la red, incluso cuando el dispositivo se encuentra en modo Doze.
Consulte la Guía de prueba para obtener consejos sobre cómo probar el modo Doze en su aplicación.
Con esta versión preliminar, el sistema puede determinar que las aplicaciones se encuentran inactivas cuando no están en uso activo. La aplicación se considera inactiva después de un cierto período, salvo que el sistema detecte alguna de las siguientes señales:
Si el dispositivo está desconectado, las aplicaciones que se consideren inactivas tendrán deshabilitado el acceso a la red y se suspenderán sus sincronizaciones y trabajos. Cuando el dispositivo se conecte a un sistema de alimentación, estas aplicaciones se podrán conectar a la red y podrán ejecutar los trabajos y las sincronizaciones pendientes. Si el dispositivo queda inactivo durante períodos prolongados, las aplicaciones inactivas pueden acceder a la red aproximadamente una vez al día.
Para probar esta característica, conecte un dispositivo que esté ejecutando la versión preliminar de Android M a su equipo de desarrollo y llame a los siguientes comandos:
$ adb shell dumpsys battery unplug $ adb shell am set-idle <packageName> true $ adb shell am set-idle <packageName> false $ adb shell am get-idle <packageName>
Nota: La próxima versión de Google Cloud Messaging (GCM) le permite designar mensajes de prioridad alta. Si su aplicación recibe mensajes de GCM de prioridad alta, se le concede un breve acceso a la red, incluso cuando la aplicación está inactiva.
Consulte la Guía de prueba para obtener consejos sobre cómo probar el modo App Standby en sus aplicaciones.
Con esta versión preliminar, los usuarios pueden adoptar dispositivos de almacenamiento externo, como tarjetas SD. Al adoptar un dispositivo de almacenamiento externo, el dispositivo se cifra y se formatea para que actúe como un elemento de almacenamiento interno. Esta característica les permite a los usuarios mover tanto las aplicaciones como los datos privados de esas aplicaciones entre dispositivos de almacenamiento. Al mover aplicaciones, el sistema respeta la preferencia {@code android:installLocation} del manifiesto.
Si su aplicación accede a las API o a los campos que se indican a continuación, tenga en cuenta que las rutas de archivo que devuelven se modificarán dinámicamente cuando la aplicación se mueva entre dispositivos de almacenamiento interno y externo. Al crear rutas de archivo, lo más recomendable es que siempre llame a estas API de forma dinámica. No use rutas de archivo codificadas de forma rígida ni continúe usando rutas de archivo completas que se hayan creado anteriormente.
Para depurar esta característica en la versión preliminar para desarrolladores, puede habilitar la opción de adoptar una unidad USB que esté conectada a un dispositivo Android mediante un cable USB On-The-Go (OTG) y para habilitarla puede ejecutar el siguiente comando:
$ adb shell sm set-force-adoptable true
Esta versión preliminar elimina el soporte del cliente HTTP de Apache. Si su aplicación utiliza este cliente y tiene como destino Android 2.3 (API de nivel 9) o una versión posterior, use, en su lugar, la clase {@link java.net.HttpURLConnection}. Esta API es más eficaz porque reduce el uso de la red mediante compresión y almacenamiento de respuesta en caché transparentes, y minimiza el consumo de energía. Para continuar utilizando las API HTTP de Apache, primero debe declarar la siguiente dependencia en tiempo de compilación en su archivo {@code build.gradle}:
android { useLibrary 'org.apache.http.legacy' }
Android está migrando de la biblioteca OpenSSL a BoringSSL . Si utiliza Android NDK en su aplicación, no vincule bibliotecas criptográficas que no forman parte de la API de NDK, como {@code libcrypto.so} y {@code 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. Además, puede exponerse a vulnerabilidades de seguridad. En cambio, modifique su código nativo para llamar a las API de criptografía de Java a través de JNI o para vincular estáticamente una biblioteca criptográfica de su elección.
Ya no se admitirán las funciones de ajustar el volumen de forma directa o silenciar secuencias específicas por medio de la clase {@link android.media.AudioManager} . El método {@link android.media.AudioManager#setStreamSolo(int,boolean) setStreamSolo()} es obsoleto, por lo que debe llamar al método {@code AudioManager.requestAudioFocus()} en su lugar. Del mismo modo, el método {@link android.media.AudioManager#setStreamMute(int,boolean) setStreamMute()} es obsoleto; en su lugar, llame al método{@code AudioManager.adjustStreamVolume()} y pase los valores de dirección {@code ADJUST_MUTE} o {@code ADJUST_UNMUTE}.
Ahora, cuando los usuarios seleccionen texto en su aplicación, usted puede 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 la sección Habilitación del modo de acción contextual para vistas individuales.
Si desea implementar una barra de herramientas flotante para selección de texto, realice los siguientes cambios en sus aplicaciones existentes:
Si utiliza la biblioteca Android Support Library versión 22.2, tenga en cuenta que las barras de herramientas flotantes no son compatibles con versiones anteriores y AppCompat toma el control de los objetos {@link android.view.ActionMode} de forma predeterminada. Esto impide que se muestren las barras de herramientas flotantes. Para permitir la compatibilidad de {@link android.view.ActionMode} en {@link android.support.v7.app.AppCompatActivity}, llame a {@code android.support.v7.app.AppCompatActivity.getDelegate()}, luego llame a {@code android.support.v7.app.AppCompatDelegate.setHandleNativeActionModesEnabled()} en el objeto {@link android.support.v7.app.AppCompatDelegate} devuelto y configure el parámetro de entrada como {@code false}. Esta llamada devuelve el control de los objetos {@link android.view.ActionMode} al marco de trabajo. En los dispositivos que ejecutan la versión preliminar de Android M, eso permite que el marco de trabajo admita los modos de barras de herramientas flotantes o {@link android.support.v7.app.ActionBar}, mientras que en los dispositivos anteriores a la versión preliminar de Android M solo se admiten los modos {@link android.support.v7.app.ActionBar}.
Con esta versión preliminar, el proveedor de Android Keystore ya no admite DSA. Aún se admite ECDSA.
Las claves que no requieren cifrado de datos estáticos ya no se eliminarán cuando se restablezca o deshabilite la pantalla de bloqueo seguro (por ejemplo, cuando lo haga el usuario o el administrador del dispositivo). Las claves que requieren el cifrado de datos estáticos se eliminarán durante estos eventos.
Esta versión preliminar introduce en las API de redes y Wi-Fi los siguientes cambios en los comportamientos.
En esta versión preliminar, 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. Los cambios en el comportamiento del servicio incluyen los siguientes:
El tiempo de ejecución de ART ahora implementa correctamente reglas de acceso para el método {@link java.lang.reflect.Constructor#newInstance(java.lang.Object...) newInstance()}. Este cambio soluciona el problema que ocurría con Dalvik, que comprobaba las reglas de acceso incorrectamente en las versiones anteriores. Si su aplicación utiliza el método {@link java.lang.reflect.Constructor#newInstance(java.lang.Object...) newInstance()} y usted desea invalidar comprobaciones de acceso, llame al método {@link java.lang.reflect.Constructor#setAccessible(boolean) setAccessible()} con el parámetro de entrada configurado en {@code true}. Si su aplicación utiliza la biblioteca AppCompat versión 7 o la biblioteca RecyclerView versión 7, debe actualizar su aplicación para utilizar las versiones más recientes de estas bibliotecas. De lo contrario, asegúrese de que las clases personalizadas a las que se haga referencia desde el XML estén actualizadas, de manera que se pueda acceder a sus constructores de clases.
Esta versión preliminar actualiza el comportamiento del vinculador dinámico. El vinculador dinámico ahora entiende la diferencia entre {@code soname} de una biblioteca y su ruta de acceso ( error público 6670), y ahora se implementa la búsqueda por {@code soname}. Las aplicaciones que anteriormente funcionaban y que tenían entradas {@code DT_NEEDED} incorrectas (generalmente, rutas absolutas en el sistema de archivo del equipo de compilación) pueden generar error al cargarse.
Ahora se implementa correctamente la marca {@code dlopen(3) RTLD_LOCAL}. Tenga en cuenta que {@code RTLD_LOCAL} es lo predeterminado, por lo que se verán afectadas las llamadas a {@code dlopen(3)} que no utilizaron explícitamente {@code RTLD_LOCAL} (salvo que su aplicación haya usado {@code RTLD_GLOBAL} explícitamente). Con {@code RTLD_LOCAL}, los símbolos no estarán disponibles para las bibliotecas cargadas por llamadas posteriores a {@code dlopen(3)} (a diferencia de lo que sucede al hacer referencia mediante entradas {@code DT_NEEDED}).
Ahora la plataforma realiza validaciones más estrictas de APK. El APK se considera dañado si un archivo está declarado en el manifiesto, pero no está presente en el APK en sí. Si se elimina algún contenido, se debe volver a firmar el APK.
Esta versión preliminar incluye los siguientes cambios en los comportamientos para Android for Work: