From 4fd1a573eb0724251b5c0986c7f0ae7b36d52369 Mon Sep 17 00:00:00 2001
From: David Friedman M Developer Preview le brinda una perspectiva avanzada de la próxima versión de la plataforma Android, que ofrece nuevas características para usuarios y desarrolladores de aplicaciones.
+
+ En este documento, se brinda una introducción sobre las API más distinguidas. M Developer Preview está destinado a usuarios desarrolladores principiantes y evaluadores.
+ Si le interesa influenciar la dirección del marco de trabajo de Android,
+pruebe M Developer Preview y envíenos sus comentarios.
+
+ Advertencia: No publique las aplicaciones que utilizan M Developer Preview en la tienda de Google Play.
+ Nota: Este documento, a menudo, hace referencia a clases y métodos que aún no cuentan con materiales de referencia disponibles en developer.android.com.
+ Estos elementos de API tienen el formato {@code code style} en este documento (sin hipervínculos).
+ Para obtener la documentación preliminar de la API para estos elementos, descargue la referencia de la versión preliminar.
+ Si publicó anteriormente una aplicación para Android, tenga en cuenta que su aplicación podría verse afectada por los cambios en la plataforma.
+ Consulte la sección Cambios en los comportamientos para obtener información detallada. Esta versión preliminar mejora el sistema de intentos de Android al proporcionar una vinculación más sólida de la aplicación. Esta característica le permite asociar una aplicación con un dominio web propio.
+ Según esta asociación, la plataforma puede determinar la aplicación predeterminada que se debe utilizar para controlar un vínculo web en particular y omitir el paso de pedirles a los usuarios que seleccionen una aplicación. Para aprender a implementar esta característica, consulte la sección
+Vinculación de la aplicación.
+
+
+
+ Ahora, el sistema realiza restauraciones y copias de seguridad de datos completas y automáticas para las aplicaciones. Este comportamiento se habilita de forma predeterminada para las aplicaciones que tienen como destino la versión preliminar de Android M; usted no necesita agregar ningún código adicional.
+ Si los usuarios eliminan sus cuentas de Google, también se eliminarán sus datos de copias de seguridad.
+ Para obtener información sobre cómo funciona esta característica y cómo configurar qué elementos incluir en la copia de seguridad del sistema de archivo, consulte la sección
+Copia de seguridad automática para aplicaciones.
+ Esta versión preliminar ofrece nuevas API para permitirle autenticar usuarios al usar escaneos de huellas dactilares en los dispositivos compatibles y verificar cuán reciente es la última autenticación del usuario al utilizar un mecanismo de desbloqueo de dispositivos (como una contraseña de pantalla de bloqueo).
+
+ Use estas API junto con el sistema Android Keystore.
+ Para autenticar usuarios mediante el escaneo de huellas dactilares, obtenga una instancia de la nueva clase
+{@code android.hardware.fingerprint.FingerprintManager} y llame al método
+{@code FingerprintManager.authenticate()}. Su aplicación se debe ejecutar en un dispositivo compatible con un sensor de huellas dactilares.
+ Debe implementar la interfaz de usuario para el flujo de autenticación por huellas dactilares en su aplicación y debe utilizar el ícono de huella dactilar estándar de Android en la UI. El ícono de huella dactilar de Android ({@code c_fp_40px.png}) se incluye en la
+aplicación de muestra. Si está desarrollando múltiples aplicaciones que utilizan la autenticación por huellas dactilares, tenga en cuenta que cada aplicación debe autenticar la huella dactilar del usuario de manera independiente.
+
+
+
+ Para utilizar esta característica en su aplicación, primero agregue el permiso {@code USE_FINGERPRINT} en su manifiesto.
+ Para ver cómo una aplicación implementa la autenticación por huellas dactilares, consulte la sección
+
+Ejemplo de diálogo de huella dactilar. Si está evaluando esta característica, siga estos pasos: En Windows, posiblemente tenga que ejecutar {@code telnet 127.0.0.1 <emulator-id>} seguido de
+ {@code finger touch <finger_id>}.
+ Su aplicación puede autenticar usuarios según el tiempo que haya pasado desde que desbloquearon su dispositivo por última vez. Esta característica evita que los usuarios tengan que recordar contraseñas adicionales específicas de la aplicación y elimina la necesidad de que usted tenga que implementar su propia interfaz de usuario de autenticación.
+
+ Su aplicación debe utilizar esta característica junto con una implementación de clave pública o secreta para la autenticación del usuario.
+ Para definir la duración del tiempo de espera en el que se puede volver a usar la misma clave después de que un usuario se haya autenticado correctamente, llame al nuevo método
+{@code android.security.keystore.KeyGenParameterSpec.setUserAuthenticationValidityDurationSeconds()}
+cuando configure {@link javax.crypto.KeyGenerator} o
+{@link java.security.KeyPairGenerator}.
+ Esta característica actualmente funciona para operaciones criptográficas simétricas.
+ Evite mostrar el diálogo de nueva autenticación de forma excesiva: sus aplicaciones deben intentar utilizar el objeto criptográfico primero y, si se agota el tiempo de espera, deben usar el método
+{@link android.app.KeyguardManager#createConfirmDeviceCredentialIntent(java.lang.CharSequence, java.lang.CharSequence) createConfirmDeviceCredentialIntent()}
+para volver a autenticar el usuario dentro de su aplicación.
+
+ Para ver cómo la aplicación implementa esta característica, consulte la sección
+
+Ejemplo de cómo confirmar la credencial. Esta versión preliminar le proporciona API para que la acción de compartir sea intuitiva y rápida para los usuarios. Ahora, puede definir destinos para compartir de forma directa que inician una actividad específica en su aplicación. Estos destinos para compartir de forma directa se exponen a los usuarios a través del menú Share.
+
+ Esta característica les permite a los usuarios compartir contenido con los destinos, como contactos, dentro de otras aplicaciones.
+ Por ejemplo, el destino para compartir de forma directa podría iniciar una actividad en otra aplicación de red social, lo que le permite al usuario compartir contenido directamente con una comunidad o un amigo específicos de esa aplicación.
+
+ Para habilitar destinos para compartir de forma directa, debe definir una clase que extienda el
+{@code android.service.} El ejemplo a continuación muestra de qué manera podría declarar {@code ChooserTargetService} en su manifiesto.
+ Para cada actividad que desee exponer a {@code ChooserTargetService}, agregue un elemento
+{@code <meta-data>} con el nombre
+{@code "android.service.chooser.chooser_target_service"} en el manifiesto de su aplicación.
+
+Esta versión preliminar proporciona una nueva API de interacción de voz que, junto con las
+acciones de voz,
+le permite compilar experiencias de conversaciones de voz en sus aplicaciones. Llame al método
+{@code android.app.Activity.isVoiceInteraction()} para determinar si su actividad se inició en respuesta a una acción de voz.
+ De ser así, su aplicación puede utilizar la clase
+{@code android.app.VoiceInteractor} para solicitar una confirmación de voz por parte del usuario, realizar una selección de una lista de opciones y mucho más.
+ Para obtener más información sobre cómo implementar acciones de voz, consulte el
+sitio para desarrolladores de acciones de voz.
+
+Esta versión preliminar ofrece una nueva manera para que los usuarios interactúen con sus aplicaciones a través de un asistente. Si desea utilizar esta característica, el usuario debe habilitar el asistente para utilizar el contexto actual.
+ Una vez habilitado, para invocar al asistente dentro de cualquier aplicación, el usuario debe mantener presionado el botón Home.
+ Su aplicación puede optar por no compartir el contexto actual con el asistente al configurar la marca
+{@link android.view.WindowManager.LayoutParams#FLAG_SECURE}. Además del conjunto de información estándar que la plataforma le pasa al asistente, su aplicación puede compartir información adicional usando la nueva clase {@code android.app.Activity.AssistContent}.
+
+ Para proporcionarle al asistente contexto adicional desde su aplicación, siga estos pasos: Esta versión preliminar agrega los siguientes cambios de API para las notificaciones: Esta versión preliminar ofrece soporte mejorado para las entradas de usuarios que utilizan un lápiz Bluetooth. Los usuarios pueden sincronizar y conectar un lápiz Bluetooth compatible con su teléfono o tablet.
+ Mientras está conectado, la información de posición de la pantalla táctil se fusiona con la información de los botones y la presión del lápiz para proporcionar una mayor variedad de expresiones que al utilizar la pantalla táctil solamente.
+
+ Su aplicación puede obedecer cuando se presiona el botón del lápiz y cuando se realizan acciones secundarias al registrar las nuevas devoluciones de llamadas
+{@code View.onStylusButtonPressListener} y {@code GestureDetector.OnStylusButtonPressListener}
+en su actividad.
+ Utilice las constantes y los métodos {@link android.view.MotionEvent} para detectar las interacciones del botón del lápiz:
+
+Si su aplicación realiza exploraciones de Bluetooth de bajo consumo, puede utilizar el nuevo método
+{@code android.bluetooth.le.ScanSettings.Builder.setCallbackType()} para especificar que usted desea que las devoluciones de llamadas se notifiquen solo cuando se encuentre por primera vez un paquete de anuncio que coincida con el conjunto
+{@link android.bluetooth.le.ScanFilter} y cuando no se vea durante un período determinado.
+
+ Este enfoque de exploración es más eficaz en cuanto al consumo de energía que la que se proporciona en la versión anterior de la plataforma.
+
+
+Esta versión preliminar agrega soporte para la especificación de Hotspot 2.0 versión 1 en los dispositivos Nexus 6 y Nexus 9. Para proveer credenciales de Hotspot 2.0 en su aplicación, use los métodos nuevos de la clase
+{@link android.net.wifi.WifiEnterpriseConfig}, como {@code setPlmn()} y
+{@code setRealm()}.
+ En el objeto {@link android.net.wifi.WifiConfiguration}, puede configurar los campos
+{@link android.net.wifi.WifiConfiguration#FQDN} y {@code providerFriendlyName}. La nueva propiedad {@code ScanResult.PasspointNetwork} indica si una red detectada representa un punto de acceso de Hotspot 2.0.
+
+
+ Ahora, la plataforma permite que las aplicaciones soliciten que la resolución de pantalla se actualice a una representación 4K en el hardware compatible.
+ Para consultar la resolución física actual, use las nuevas API
+{@code android.view.Display.Mode}. Si la UI se establece en una resolución lógica más baja y se aumenta a una resolución física más alta, tenga en cuenta que la resolución física que devuelve el método
+{@code Display.Mode.getPhysicalWidth()} puede ser diferente de la resolución lógica informada por {@link android.view.Display#getSize(android.graphics.Point) getSize()}.
+
+ Puede pedirle al sistema que cambie la resolución física en su aplicación mientras se ejecuta y, para ello, debe configurar la propiedad {@code WindowManager.LayoutParams.preferredDisplayModeId} de la ventana de su aplicación.
+ Esta característica resulta útil si desea cambiar a la resolución de pantalla 4K.
+ Mientras se encuentra en el modo de pantalla 4K, la UI se continúa representando en la resolución original (como 1080p) y se aumenta a 4K, pero los objetos
+{@link android.view.SurfaceView} pueden mostrar contenido en la resolución nativa.
+ Ahora, los atributos de tema se admiten en
+{@link android.content.res.ColorStateList} para los dispositivos que ejecutan la versión preliminar de Android M. Los métodos
+{@link android.content.res.Resources#getColorStateList(int) getColorStateList()} y
+{@link android.content.res.Resources#getColor(int) getColor()} se dejaron de usar. Si desea llamar a estas API, en su lugar, llame a los métodos nuevos {@code Context.getColorStateList()} o
+{@code Context.getColor()}.
+ Estos métodos también se encuentran disponibles en la biblioteca AppCompat v4 vía {@link android.support.v4.content.ContextCompat}.
+ Esta versión preliminar agrega mejoras al procesamiento de audio en Android, lo que incluye lo siguiente: Esta versión preliminar agrega nuevas capacidades a las API de procesamiento de video, entre ellas, las siguientes: Esta versión preliminar incluye las siguientes API nuevas para acceder a la luz de flash de la cámara y para el reprocesamiento de imágenes de la cámara:
+ Si un dispositivo de cámara cuenta con una unidad de flash, puede llamar al método {@code CameraManager.setTorchMode()}
+para activar o desactivar el modo linterna de una unidad de flash sin abrir el dispositivo de cámara. La aplicación no tiene propiedad exclusiva de la unidad de flash ni del dispositivo de cámara.
+ El modo linterna se desactiva y deja de estar disponible cuando la cámara no se encuentra disponible o cuando otros recursos de la cámara que mantienen la linterna encendida dejan de estar disponibles.
+
+ Otras aplicaciones también pueden llamar a {@code setTorchMode()}
+para desactivar el modo linterna. Cuando se cierra la última aplicación que activó el modo linterna, este modo se desactiva.
+ Si desea registrar una devolución de llamada para recibir una notificación sobre el estado del modo linterna, llame al método
+{@code CameraManager.registerTorchCallback()}. La primera vez que se registra la devolución de llamada, se llama inmediatamente con el estado del modo linterna de todos los dispositivos de cámara que se conocen actualmente y que tengan una unidad de flash.
+
+ Si el modo linterna se activa o desactiva correctamente, se invoca al método
+{@code CameraManager.TorchCallback.onTorchModeChanged()}. La API {@link android.hardware.camera2 Camera2} se extiende para admitir el reprocesamiento de imágenes privadas de formato opaco y YUV.
+ Su aplicación determina si las capacidades de reprocesamiento se encuentran disponibles vía {@code CameraCharacteristics.REQUEST_AVAILABLE_CAPABILITIES}.
+ Si un dispositivo admite el reprocesamiento, usted puede crear una sesión de captura de cámara reprocesable llamando a
+{@code CameraDevice.createReprocessableCaptureSession()} y puede crear solicitudes para el reprocesamiento de búferes de entrada.
+
+ Utilice la clase {@code ImageWriter} para conectar el flujo del búfer de entrada a la entrada de reprocesamiento de la cámara.
+ Para obtener un búfer vacío, siga el modelo de programación que se indica a continuación: Si está utilizando un objeto {@code ImageWriter} junto con una imagen
+{@code android.graphics.ImageFormat.PRIVATE}, su aplicación no puede acceder a los datos de la imagen de forma directa.
+ En cambio, pase la imagen {@code ImageFormat.PRIVATE} directamente a
+{@code ImageWriter} llamando al método {@code ImageWriter.queueInputImage()} sin ninguna copia del búfer.
+ La clase {@code ImageReader} ahora admite secuencias de imagen de formato {@code android.graphics.ImageFormat.PRIVATE}.
+ Este soporte le permite que su aplicación mantenga una cola de imagen circular de imágenes de salida
+{@code ImageReader}, seleccione una o más imágenes y las envíe a
+{@code ImageWriter} para el reprocesamiento de la cámara. Esta versión preliminar incluye las siguientes API nuevas para Android for Work: Además, al configurar las restricciones de la aplicación en los servicios de Google Play, los propietarios de dispositivos pueden especificar cuentas de Google alternativas para desbloquear la FRP y reemplazar las que se encuentran activadas en el dispositivo.
+ Un propietario de dispositivo o perfil puede configurar una directiva de permisos para todas las solicitudes de tiempo de ejecución de todas las aplicaciones que utilizan
+{@code DevicePolicyManager.setPermissionPolicy()}, a fin de pedirle confirmación al usuario para conceder el permiso de manera normal, o bien, para conceder o negar el permiso automáticamente sin notificarlo.
+
+ Si se configura la última directiva, el usuario no puede modificar la selección realizada por el propietario de dispositivo o perfil dentro de la pantalla de permisos de la aplicación en Settings.
+
+
+ Para obtener una vista detallada de todos los cambios de la API en M Developer Preview, consulte el Informe de diferencias de las API.
+ 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:Contenido del documento
+
+ mostrar más
+
+
+
+
+Diferencias de las API
+
+
+Importantes cambios en los comportamientos
+
+Vinculación de la aplicación
+Copia de seguridad automática para aplicaciones
+Autenticación
+Autenticación por huellas dactilares
+
+
+<uses-permission
+ android:name="android.permission.USE_FINGERPRINT" />
+
+
+
+
+
+
+
+
+adb -e emu finger touch <finger_id>
+
+Confirmar credencial
+Compartir de forma directa
+
+
+
+
+Clase {@code chooser.ChooserTargetService}. Declare su
+{@code ChooserTargetService} en el manifiesto. En esa declaración, especifique el permiso
+{@code BIND_CHOOSER_TARGET_SERVICE} y un filtro de intento con la acción
+{@code SERVICE_INTERFACE}.
+<service android:name=".ChooserTargetService"
+ android:label="@string/service_name"
+ android:permission="android.permission.BIND_CHOOSER_TARGET_SERVICE">
+ <intent-filter>
+ <action android:name="android.service.chooser.ChooserTargetService" />
+ </intent-filter>
+</service>
+
+
+
+<activity android:name=".MyShareActivity”
+ android:label="@string/share_activity_label">
+ <intent-filter>
+ <action android:name="android.intent.action.SEND" />
+ </intent-filter>
+<meta-data
+ android:name="android.service.chooser.chooser_target_service"
+ android:value=".ChooserTargetService" />
+</activity>
+
+
+Interacciones de voz
+Asistencia de API
+
+
+
+Notificaciones
+
+
+
+Compatibilidad del lápiz Bluetooth
+
+
+
+Exploración mejorada de Bluetooth de bajo consumo
+Soporte de Hotspot 2.0 versión 1
+Modo de pantalla 4K
+ColorStateLists para poder aplicar temas
+Características de audio
+
+
+
+
+Características de video
+
+
+
+Características de la cámara
+API para luz de flash
+API de reprocesamiento
+
+
+
+Características de Android for Work
+
+
+
+
+
+
+
+
+Contenido del documento
+
+
+
+Diferencias de las API
+
+
+
+Consulte también
+
+
+Permisos de tiempo de ejecución
+
Optimizaciones de ahorro de energía
+Doze
+
+
+
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:
++ M Developer Preview introduce un nuevo modelo de permisos de la aplicación que facilita a los usuarios el proceso de instalación y actualización de aplicaciones. + Si una aplicación que se ejecuta en la versión preliminar de Android M es compatible con el nuevo modelo de permisos, el usuario no tiene que conceder ningún permiso al instalar o actualizar la aplicación. En su lugar, la aplicación solicitará los permisos a medida que los vaya necesitado y el sistema mostrará al usuario un diálogo en el que le solicitará los permisos necesarios. + + + + +
+ ++ Si la aplicación es compatible con el nuevo modelo de permisos, podrá instalarse y ejecutarse en los dispositivos con versiones anteriores de Android, utilizando el modelo de permisos anterior en esos dispositivos. + + +
+ ++ En M Developer Preview, la plataforma introduce un nuevo modelo +de permisos de la aplicación. A continuación, se presenta un resumen de los componentes principales de este nuevo modelo: +
+ +CONTACTS contiene permisos para leer y escribir los contactos y la información de perfil del usuario.
+
+ Permisos limitados concedidos durante la instalación: Cuando el usuario instala o actualiza la aplicación, el sistema le concede a la aplicación todos los permisos que la aplicación solicita que corresponden a {@link + android.content.pm.PermissionInfo#PROTECTION_NORMAL PROTECTION_NORMAL}. + + + Por ejemplo, los permisos para la alarma y los permisos de intento corresponden a {@link + android.content.pm.PermissionInfo#PROTECTION_NORMAL PROTECTION_NORMAL}, por lo que se conceden automáticamente durante la instalación. + +
+ +El sistema puede concederle a la aplicación permisos de firma y de sistema, como se especifica en la sección Permisos de firma y de sistema de la aplicación. + + Al usuario no se le solicitará conceder ningún permiso durante la instalación. +
++ Este modelo de permisos cambia la forma en la que la aplicación se comporta para características que requieren permisos. + A continuación, se presenta un resumen de las prácticas de desarrollo que debe seguir para ajustarse a este modelo: + +
+ +
+ + Figura 1 Pantalla de permisos en Settings de la aplicación. +
++ Nota: Si una aplicación tiene como destino M Developer Preview, debe utilizar el nuevo modelo de permisos. + +
+ ++ A partir del lanzamiento de M Developer Preview, no todas las aplicaciones de Google implementarán por completo el nuevo modelo de permisos. + Google actualiza estas aplicaciones durante el transcurso de M Developer Preview para respetar adecuadamente las configuraciones de alternancia de los permisos. + + +
+ ++ Nota: Si la aplicación cuenta con su propia superficie de API, no transmita permisos sin antes asegurarse de que el iniciador de la llamada cuente con los permisos requeridos para acceder a esa información. + + +
+ ++ Generalmente, cuando el usuario instala una aplicación, el sistema solo otorga a la aplicación +{@link android.content.pm.PermissionInfo#PROTECTION_NORMAL + PROTECTION_NORMAL}. Sin embargo, en ciertas circunstancias, el sistema le concede a la aplicación más permisos: + +
+ ++ En ambos casos, el usuario aún puede revocar los permisos en cualquier momento si accede a la pantalla Settings del sistema y selecciona Apps > + + app_name > Permissions. La aplicación debe seguir controlando los permisos al momento de la ejecución y solicitarlos si fuese necesario. + + +
+ ++ Si una aplicación no tiene como destino M Developer Preview, la aplicación continúa utilizando el modelo de permisos anterior, incluso en dispositivos con la versión preliminar de Android M. + Cuando el usuario instala la aplicación, el sistema le solicita al usuario que otorgue todos los permisos enumerados en el manifiesto de la aplicación. + + +
+ ++ Nota: En dispositivos que ejecutan M Developer Preview, el usuario puede desactivar los permisos para cualquier aplicación (incluso para aplicaciones heredadas) desde la pantalla Settings de la aplicación. + + Si un usuario desactiva permisos para una aplicación heredada, el sistema desactiva las funciones correspondientes de forma automática. + Cuando la aplicación intenta realizar una operación que requiere ese permiso, la operación no generará necesariamente una excepción. + + En su lugar, devolverá un conjunto de datos vacíos, indicará un error o, de lo contrario, mostrará un comportamiento inesperado. + Por ejemplo, si realiza una consulta sobre el calendario sin permisos, el método devuelve un conjunto de datos vacíos. + +
+ ++ Si instala una aplicación que utiliza el nuevo modelo de permisos en un dispositivo que no ejecuta la versión preliminar de Android M, el sistema la trata como cualquier otra aplicación: el sistema le pide al usuario, durante la instalación, que conceda los permisos declarados. + + + +
+ ++ Nota: Para el lanzamiento de la versión preliminar, debe configurar la versión mínima del SDK en M Preview SDK para compilar con la versión del SDK preliminar. + Esto significa que no podrá probar dichas aplicaciones en plataformas anteriores durante la versión preliminar para desarrolladores. + + +
+ ++ En muchas situaciones, puede elegir entre dos formas para que sus aplicaciones realicen una tarea. + Puede hacer que su aplicación solicite permiso para realizar la operación por sí misma. + De lo contrario, puede hacer que la aplicación utilice un intento para que otra aplicación realice la tarea. + +
+ +
+ Por ejemplo, supongamos que su aplicación necesita poder tomar fotografías con la cámara del dispositivo.
+ Su aplicación puede solicitar el permiso
+android.permission.CAMERA, lo que le permite a su aplicación acceder a la cámara directamente.
+ Entonces, su aplicación utilizará las API de la cámara para controlar la cámara y tomar una fotografía.
+ Este enfoque le otorga a su aplicación total control del proceso de fotografía y le permite incorporar la UI de la cámara en su aplicación.
+
+
+
+ Sin embargo, si no necesita dicho control, puede utilizar {@link + android.provider.MediaStore#ACTION_IMAGE_CAPTURE ACTION_IMAGE_CAPTURE} para solicitar una imagen. + Cuando ejecute el intento, se le solicita al usuario que elija una aplicación de cámara (en caso de que no haya una aplicación de cámara predeterminada) y esa aplicación tomará la fotografía. + + La aplicación de cámara devuelve la fotografía al método {@link + android.app.Activity#onActivityResult onActivityResult()} de su aplicación. +
+ ++ De manera similar, si necesita realizar una llamada telefónica, acceder a los contactos del usuario, etc., lo puede hacer creando intentos apropiados o puede solicitar los permisos e ingresar directamente a los objetos apropiados. + + Cada enfoque tiene ventajas y desventajas. + +
+ ++ Si utiliza los permisos: +
+ ++ Si utiliza un intento: +
+ ++ Si su aplicación tiene como destino el nuevo M Developer Preview, deberá usar el nuevo modelo de permisos. + Esto significa que, además de declarar los permisos necesarios en el manifiesto, también debe comprobar si tiene los permisos de tiempo de ejecución y solicitarlos en caso de no tenerlos. + + + +
+ +
+ Para habilitar el nuevo modelo de permisos de M Developer Preview, configure el atributo
+targetSdkVersion de la aplicación en "MNC" y
+compileSdkVersion en "android-MNC". Al hacerlo, se habilitan todas las características de los nuevos permisos.
+
+
+ Para el lanzamiento de la versión preliminar, debe establecer minSdkVersion en
+"MNC" para compilar con el SDK preliminar.
+
+ Puede utilizar el nuevo elemento <uses-permission-sdk-m> en el manifiesto de la aplicación para indicar que se necesita un permiso solo para M Developer Preview.
+ Si declara un permiso de esta manera, cuando la aplicación se instale en un dispositivo anterior, el sistema no le solicitará al usuario el permiso ni se lo otorgará a la aplicación. Al usar el elemento <uses-permission-sdk-m>, puede añadir nuevos permisos a las versiones actualizadas de su aplicación sin forzar a los usuarios a otorgar permisos cuando instalen la actualización.
+
+
+
+
+
+
+
+ Si la aplicación se ejecuta en un dispositivo con M Developer Preview,
+<uses-permission-sdk-m> se comporta al igual que
+<uses-permission>.
+ El sistema no le solicita al usuario que otorgue ningún permiso al instalar la aplicación y la aplicación solicita los permisos a medida que se necesiten.
+
+
+ Si su aplicación utiliza el nuevo modelo de permisos de M Developer Preview, no se le pedirá al usuario que otorgue todos los permisos cuando la aplicación se ejecute por primera vez en un dispositivo con la versión preliminar de Android M. + + En su lugar, su aplicación solicita los permisos a medida que los necesita. + Cuando su aplicación solicita un permiso, el sistema le muestra un diálogo al usuario. + +
+ +
+ Si su aplicación se ejecuta en un dispositivo con SDK 22 o anterior, la aplicación utiliza el modelo de permisos anterior.
+ Cuando el usuario instala la aplicación, se le solicita que otorgue todos los permisos que la aplicación requiere en su manifiesto, excepto aquellos permisos marcados con <uses-permission-sdk-m>.
+
+
+
+ Este modelo de permisos es compatible solamente con dispositivos que ejecutan M Developer Preview.
+ Antes de llamar a cualquiera de estos métodos, la aplicación debe verificar en qué plataforma se está ejecutando y, para hacerlo, se controla el valor de {@link android.os.Build.VERSION#CODENAME
+ Build.VERSION.CODENAME}.
+
+ Si el dispositivo ejecuta M Developer Preview,
+{@link android.os.Build.VERSION#CODENAME CODENAME} es "MNC".
+
Cuando el usuario intenta realizar algo que requiere un permiso, la aplicación controla si ya tiene el permiso para realizar esa operación.
+ Para hacerlo, la aplicación llama a Context.checkSelfPermission(
+
+permission_name). La aplicación debe realizar este control incluso si sabe que el usuario ya ha concedido ese permiso, ya que el usuario puede revocar los permisos de una aplicación en cualquier momento.
+
+
+ Por ejemplo, si un usuario quiere usar una aplicación para tomar una fotografía, la aplicación llama a Context.checkSelfPermission(Manifest.permission.CAMERA).
+
+
+ Tabla 1. Permisos y grupo de permisos.
+| Grupo de permisos | +Permisos | +
|---|---|
android.permission-group.CALENDAR |
+
+
|
+
android.permission-group.CAMERA |
+
+
|
+
android.permission-group.CONTACTS |
+
+
|
+
android.permission-group.LOCATION |
+
+
|
+
android.permission-group.MICROPHONE |
+
+
|
+
android.permission-group.PHONE |
+
+
|
+
android.permission-group.SENSORS |
+
+
|
+
android.permission-group.SMS |
+
+
|
+
Si la aplicación no posee los permisos que necesita, llama al método
+Activity.requestPermissions(String[], int) para solicitar el permiso o los permisos apropiados.
+ La aplicación pasa el permiso o los permisos que necesita y un “código de solicitud” entero.
+
+ Este método funciona de manera asincrónica: realiza la devolución inmediatamente y cuando el usuario responde a la ventana de diálogo, el sistema llama al método de devolución de llamada de la aplicación con los resultados, y pasa el mismo “código de solicitud” que pasó la aplicación a
+requestPermissions().
+
+
El siguiente código verifica si la aplicación tiene permisos para leer los contactos del usuario y solicita los permisos de ser necesario: +
+ +
+if (checkSelfPermission(Manifest.permission.READ_CONTACTS)
+ != PackageManager.PERMISSION_GRANTED) {
+ requestPermissions(new String[]{Manifest.permission.READ_CONTACTS},
+ MY_PERMISSIONS_REQUEST_READ_CONTACTS);
+
+ // MY_PERMISSIONS_REQUEST_READ_CONTACTS is an
+ // app-defined int constant
+
+ return;
+}
+
+
+
+ Cuando una aplicación solicita permisos, el sistema le muestra al usuario una ventana de diálogo.
+ Cuando el usuario responde, el sistema invoca
+Activity.onRequestPermissionsResult(int, String[], int[])
+ de su aplicación y le transfiere la respuesta del usuario. Su aplicación necesita invalidar ese método. La devolución de llamada pasa el mismo código de solicitud que usted pasó a requestPermissions().
+
+ Por ejemplo, si una aplicación solicita acceso READ_CONTACTS, es posible que tenga el siguiente método de devolución de llamada:
+
+
+
+@Override
+public void onRequestPermissionsResult(int requestCode,
+ String permissions[], int[] grantResults) {
+ switch (requestCode) {
+ case MY_PERMISSIONS_REQUEST_READ_CONTACTS: {
+ if (grantResults[0] == PackageManager.PERMISSION_GRANTED) {
+
+ // permission was granted, yay! do the
+ // calendar task you need to do.
+
+ } else {
+
+ // permission denied, boo! Disable the
+ // functionality that depends on this permission.
+ }
+ return;
+ }
+
+ // other 'switch' lines to check for other
+ // permissions this app might request
+ }
+}
+
+
+ Si el usuario concede un permiso, el sistema le otorga a la aplicación todos los permisos enumerados en el manifiesto para esa área funcional. + Se deben tomar acciones apropiadas si el usuario rechaza la solicitud. + Por ejemplo, usted podría desactivar cualquier acción del menú que dependa de este permiso. + + +
+ +
+ Cuando el sistema le solicita al usuario que otorgue un permiso, el usuario tiene la opción de indicarle al sistema que no solicite ese permiso de nuevo.
+ En ese caso, cuando la aplicación utiliza requestPermissions() para solicitar ese permiso, el sistema rechaza la solicitud inmediatamente.
+
+ En este caso, el sistema llama a su onRequestPermissionsResult() de la misma manera en que lo haría si el usuario hubiese rechazado explícitamente su solicitud nuevamente.
+
+ Por esta razón, su aplicación no puede asumir que se ha llevado a cabo algún tipo de interacción con el usuario.
+
+
+ Si su aplicación tiene como destino M Developer Preview, debe probar que administre los permisos correctamente. + No debe asumir que su aplicación tiene algún permiso en particular cuando se ejecuta. + Cuando la aplicación se ejecuta por primera vez, es muy probable que no tenga permisos y el usuario puede revocar o reestablecer los permisos en cualquier momento. + + +
+ ++ Debe probar su aplicación para asegurarse de que funciona correctamente en todas las situaciones de permisos. + Con el SDK de la versión preliminar de Android M, hemos brindado nuevos comandos Android Debug Bridge (adb) que le permitirán probar su aplicación con cualquier configuración de permisos que necesite probar. + + + +
+ ++ Las herramientas de plataforma del SDK de la versión preliminar de Android M contienen varios comandos nuevos que le permiten probar la manera en que su aplicación administra los permisos. + +
+ +
+ Puede utilizar la nueva opción -g del comando adb
+ install, que instala la aplicación y concede todos los permisos enumerados en el manifiesto de la aplicación:
+
+
+$ adb install -g <path_to_apk> ++ +
+ Puede utilizar los comandos ADB nuevos package manager (pm) para conceder y revocar permisos a una aplicación instalada. Esta funcionalidad puede resultar útil para pruebas automáticas. + + +
+ +
+ Para conceder un permiso, utilice el comando grant de package manager:
+
+$ adb pm grant <package_name> <permission_name> ++ +
+ Por ejemplo, para conceder el paquete de permisos com.example.myapp para grabar audio utilice este comando: + +
+ ++$ adb pm grant com.example.myapp android.permission.RECORD_AUDIO ++ +
+ Para revocar un permiso, utilice el comando revoke de package manager:
+
+$ adb pm revoke <package_name> <permission_name> ++ +
+ El nuevo modelo de permisos brinda a los usuarios una experiencia más fluida y les facilita la instalación de aplicaciones, además de hacerlos sentir cómodos con las actividades de sus aplicaciones. + + Sugerimos las siguientes mejores prácticas para obtener el mayor beneficio del nuevo modelo. + +
+ + ++ Cada vez que solicite un permiso, usted obliga al usuario a tomar una decisión. + La funcionalidad de su aplicación se verá reducida si el usuario rechaza la solicitud. + Debe minimizar la cantidad de veces que realiza estas solicitudes. +
+ ++ Por ejemplo, a menudo, su aplicación puede obtener la funcionalidad necesaria a través de un intento en lugar de una solicitud de permiso. + + Si su aplicación necesita tomar fotografías con la cámara del teléfono, la aplicación puede utilizar un intento {@link + android.provider.MediaStore#ACTION_IMAGE_CAPTURE + MediaStore.ACTION_IMAGE_CAPTURE}. + Cuando su aplicación ejecuta el intento, el sistema le solicita al usuario que elija una aplicación para la cámara que ya está instalada a fin de tomar la fotografía. + + +
+ ++ Si expone al usuario a muchas solicitudes de permisos al mismo tiempo, lo abrumará y hará que deje de usar su aplicación. Por el contrario, debe pedir permisos en la medida que los necesite. + + +
+ ++ A veces, uno o más permisos pueden ser absolutamente necesarios para la aplicación. En ese caso, es recomendable pedir todos los permisos no bien se inicie la aplicación. + + Por ejemplo, si crea una aplicación de fotografía, la aplicación necesitará acceso a la cámara del dispositivo. + Cuando el usuario inicie la aplicación por primera vez, no se sorprenderá si la aplicación le solicita permiso para usar la cámara. + + Sin embargo, si la misma aplicación además tuviese una característica para compartir fotografías con los contactos del usuario, no solicite ese permiso la primera vez que se ejecute. + + En su lugar, espere hasta que el usuario utilice la característica “compartir” para solicitar el permiso en ese momento. + +
+ ++ Si su aplicación proporciona un tutorial, se recomienda que se pidan los permisos esenciales de la aplicación al final del tutorial. + +
+ +
+ El diálogo de permisos que muestra el sistema cuando llama a
+ requestPermissions() informa qué permisos necesita su aplicación pero no establece el motivo.
+ A veces, el usuario puede confundirse.
+ Es una buena idea explicarle al usuario los motivos por los que la aplicación necesita esos permisos antes de llamar a requestPermissions().
+
+
+ Por ejemplo, una aplicación de fotografía puede solicitar servicios de ubicación para añadir una etiqueta geográfica a las fotografías.
+ Es posible que un usuario típico no sepa que una fotografía puede contener información sobre la ubicación y se confundiría si una aplicación de fotografía solicita la ubicación.
+
+ En este caso, es recomendable que la aplicación le informe al usuario acerca de esta característica antes de llamar a
+requestPermissions().
+
+
+ Una forma de hacerlo es incorporar estas solicitudes en el tutorial de la aplicación. El tutorial puede mostrar todas las características de la aplicación, una por vez, y mientras lo hace explicar los permisos que son necesarios.
+
+ Por ejemplo, el tutorial de la aplicación de fotografía puede mostrar la característica “compartir fotografías con contactos” y luego explicarle al usuario que debe otorgar permisos para que la aplicación vea los contactos del usuario.
+
+
+ La aplicación puede entonces llamar a requestPermissions() para solicitarle al usuario ese acceso.
+ Por supuesto, no todos los usuarios siguen el tutorial, por lo que aun así debe controlar y solicitar los permisos durante el funcionamiento normal de la aplicación.
+
+
+
+ Bienvenido a Android M Developer Preview, el programa que le brinda todo lo que necesita para probar y optimizar sus aplicaciones para la próxima versión de Android. + + Es gratis y puede comenzar a utilizarlo ahora mismo. Solo tiene que descargar las herramientas de M Developer Preview. + +
+ ++ Ejecute y pruebe sus aplicaciones en Nexus 5, 6, 9 y Player (para TV), además del emulador. + +
++ Durante la versión preliminar, ofreceremos múltiples actualizaciones, por lo que usted realizará la prueba comparando los últimos cambios de la plataforma. + +
++ Luego de actualizar su dispositivo a la versión preliminar inicial, usted podrá obtener actualizaciones por red inalámbrica (over-the-air, OTA). + +
++ Inicie el funcionamiento con anticipación para admitir los comportamientos de la nueva plataforma como el nuevo modelo de permisos de tiempos de ejecución y las opciones de ahorro de energía. + +
++ Durante las primeras semanas, daremos prioridad a los problemas informados por los desarrolladores; por lo tanto, realice las pruebas y envíe sus comentarios lo antes posible. + +
++ Infórmenos los problemas y envíenos comentarios a través de nuestro seguimiento de problemas. + Póngase en contacto con otros desarrolladores de la comunidad M Developer Community. + +
+
++ M Developer Preview estará disponible a partir del 28 de mayo hasta la versión final del SDK de Android M, que lanzaremos al poco tiempo del lanzamiento público durante el tercer trimestre de 2015. + + +
+ ++ En momentos clave del desarrollo, lanzaremos actualizaciones para sus dispositivos de prueba. + Los momentos clave tentativos son los siguientes: +
+ ++ Estas actualizaciones terminan con el SDK final (más adelante durante el tercer trimestre), lo que proporcionará tanto las API oficiales para la nueva versión de Android como los comportamientos y las características finales del sistema. + + +
+ ++ A medida que usted prueba y desarrolla en Android M, le recomendamos que mantenga su entorno de desarrollo actualizado a medida que se lanzan las actualizaciones de la versión preliminar. + + Para que el proceso sea más fácil, lanzaremos actualizaciones OTA para los dispositivos que ya hayan sido actualizados a una compilación de la versión preliminar y brindaremos imágenes del sistema que puede descargar y actualizar manualmente. + + +
++ Nota: El SDK final y las imágenes del sistema no se pueden proporcionar vía OTA y deberán actualizarse manualmente en sus dispositivos de prueba. + + +
+ ++ Le informaremos cuando las actualizaciones de la versión preliminar se encuentren disponibles a través del blog de Android para desarrolladores (Android Developers Blog), de este sitio y de la comunidad de desarrolladores Android M Developer Community. + + +
+ ++ M Developer Preview incluye todo lo que necesita para probar sus aplicaciones actuales en una variedad de tamaños de pantalla, de tecnologías de redes, de conjuntos de chip CPU/GPU y de arquitecturas de hardware. + + +
+ ++ Estos componentes se pueden descargar mediante SDK Manager en Android Studio: +
+ ++ Puede descargar estas imágenes del sistema de hardware para dispositivos Nexus desde la página de Descargas: + +
+ ++ Estos recursos de documentación lo ayudan a obtener información sobre la versión preliminar: +
+ ++ Utilice los siguientes recursos de soporte durante el proceso de prueba y desarrollo en M Developer Preview: + +
+ +
+ Android M Developer Preview es una versión solo para desarrollo y no tiene un nivel de API estándar.
+ Si quiere darse de baja de los comportamientos de compatibilidad para probar su aplicación (lo que es muy recomendado), puede elegir como destino M Developer Preview estableciendo targetSdkVersion de su aplicación como “MNC”.
+
+
+
+
+ Android M Developer Preview ofrece API preliminares + — las API no serán oficiales hasta que se lance el SDK final, lo que actualmente está planeado para el tercer trimestre de 2015. + Esto quiere decir que surgirán cambios menores en la API con el tiempo, particularmente durante las primeras semanas del programa. + + Con cada actualización de Android M Developer Preview, proporcionaremos un resumen con los cambios realizados. + +
+ ++ Tenga en cuenta que aunque las API preliminares pueden modificarse, los comportamientos del sistema subyacente, como los permisos de tiempo de ejecución y las opciones de ahorro de energía, se mantienen estables y disponibles para cualquier prueba inmediata. + + +
+ ++ En cuanto a la publicación, Google Play no permite que se publiquen aplicaciones que tienen como destino M Developer Preview. + Una vez que el SDK final de Android M esté disponible, podrá seleccionar como destino el nivel de API oficial de Android M y publicar su aplicación en Google Play. + + Mientras tanto, si desea distribuir una aplicación con Android M como destino a otros evaluadores, lo puede hacer por correo electrónico o mediante descarga directa desde su sitio. + + +
+ ++ Para comenzar a probar su aplicación: +
+ ++ ¡Agradecemos su participación en el programa Android M Developer Preview! +
diff --git a/docs/html-intl/intl/ja/preview/api-overview.jd b/docs/html-intl/intl/ja/preview/api-overview.jd new file mode 100644 index 0000000000000..2c0816b54605a --- /dev/null +++ b/docs/html-intl/intl/ja/preview/api-overview.jd @@ -0,0 +1,521 @@ +page.title=API の概要 +page.keywords=プレビュー,sdk,互換性 +page.tags=previewresources, androidm sdk.platform.apiLevel=22-mnc +page.image=images/cards/card-api-overview_16-9_2x.png +@jd:body + + + +M Developer Preview では、ユーザーやアプリ開発者に Android プラットフォームの次期リリースの新機能をいち早く試していただくことができます。 + +このドキュメントでは、いくつかの注目すべき API の概要について説明します。
+ +M Developer Preview は、Developer の早期導入者とテスターを対象としています。 +是非 +M Developer Preview を試してフィードバックをご提供ください。あなたのご意見が、Android フレームワークの方向性を決定する上で貴重な情報になります。 + +
+ +注意: M Developer Preview を使用したアプリは、Google Play ストアには公開しないでください。 +
+ +注: このドキュメントには、まだ developer.android.com のリファレンス マテリアルにないクラスやメソッドが多数登場します。 +このドキュメントでは、API エレメントは {@code code style} 形式で記載されています(ハイパーリンクなし)。 +これらのエレメントに関する API ドキュメント(準備段階)については、プレビューのリファレンスをダウンロードしてください。 +
+ +過去に Android にアプリを公開したことがある場合は、アプリがプラットフォームの変更による影響を受ける場合があります。 +
+ +詳細については、Behavior Changes をご覧ください。
+ +このプレビューでは、アプリのリンク機能を強化することで Android のインテント システムが向上しました。この機能では、所有するウェブドメインにアプリを関連付けることができます。 +この関連付けに基づいて、プラットフォームが特定のウェブリンクの処理に使用するデフォルトのアプリを決めることができ、ユーザーにアプリを選択させる操作をスキップできます。この機能の実装方法については、 +アプリのリンク機能をご覧ください。 + + + +
システムで、アプリの自動フルデータ バックアップと復元を実行できるようになりました。この動作は、M Preview を対象としたアプリでデフォルトで有効になっています。追加のコードは必要ありません。 +ユーザーが Google アカウントを削除すると、バックアップ データも削除されます。 +この機能の仕組みとファイル システムでバックアップ対象を設定する方法については、 +アプリの自動バックアップをご覧ください。 +
+ +このプレビューでは、サポートされる端末での指紋スキャンを使用したユーザー認証や、端末のロック解除メカニズム(ロック画面のパスワードなど)を使って最後にユーザーが認証された時期の確認などを行える新しい API が提供されます。 + +これらの API は、Android キーストローク システムと共に使用します。 +
+ +指紋スキャンでユーザーを認証するには、新しい +{@code android.hardware.fingerprint.FingerprintManager} クラスのインスタンスを取得して、 +{@code FingerprintManager.authenticate()} メソッドを呼び出します。アプリは、指紋センサー付きの、互換性のある端末上で実行している必要があります。 +指紋認証フローのユーザー インターフェースをアプリに実装し、UI には標準の Android 指紋アイコンを使用する必要があります。Android 指紋アイコン({@code c_fp_40px.png})はサンプルアプリに含まれています。指紋認証を使用するアプリを複数開発する場合は、それぞれのアプリで個別にユーザーの指紋を認証する必要があります。 + + + + +
+ +アプリでこの機能を使用するには、まずマニフェストに {@code USE_FINGERPRINT} パーミッションを追加する必要があります。 +
+ ++<uses-permission + android:name="android.permission.USE_FINGERPRINT" /> ++ +
+
+アプリでの指紋認証の実装については、 +指紋ダイアログのサンプルをご覧ください。 +
+ +この機能をテストする場合は、次の手順を使用します。
++adb -e emu finger touch <finger_id> ++
Windows では、{@code telnet 127.0.0.1 <emulator-id>}、 +{@code finger touch <finger_id>} の順に実行する必要がある場合があります。 +
+アプリでは、ユーザーがいつ、最後に端末のロックを解除したかに基づいて、ユーザーを認証できます。この機能によって、ユーザーがアプリ固有のパスワードを覚えたり、開発者が独自の認証ユーザー インターフェースを実装したりする必要性がなくなります。 + +アプリでこの機能を使用する場合は、ユーザー認証用の公開鍵か秘密鍵を実装する必要があります。 +
+ +ユーザーが正常に認証された後、同じキーを再使用できるタイムアウト期間を設定するには、{@link javax.crypto.KeyGenerator} か +{@link java.security.KeyPairGenerator} のセットアップ後に新しい +{@code android.security.keystore.KeyGenParameterSpec.setUserAuthenticationValidityDurationSeconds()} メソッドを呼び出します。 + +現在、この機能は対象暗号化操作で動作します。 +
+ +再認証ダイアログを過度に表示しないようにします。アプリでは、まず暗号オブジェクトを使用し、タイムアウトした場合は +{@link android.app.KeyguardManager#createConfirmDeviceCredentialIntent(java.lang.CharSequence, java.lang.CharSequence) createConfirmDeviceCredentialIntent()} メソッドを使用してユーザーをアプリ内で再認証するようにします。 + + +
+ +アプリでのこの機能の実装については、 +資格情報の確認サンプルをご覧ください。 +
+ +
+
+このプレビューでは、ユーザーが直感的にすばやく共有できるようにする API が提供されます。アプリで特定のアクティビティを起動するダイレクト シェアのターゲットを定義すると、それらのダイレクト シェアのターゲットは [共有] メニューに表示されるようになります。 + +この機能を使うと、他のアプリ内にある連絡先などのターゲットにコンテンツを共有できます。 +たとえば、ダイレクト シェアのターゲットによって他のソーシャル ネットワーク アプリのアクティビティが起動し、そのアプリ内の特定の友人やコミュニティに直接コンテンツを共有できるようになります。 + +
+ +ダイレクト シェアのターゲットを有効にするには、まず
+{@code android.service.} を拡張するクラスを定義する必要があります。
+{@code chooser.ChooserTargetService} クラス。マニフェストで
+{@code ChooserTargetService} を宣言します。その宣言内で、
+{@code BIND_CHOOSER_TARGET_SERVICE} パーミッションと、
+{@code SERVICE_INTERFACE} アクションを使ったインテント フィルタを指定します。
次の例は、マニフェストで {@code ChooserTargetService} を宣言する方法を示しています。 +
++<service android:name=".ChooserTargetService" + android:label="@string/service_name" + android:permission="android.permission.BIND_CHOOSER_TARGET_SERVICE"> + <intent-filter> + <action android:name="android.service.chooser.ChooserTargetService" /> + </intent-filter> +</service> ++ +
{@code ChooserTargetService} に公開するアクティビティごとに、 {@code "android.service.chooser.chooser_target_service"} という名前の +{@code <meta-data>} 要素をアプリのマニフェストに追加します。 + +
+ ++<activity android:name=".MyShareActivity” + android:label="@string/share_activity_label"> + <intent-filter> + <action android:name="android.intent.action.SEND" /> + </intent-filter> +<meta-data + android:name="android.service.chooser.chooser_target_service" + android:value=".ChooserTargetService" /> +</activity> ++ +
+このプレビューでは、音声アクションと共に使用することでアプリに対話形式の音声操作をビルドできる新しい音声インタラクション API が提供されます。 + + +{@code android.app.Activity.isVoiceInteraction()} メソッドを呼び出して、アクティビティが音声アクションへの応答として開始されたかどうかを確認します。 +音声アクションへの応答であった場合、アプリで +{@code android.app.VoiceInteractor} クラスを使用してユーザーに音声の確認や、オプションのリストからの選択などを要求できます。 +音声アクションの実装の詳細については、 +音声アクションの開発者サイトをご覧ください。 +
+ ++このプレビューでは、アシスタントを介してユーザーがアプリを操作できる新しい方法が用意されています。この機能を使用するには、ユーザーが現在のコンテキストを使うようアシスタントを有効にする必要があります。 +有効にすると、ホーム ボタンを長押しすることで、すべてのアプリ内でアシスタントを呼び出すことができます。 +
++{@link android.view.WindowManager.LayoutParams#FLAG_SECURE} フラグを設定すると、アプリが現在のコンテキストをアシスタントと共有しないようにできます。新しい {@code android.app.Activity.AssistContent} クラスを使用すると、プラットフォームがアシスタントに渡す標準的な情報セットの他に、アプリで追加の情報を共有できます。 + +
+ +アプリから追加のコンテキストをアシスタントに提供するには、次の手順を使用します。
+ +このプレビューでは、通知に関して次のような API の変更点が追加されています。
+このプレビューでは、Bluetooth スタイラスを使用したユーザー入力のサポートが強化されました。互換性のある Bluetooth スタイラスと電話やタブレットをペアリングして接続できます。 +接続されている間、タッチスクリーンからの位置情報とスタイラスからの筆圧やボタン情報を合わせることで、タッチスクリーン単独の場合よりも表現の幅が大きく広がります。 + +新しい +{@code View.onStylusButtonPressListener} コールバックと {@code GestureDetector.OnStylusButtonPressListener} コールバックをアクティビティに登録すると、スタイラスのボタンが押されたことをアプリがリッスンし、次のアクションを実行できるようになります。 + +
+ +スタイラスのボタン操作を検出するには、{@link android.view.MotionEvent} メソッドと定数を使用します。 +
++アプリで Bluetooth Low Energy スキャンを実行する場合は、新しい +{@code android.bluetooth.le.ScanSettings.Builder.setCallbackType()} メソッドを使って、設定された +{@link android.bluetooth.le.ScanFilter} に一致する宣伝パケットが最初に見つかったときと、それが長期間見つからない場合に通知する目的でのみコールバックが必要であると指定できます。 + +このスキャン アプローチは、以前のプラットフォーム バージョンで提供されていたものよりもはるかに効率的です。 + +
+ ++このプレビューでは、Nexus 6 と Nexus 9 端末のアクセス ポイント2.0 Release 1 仕様のサポートが追加されました。アクセス ポイント 2.0 の資格情報をアプリに提供するには、 +{@code setPlmn()} や {@code setRealm()} などの +{@link android.net.wifi.WifiEnterpriseConfig} クラスの新しいメソッドを使用します。 +{@link android.net.wifi.WifiConfiguration} オブジェクトで、 +{@link android.net.wifi.WifiConfiguration#FQDN} フィールドと {@code providerFriendlyName} フィールドを設定できます。新しい {@code ScanResult.PasspointNetwork} プロパティは、検出されたネットワークがアクセス ポイント 2.0 のアクセス ポイントを表しているかどうかを示します。 + + +
+ +互換性のあるハードウェアで、ディスプレイの解像度を 4K レンダリングにアップグレードするようアプリから要求できるようになりました。 +現在の物理的解像度を照会するには、新しい +{@code android.view.Display.Mode} API を使用します。UI が低い論理的解像度で描画されていて、より高い物理的解像度にアップスケールされた場合は、 +{@code Display.Mode.getPhysicalWidth()} メソッドが返す物理的解像度が {@link android.view.Display#getSize(android.graphics.Point) getSize()} で報告される論理的解像度と異なる場合があります。 + +
+ +アプリ ウィンドウの +{@code WindowManager.LayoutParams.preferredDisplayModeId} プロパティを設定することで、アプリの実行時に物理的解像度を変更するようシステムに要求できます。この機能は、4K ディスプレイの解像度に切り替えたい場合に便利です。 +4K ディスプレイ モード中、UI は引き続き元の解像度(1080p など)で表示され、4K にアップスケールされますが、 +{@link android.view.SurfaceView} オブジェクトではコンテンツをネイティブの解像度で表示する場合があります。 +
+ +M Preview を実行する端末で、テーマの属性が +{@link android.content.res.ColorStateList} でサポートされるようになりました。 +{@link android.content.res.Resources#getColorStateList(int) getColorStateList()} メソッドと +{@link android.content.res.Resources#getColor(int) getColor()} メソッドは廃止されました。これらの API を呼び出す場合は、代わりに新しい {@code Context.getColorStateList()} メソッドか +{@code Context.getColor()} メソッドを呼び出します。 +これらのメソッドは、{@link android.support.v4.content.ContextCompat} の v4 appcompat ライブラリにもあります。 +
+ +このプレビューでは、次のように Android でのオーディオ処理が改善されました。
+このプレビューでは、ビデオ処理の API に次のような新機能が追加されました。
+このプレビューでは、カメラのフラッシュやカメラによる画像の再処理にアクセスするための新しい API が用意されています。 +
+ +カメラ端末にフラッシュ ユニットが付属している場合は、{@code CameraManager.setTorchMode()} メソッドを呼び出すことで、カメラ端末を開かずにフラッシュ ユニットのタッチモードのオン/オフを切り替えることができます。 +アプリには、フラッシュ ユニットやカメラ端末のフラッシュの独占所有権はありません。 +トーチモードは、カメラ端末が利用不可になったときや、トーチを付けている他のカメラリソースが利用不可になったときにオフになり、利用できなくなります。 + +他のアプリでも {@code setTorchMode()} を呼び出してトーチモードをオフにできます。 +最後にトーチモードをオンにしたアプリが閉じられると、トーチモードはオフになります。 +
+ ++{@code CameraManager.registerTorchCallback()} メソッドを呼び出すことで、トーチモードの状態に関する通知を受けるようコールバックを登録できます。コールバックを初めて登録したときに、現在検知されているすべてのフラッシュ ユニット付きのカメラ端末のトーチモードの状態が即座に呼び出されます。 + +トーチモードが正常にオン/オフされると、 +{@code CameraManager.TorchCallback.onTorchModeChanged()} メソッドが呼び出されます。
+ +{@link android.hardware.camera2 Camera2} API は、YUV とプライベートな不透明形式の画像の再処理をサポートするよう拡張されました。 +アプリは、再処理機能が利用可能かどうかを {@code CameraCharacteristics.REQUEST_AVAILABLE_CAPABILITIES} 経由で確認します。 +端末が再処理をサポートしている場合は、 +{@code CameraDevice.createReprocessableCaptureSession()} を呼び出して再処理可能なカメラ撮影セッションを作成し、入力バッファの再処理の要求を作成できます。 + +
+ +入力バッファのフローをカメラの再処理入力に接続するには、{@code ImageWriter} クラスを使用します。 +空のバッファを取得するには、次のプログラミング モデルを使用します。
+ +{@code ImageWriter} オブジェクトを +{@code android.graphics.ImageFormat.PRIVATE} 画像と共に使用する場合、アプリから直接画像データにアクセスすることはできません。 +代わりに、{@code ImageWriter.queueInputImage()} メソッドをバッファコピーなしで呼び出して、{@code ImageFormat.PRIVATE} 画像を直接 +{@code ImageWriter} に渡します。 +
+ +{@code ImageReader} クラスで {@code android.graphics.ImageFormat.PRIVATE} 形式の画像ストリームがサポートされるようになりました。 +これにより、アプリが +{@code ImageReader} 出力画像の循環的な画像のキューを維持でき、1 つ以上の画像を選択して、それらをカメラの再処理用に +{@code ImageWriter} に送ることができます。
+ +このプレビューには、次のような Android for Work 用の新しい API が含まれています。
+さらに、Google Play サービスでアプリの制限を設定することで、デバイス オーナーは FRP のロック解除用の別の Google アカウントを指定して、端末でアクティベートされたアカウントを置き換えることができます。 +
+
+プロファイルやデバイス オーナーは、 +{@code DevicePolicyManager.setPermissionPolicy()} を使用するすべてのアプリケーションのすべての実行時の要求に対するパーミッション ポリシーを設定でき、通常のとおりユーザーにパーミッションを付与するよう要求する、自動的に付与する、パーミッションをサイレントに拒否する、のいずれかを行うことができます。 + +後者のポリシーが設定されている場合、ユーザーはプロファイルやデバイス オーナーによって選択された内容を [設定] にあるアプリのパーミッション画面で修正できません。 + +
+ M Developer Preview のすべての API の変更点の詳細については、API Differences Report をご覧ください。 +
diff --git a/docs/html-intl/intl/ja/preview/behavior-changes.jd b/docs/html-intl/intl/ja/preview/behavior-changes.jd new file mode 100644 index 0000000000000..a7950a1ad0d0d --- /dev/null +++ b/docs/html-intl/intl/ja/preview/behavior-changes.jd @@ -0,0 +1,402 @@ +page.title=動作の変更点 +page.keywords=プレビュー,sdk,compatibility +sdk.platform.apiLevel=MNC +@jd:body + +M Developer Preview には、新機能以外にもさまざまなシステムの変更点や API の動作の変更点が盛り込まれています。 +このドキュメントでは、アプリ開発において把握しておくべき主な変更点について説明します。 +
+ +過去に Android にアプリを公開したことがある場合は、アプリがこれらの変更による影響を受ける場合があることに注意してください。 +
+ +このプレビューでは、アプリのパーミッションを実行時にユーザーが直接管理できる新しいパーミッション モデルが採用されました。 +このモデルによって、ユーザーに対するパーミッションの可視性と制御性が向上し、アプリ開発者にとってはアプリのインストールや自動アップデート プロセスの効率が上がります。ユーザーはインストール済みアプリのパーミッションを個別に付与したり取り消したりできます。 + +
+ +M Preview を対象としたアプリでは、必ずパーミッションを実行時に確認、要求するようにします。 +アプリにパーミッションが付与されているかどうかを確認するには、新しい {@code Context.checkSelfPermission()} メソッドを呼び出します。 +パーミッションを要求するには、新しい +{@code Activity.requestPermission()} メソッドを呼び出します。アプリが M を対象としていない場合でも、新しいパーミッション モデルでアプリをテストするようにしてください。 +
+ +アプリで新しいパーミッションをサポートする際の詳細については、Developer Preview ページの +Permissions をご覧ください。 +アプリへの影響を評価する際のヒントについては、Testing Guide をご覧ください。 +
+ +このプレビューでは、アイドル中の端末やアプリに対する新しい省電力の最適化機能が採用されています。
+ +端末が電源に接続されておらず、画面が一定時間オフ状態の場合は Doze モードに入り、システムをスリープ状態に保ちます。 +このモードでは、端末は定期的に通常の操作を短時間再開することで、アプリを同期したり、システムが保留中の操作を行ったりすることができます。 + +
+ +Doze 中は、アプリに次の制限が適用されます。
+端末が Doze モードでなくなると、保留中のすべての同期とジョブが実行されます。
+この機能をテストするには、M Preview を実行する端末を開発マシンに接続して、次のコマンドを呼び出します。 + +
++$ adb shell dumpsys battery unplug +$ adb shell dumpsys deviceidle step +$ adb shell dumpsys deviceidle -h ++
注: +Google Cloud Messaging の次期リリースでは、高優先度のメッセージを指定できます。 + +アプリが高優先度の GCM メッセージを受信する場合は、端末が Doze 中でも短時間のネットワーク アクセスが付与されます。 + +
+ +アプリで Doze をテストする方法のヒントについては、 +Testing Guide をご覧ください。 +
+ +このプレビューでは、アクティブに使用されていないアプリをシステムがアイドル状態であるとみなす場合があります。 +システムが次の信号を検出しない場合、一定時間の経過後にアプリはアイドル状態であるとみなされます。 +
+ +端末が電源に接続されていない場合、アイドル中のみなされたアプリのネットワーク アクセスは無効になり、同期とジョブは保留されます。 +端末が電源に接続されると、アプリのネットワーク アクセスは許可され、保留中のすべてのジョブと同期が実行されます。 +端末が長時間アイドル状態の場合、アイドル中のアプリは 1 日 1 回程度ネットワーク アクセスが許可されます。 +
+ +この機能をテストするには、M Preview を実行する端末を開発マシンに接続して、次のコマンドを呼び出します。 + +
++$ 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> ++ +
注: +Google Cloud Messaging(GCM)の次期リリースでは、高優先度のメッセージを指定できます。 + +アプリが高優先度の GCM メッセージを受信する場合は、アプリがアイドル 中でも短時間のネットワーク アクセスが付与されます。 + +
+ +アプリで App Standby をテストする方法のヒントについては、 +Testing Guide をご覧ください。 +
+ ++このプレビューでは、SD カードなどの外部ストレージ端末を追加できます。外部ストレージ端末を追加すると、端末が内部ストレージのように動作するよう暗号化とフォーマットが行われます。 +この機能によって、アプリとアプリの個人データをストレージ端末間で移動できるようになります。 +アプリを移動する際、システムはマニフェストの +{@code android:installLocation} を遵守します。 + +
+ +アプリが次の API やフィールドにアクセスする場合は、アプリが内部ストレージ端末と外部ストレージ端末間で移動する際に返されるファイルパスが動的に変化することに注意してください。ファイルパスの構築時は、これらの API を動的に呼び出すことを強くお勧めします。ハードコードされたファイル パスを使用したり、過去にビルドした完全修飾ファイルパスをそのまま使用したりしないでください。 + + +
+ +Developer Preview のこの機能をデバッグするには、USB On-The-Go(OTG)ケーブルで Android 端末に接続された USB ドライブの追加を有効にして、次のコマンドを実行します。 +
+ ++$ adb shell sm set-force-adoptable true ++ +
このプレビューでは、Apache HTTP クライアントのサポートが削除されました。アプリでこのクライアントを使用していて、Android 2.3(API レベル 9)以上を対象としている場合は、代わりに {@link java.net.HttpURLConnection} クラスを使用します。 + +この API は透過的データ圧縮と応答のキャッシュによってネットワーク使用を軽減し、電源の消費を最小化するため、効率性が向上します。 +Apache HTTP API を引き続き使用するには、まず {@code build.gradle} ファイルで次のコンパイル時の依存関係を宣言する必要があります。 + +
+
+android {
+ useLibrary 'org.apache.http.legacy'
+}
+
+Android は、OpenSSL から +BoringSSL ライブラリに移行しています。 +アプリで Android NDK を使用している場合は、{@code libcrypto.so} や {@code libssl.so} など、NDK API の一部でない暗号化ライブラリにリンクしないでください。 +これらのライブラリは パブリック API ではなく、リリースや端末に対する通知なしで変更されたり、中断したりする可能性があります。また、セキュリティ上の脆弱性を露呈する場合もあります。 + +代わりに、ネイティブ コードを変更して JNI 経由で Java の暗号化 API を呼び出すか、希望の暗号化ライブラリに静的リンクします。 + +
+ +{@link android.media.AudioManager} クラスで音量を直接設定したり、特定のストリームをミュートにしたりする方法はサポートされなくなりました。 +{@link android.media.AudioManager#setStreamSolo(int,boolean) +setStreamSolo()} メソッドは廃止されたため、代わりに +{@code AudioManager.requestAudioFocus()} メソッドを呼び出す必要があります。同様に、 +{@link android.media.AudioManager#setStreamMute(int,boolean) setStreamMute()} メソッドも廃止され、代わりに {@code AudioManager.adjustStreamVolume()} メソッドを呼び出して、値に {@code ADJUST_MUTE} か {@code ADJUST_UNMUTE} を渡します。 + +
+ +
+
+ユーザーがアプリ内でテキストを選択するとき、 +切り取り、コピー、貼り付けなどのテキスト選択のアクションを +フローティング ツール バーに表示できるようになりました。 +個別のビューに対してコンテキスト アクション モードを有効にするにあるように、コンテキスト アクションバーに関するユーザー操作の実装も同様です。 + +
+ +テキスト選択にフローティング ツール バーを実装するには、既存のアプリに次の変更を加えます。 +
++Android Support Library revision 22.2 を使用している場合、フローティング ツール バーに下方互換性はなく、デフォルトで appcompat が代わりに {@link android.view.ActionMode} オブジェクトを制御することに注意してください。 + +これにより、フローティング ツール バーは表示されなくなります。 +{@link android.support.v7.app.AppCompatActivity} で +{@link android.view.ActionMode} がサポートされるようにするには、 +{@code android.support.v7.app.AppCompatActivity.getDelegate()} を呼び出して、返された +{@link android.support.v7.app.AppCompatDelegate} オブジェクトで +{@code android.support.v7.app.AppCompatDelegate.setHandleNativeActionModesEnabled()} を呼び出し、 入力パラメータを {@code false} に設定します。 +この呼び出して、{@link android.view.ActionMode} オブジェクトの制御がフレームワークに戻ります。 +M Preview を実行する端末ではフレームワークによる +{@link android.support.v7.app.ActionBar} やフローティング ツール バー モードのサポートが可能ですが、M Preview 以前の端末では +{@link android.support.v7.app.ActionBar} モードのみがサポートされます。
+ +このプレビューでは、 +Android Keystore プロバイダによる DSA のサポートがなくなります。 +ECDSA は引き続きサポートされます。
+ +停止時に暗号化を必要としないキーが、ロック画面の(ユーザーや端末の管理者などによる)無効時やリセット時に削除されなくなりました。 +停止時に暗号化を必要とするキーは、これらのイベント時に削除されます。 +
+ +このプレビューでは、Wi-Fi API とネットワーク API の動作に次のような変更点が追加されました。
+このプレビューでは、カメラ サービスの共有リソースへのアクセスモデルが、以前の "先着順" モデルから、"優先度順" に変更されました。 + +この動作の変更には、次のようなものがあります。
+ART ランタイムで、 +{@link java.lang.reflect.Constructor#newInstance(java.lang.Object...) newInstance()} メソッドに対するアクセスルールを正常に実装できるようになりました。この変更によって、以前のバージョンで Dalvik がアクセス ルールを正しく確認できなかった問題が解決しました。アプリで +{@link java.lang.reflect.Constructor#newInstance(java.lang.Object...) newInstance()} メソッドを使用していて、アクセス チェックをオーバーライドしたい場合は、 {@link java.lang.reflect.Constructor#setAccessible(boolean) setAccessible()} メソッドを使って入力パラメータを {@code true} に設定します。 + + + + +アプリで +v7 appcompat ライブラリや +v7 recyclerview ライブラリを使用する場合は、これらのライブラリの最新バージョンを使用するようアプリをアップデートする必要があります。 +アップデートしない場合は、XML から参照するカスタム クラスがアップデートされていて、クラス コンストラクタがアクセス可能であることを確認しておく必要があります。 +
+ +このプレビューでは、動的リンクの動作がアップデートされました。動的リンクでは、ライブラリの {@code soname} とそのパス( +public bug 6670)の違いを認識でき、{@code soname} が実装されています。 + + +以前動作していたアプリで間違った {@code DT_NEEDED} エントリを持つもの(ビルドマシンのファイル システムの絶対パスなど)は、読み込み時に失敗する場合があります。 +
+ +{@code dlopen(3) RTLD_LOCAL} フラグは正常に実装されました。 +{@code RTLD_LOCAL} はデフォルトのため、 +{@code RTLD_LOCAL} を明示的に使用しない {@code dlopen(3)} への呼び出しは影響を受けます(アプリで明示的に {@code RTLD_GLOBAL} を使用している場合を除く)。 +{@code RTLD_LOCAL} では、後に +{@code dlopen(3)} への呼び出しで読み込まれたライブラリで記号は使用できません({@code DT_NEEDED} エントリによって参照された場合とは逆)。
+ + +プラットフォームでより厳しい APK の検証が行われるようになりました。APK がマニフェスト ファイルで宣言されているにもかかわらず、APK 自体に存在しない場合、その APK は破損しているとみなされます。 +コンテンツが一部でも削除された場合は、APK の再署名が必要になります。 +
+ +このプレビューには、次のような Android for Work に関する動作の変更点が含まれています。
++ M Developer Preview では、アプリをインストールしてアップグレードするユーザーのプロセスを効率化する新しいアプリのパーミッション モデルが導入されました。 +M Preview で実行しているアプリで新しいパーミッション モデルがサポートされている場合、ユーザーはアプリをインストールまたはアップグレードするときにパーミッションを付与する必要はありません。その代わりに、アプリは必要になるとパーミッションを要求し、パーミッションを確認するよう求めるダイアログが表示されます。 + + + + +
+ ++ アプリで新しいパーミッション モデルがサポートされている場合、以前のバージョンの Android を実行している端末で、以前のパーミッション モデルを使ってインストールして実行することもできます。 + + +
+ ++ M Developer Preview とともに、プラットフォームでは新しいアプリのパーミッション モデルが導入されました。 +この新しいモデルの主要なコンポーネントの概要を次に示します。 +
+ +CONTACTS パーミッション グループにはユーザーの連絡先とプロフィール情報を読み書きするパーミッションが含まれます。
+
+
+ インストール時に付与される制限付きのパーミッション: ユーザーがアプリをインストールまたはアップデートするとき、{@link + android.content.pm.PermissionInfo#PROTECTION_NORMAL PROTECTION_NORMAL} に該当する、アプリが要求するすべてのパーミッションがアプリに付与されます。 + + + たとえば、目覚まし時計とインターネットのパーミッションは {@link + android.content.pm.PermissionInfo#PROTECTION_NORMAL PROTECTION_NORMAL} に該当するため、インストール時に自動的にそれらのパーミッションが付与されます。 + +
+ +システムは、システムアプリと署名のパーミッションに記載のとおり、アプリの署名とシステムのパーミッションも付与することがあります。 + +ユーザーは、インストール時にパーミッションを付与するように促すメッセージは表示されません。 +
++ このパーミッション モデルにより、パーミッションを要求する機能に対するアプリの動作方法が変わります。 +このモデルに合わせるために、従う必要のある開発プラクティスの概要を次に示します。 + +
+ +
+ + 図 1.アプリの [設定] のパーミッション画面。 +
++ 注: アプリのターゲットが M Developer Preview の場合、新しいパーミッション モデルを使う必要があります。 + +
+ ++ M Developer Preview のローンチ時点では、すべての Google アプリで新しいパーミッション モデルが完全に実装されているわけではありません。 +Google はこれらのアプリを M Developer Preview 中にアップデートして、パーミッションの切り替え設定を完全に実装します。 + + +
+ ++ 注: アプリに独自の API サーフェスがある場合、まず呼び出し側にそのデータへのアクセスに必要なパーミッションがあることを確認しないままパーミッションをプロキシしないでください。 + + +
+ ++ 本来、ユーザーがアプリをインストールするとき、システムはアプリに + {@link android.content.pm.PermissionInfo#PROTECTION_NORMAL + PROTECTION_NORMAL} のみを付与します。ただし、特定の環境では、アプリにより多くのパーミッションが付与されます。 + +
+ ++ + +どちらの場合でも、ユーザーはシステムの [設定] 画面に移動して [アプリ] > [app_name] > [パーミッション] を選ぶと、いつでもパーミッションを取り消すことができます。アプリは実行時にパーミッションを継続して確認し、必要に応じて要求する必要があります。 + + +
+ ++ アプリのターゲットが M Developer Preview 以外の場合、M Preview 端末でも以前のパーミッション モデルを引き続き使います。 +ユーザーがアプリをインストールするとき、ユーザーはアプリのマニフェストでリストされているすべてのパーミッションを付与するように要求されます。 + + +
+ ++ 注: M Developer Preview を実行している端末で、ユーザーはアプリの [設定] 画面から従来のアプリを含むすべてのアプリのパーミッションをオフにできます。 + +従来のアプリに対してパーミッションをオフにすると、適切な機能がサイレント状態で無効になります。 +アプリがそのパーミッションを必要とする操作を実行しようとするとき、その操作によって必ずしも例外が発生するとは限りません。 + +代わりに、空のデータセットを返す、エラーを示す、または予期しない動作を返すことがあります。 +たとえば、パーミッションなしでカレンダーを照会すると、メソッドは空のデータセットを返します。 + +
+ ++ M Preview を実行していない端末で新しいパーミッション モデルを使ってアプリをインストールする場合、他のすべてのアプリと同様に扱われ、インストール時に、すべての宣言されたパーミッションを付与するようユーザーに求めます。 + + + +
+ ++ 注: Preview リリースの場合、M Preview SDK に SDK の最小バージョンを設定して Preview SDK でコンパイルする必要があります。 +つまり、Developer Preview 中は従来のプラットフォームでそのようなアプリをテストできません。 + + +
+ ++ 多くの場合、アプリがタスクを実行するには 2 つの方法から選択できます。 +アプリ自体が操作を実行するパーミッションを要求できます。 +アプリでインテントを使うようにして、別のアプリがそのタスクを実行するようにすることもできます。 + +
+ +
+ たとえば、端末のカメラで写真を撮る機能がアプリに必要だとします。
+アプリは android.permission.CAMERA パーミッションをリクエストでき、それによりアプリが直接カメラにアクセスできるようになります。
+
+そのとき、アプリはカメラの API を使ってカメラを制御し、写真を撮ります。
+このアプローチにより、アプリが写真のプロセスを完全に制御し、カメラの UI をアプリに組み込むことができます。
+
+
+
+ ただし、そのような制御が不要な場合は、{@link + android.provider.MediaStore#ACTION_IMAGE_CAPTURE ACTION_IMAGE_CAPTURE} インテントを使うだけで画像を要求できます。 +インテントを開始すると、カメラアプリ(デフォルトのカメラアプリがない場合)を選んでアプリで写真を撮るよう求めるメッセージが表示されます。 + +カメラアプリはアプリの {@link + android.app.Activity#onActivityResult onActivityResult()} メソッドに写真を返します。 +
+ ++ 同様に、ユーザーの連絡先にアクセスするなどして電話をかける必要がある場合、適切なインテントを作成するか、パーミッションを要求して適切なオブジェクトに直接アクセスできます。 + +各アプローチにはメリットとデメリットがあります。 + +
+ ++ パーミッションを使う場合: +
+ ++ インテントを使う場合: +
+ ++ アプリのターゲットが新しい M Developer Preview の場合、新しいパーミッション モデルを使う必要があります。 +つまり、マニフェストで必要なパーミッションを宣言する他に、実行時にパーミッションがあることを確認し、まだパーミッションがない場合にはパーミッションを要求します。 + + + +
+ +
+ 新しい M Developer Preview パーミッション モデルを有効にするには、アプリの targetSdkVersion 属性を "MNC" に、compileSdkVersion を "android-MNC" に設定します。
+
+このように設定することで、新しいパーミッション機能すべてが有効になります。
+
+
+ Preview リリースの場合、minSdkVersion を "MNC" に設定して Preview SDK でコンパイルする必要があります。
+
+
+ アプリ マニフェストで新しい <uses-permission-sdk-m> 要素を使って、M Developer Preview のみで必要なパーミッションを表示できます。
+このようにしてパーミッションを宣言すると、アプリを以前の端末にインストールする場合はユーザーにメッセージが表示されないか、アプリにパーミッションが付与されません。<uses-permission-sdk-m> 要素を使うと、新しいパーミッションを追加してインストールをアップデートするときにパーミッションの付与を強制せずにアプリのバージョンがアップデートされます。
+
+
+
+
+
+
+
+ M Developer Preview を使ってアプリが端末で実行されている場合、<uses-permission-sdk-m> は <uses-permission> と同じように動作します。
+
+
+ アプリをインストールするとき、パーミッションの付与を求めるメッセージは表示されず、アプリは必要なときにパーミッションを要求します。
+
+
+ アプリで新しい M Developer Preview パーミッション モデルが使われている場合、M Preview を実行している端末でアプリを初めて起動するとき、すべての権限を付与する必要はありません。 + +その代わりに、アプリは必要なときにパーミッションを要求します。 +アプリがパーミッションを要求すると、ユーザーにダイアログが表示されます。 + +
+ +
+ SDK 22 以降がインストールされた端末でアプリを実行する場合、アプリでは以前のパーミッション モデルが使われます。
+ユーザーがアプリをインストールすると、アプリがそのマニフェストで要求するすべてのパーミッションの付与を求めるメッセージが表示されます。ただし、<uses-permission-sdk-m> というラベルの付いたパーミッションは例外です。
+
+
+
+ このパーミッション モデルは、M Developer Preview を実行している端末でのみサポートされます。
+これらのメソッドのいずれかを呼び出す前に、アプリは {@link android.os.Build.VERSION#CODENAME
+ Build.VERSION.CODENAME} の値を確認してどのプラットフォーム上で実行されているのかを確認する必要があります。
+
+端末で M Developer Preview が実行されている場合、{@link android.os.Build.VERSION#CODENAME CODENAME} は "MNC" です。
+
+
ユーザーがパーミッションを要求する動作を行うと、アプリは現在この操作を実行するためのパーミッションがあるかどうかを確認します。
+
+
+確認するために、アプリは Context.checkSelfPermission(permission_name) を呼び出します。ユーザーが既にパーミッションを付与していることをアプリが認識している場合でも、ユーザーはいつでもアプリのパーミッションを取り消すことができるため、この確認が行われます。
+
+
+たとえば、ユーザーがアプリを使って写真を撮る場合、アプリは Context.checkSelfPermission(Manifest.permission.CAMERA) を呼び出します。
+
+
+ 表 1.パーミッションとパーミッション グループ。
+| パーミッション グループ | +パーミッション | +
|---|---|
android.permission-group.CALENDAR |
+
+
|
+
android.permission-group.CAMERA |
+
+
|
+
android.permission-group.CONTACTS |
+
+
|
+
android.permission-group.LOCATION |
+
+
|
+
android.permission-group.MICROPHONE |
+
+
|
+
android.permission-group.PHONE |
+
+
|
+
android.permission-group.SENSORS |
+
+
|
+
android.permission-group.SMS |
+
+
|
+
アプリに必要なパーミッションがない場合、アプリは Activity.requestPermissions(String[], int) メソッドを呼び出して適切なパーミッションを要求します。
+
+アプリは必要なパーミッションと整数の「要求コード」を渡します。
+
+ このメソッドは非同期に機能します。このメソッドはすぐに返され、ユーザーがダイアログ ボックスに応答した後、システムはその結果と一緒にアプリのコールバック メソッドを呼び出し、アプリが requestPermissions() に渡すのと同じ「要求コード」を渡します。
+
+
+
次のコードは、ユーザーの連絡先を読み込むパーミッションがアプリにあることを確認し、必要に応じてパーミッションを要求します。 +
+ +
+if (checkSelfPermission(Manifest.permission.READ_CONTACTS)
+ != PackageManager.PERMISSION_GRANTED) {
+ requestPermissions(new String[]{Manifest.permission.READ_CONTACTS},
+ MY_PERMISSIONS_REQUEST_READ_CONTACTS);
+
+ // MY_PERMISSIONS_REQUEST_READ_CONTACTS is an
+ // app-defined int constant
+
+ return;
+}
+
+
+
+ アプリがパーミッションを要求すると、システムによってダイアログ ボックスが表示されます。
+ユーザーが応答すると、システムはアプリの Activity.onRequestPermissionsResult(int, String[], int[]) を呼び出し、ユーザーの応答を渡します。
+
+アプリはそのメソッドをオーバーライドする必要があります。コールバックには開発者が requestPermissions() に渡したのと同じ要求コードが渡されます。
+
+たとえばアプリが READ_CONTACTS アクセスを要求する場合、次のコールバック メソッドが含まれる可能性があります。
+
+
+
+@Override
+public void onRequestPermissionsResult(int requestCode,
+ String permissions[], int[] grantResults) {
+ switch (requestCode) {
+ case MY_PERMISSIONS_REQUEST_READ_CONTACTS: {
+ if (grantResults[0] == PackageManager.PERMISSION_GRANTED) {
+
+ // permission was granted, yay! do the
+ // calendar task you need to do.
+
+ } else {
+
+ // permission denied, boo! Disable the
+ // functionality that depends on this permission.
+ }
+ return;
+ }
+
+ // other 'switch' lines to check for other
+ // permissions this app might request
+ }
+}
+
+
+ ユーザーがパーミッションを付与すると、システムは、機能領域のアプリ マニフェストがリストするすべてのパーミッションを付与します。 +ユーザーが要求を拒否する場合は、適切なアクションを取ってください。 +たとえば、このパーミッションに応じて、すべてのメニュー アクションを無効にできます。 + + +
+ +
+ ユーザーにパーミッションの付与を確認するとき、ユーザーにそのパーミッションについて再度確認しないようにするオプションがあります。
+この場合、アプリが requestPermissions() を使ってパーミッションを確認すると、システムはその要求をすぐに拒否します。
+
+この場合、システムはユーザーが要求を再度明示的に拒否する場合と同様に onRequestPermissionsResult() を呼び出します。
+
+このため、アプリではユーザーとの直接的なやり取りが発生することが想定されません。
+
+
+ アプリのターゲットが M Developer Preview の場合、パーミッションが正しく処理されることをテストする必要があります。 +アプリ起動時に特定のパーミッションがアプリにあることは想定できません。 +アプリが初めて起動されるとき、パーミッションがない可能性が高く、ユーザーはいつでもパーミッションを取り消すまたは復元できます。 + + +
+ ++ アプリがすべてのパーミッションの状況下で確実に正しく動作することをテストしてください。 +M Preview SDK とともに、新しい Android デバッグ ブリッジ(adb)コマンドが導入され、試す必要のあるあらゆるパーミッション設定でアプリをテストできます。 + + + +
+ ++ M Preview SDK Platform-tools では、アプリがパーミッションをどう処理するかをテストするための、いくつかの新しいコマンドが導入されました + +
+ +
+ adb
+ install コマンドの新しい -g オプションを使ってアプリをインストールし、そのマニフェストにリストされるすべてのパーミッションを付与できます。
+
+
+$ adb install -g <path_to_apk> ++ +
+ 新しい ADB Package Manager(pm)コマンドを使って、インストールされているアプリにパーミッションを付与したり取り消したりできます。この機能は自動化されたテストに役立ちます。 + + +
+ +
+ パーミッションを付与するには、Package Manager の grant コマンドを使います。
+
+$ adb pm grant <package_name> <permission_name> ++ +
+ たとえば、com.example.myapp パッケージ パーミッションを付与してオーディオを録音するには、このコマンドを使います。 + +
+ ++$ adb pm grant com.example.myapp android.permission.RECORD_AUDIO ++ +
+ パーミッションを取り消すには、Package Manager の revoke コマンドを使います。
+
+$ adb pm revoke <package_name> <permission_name> ++ +
+ 新しいパーミッション モデルにより、ユーザーはよりスムーズな操作感を得られ、アプリを簡単にインストールできるようになり、アプリが実行している内容に満足します。 + +新しいモデルを最大限に活用するために、次のベスト プラクティスをお勧めします。 + +
+ + ++ パーミッションを要求するたびに、ユーザーに決定するよう強制します。 + ユーザーが要求を却下すると、アプリの機能が低下します。 + これらの要求回数は最小限にしてください。 +
+ ++ たとえば、アプリがパーミッションを要求する代わりに、インテントを使って必要な機能を取得できる場合がよくあります。 + +アプリが携帯電話のカメラで写真を撮る必要がある場合、そのアプリでは {@link + android.provider.MediaStore#ACTION_IMAGE_CAPTURE + MediaStore.ACTION_IMAGE_CAPTURE} インテントを使用できます。 +アプリがインテントを実行すると、写真を撮るためのインストール済みのカメラアプリを選ぶようユーザーに促します。 + + +
+ ++ ユーザーにパーミッションをたくさん要求すると、ユーザーを疲れさせてしまい、アプリが終了される原因になります。代わりに、ユーザーには必要なパーミッションのみを要求してください。 + + +
+ ++ アプリ対して 1 つ以上のパーミッションが必須である場合もあります。その場合は、アプリの起動後すぐに、すべてのパーミッションを要求することが合理的である場合があります。 + +たとえば、カメラアプリを作成する場合、アプリは端末のカメラにアクセスする必要があります。 +アプリを初めて起動するときにカメラの使用についてのパーミッションを求められても驚かないはずです。 + +ただし、同じアプリにユーザーの連絡先と写真を共有する機能もある場合は、最初の起動時にパーミッションを要求しない方が無難です。 + +その代わりに、ユーザーが「共有」機能を使うまで待ち、そのときにパーミッションを要求します。 + +
+ ++ アプリにチュートリアルが含まれる場合は、チュートリアルのシーケンスの最後で、アプリに必須のパーミッションを要求する方が合理的です。 + +
+ +
+ requestPermissions() を呼び出すとき、システムによって表示されるパーミッション ダイアログにはアプリが必要としているパーミッションは表示されますが、理由は表示されません。
+
+これによりユーザーが困惑する場合もあります。
+ requestPermissions() を呼び出す前に、アプリがパーミッションを必要としている理由をユーザーに説明するのはよい方法です。
+
+
+ たとえば、カメラアプリでは、位置情報サービスを使って写真に位置情報タグを付けられるようにする場合があります。
+通常のユーザーは、写真に位置情報が含まれる場合があることを認識していない可能性があり、なぜカメラアプリで位置情報が必要なのか困惑する可能性があります。
+
+この場合、アプリが requestPermissions() を呼び出す前に、この機能についてユーザーに知らせることをお勧めします。
+
+
+
+ その方法として、これらの要求をアプリのチュートリアルに組み込むこともできます。チュートリアルでは、アプリの各機能を順番に表示できるので、必要なパーミッションを説明できます。
+
+たとえば、カメラアプリのチュートリアルでは、「連絡先と写真を共有する」機能について説明し、ユーザーの連絡先を参照するためにアプリにパーミッションが必要であることをユーザーに知らせることができます。
+
+
+その後、アプリは requestPermissions() を呼び出して、ユーザーにそのアクセスを求めることができます。
+もちろん、すべてのユーザーがチュートリアルに従うわけではないため、アプリの通常操作中にパーミッションを確認して要求することも必要です。
+
+
+
+ Android M Developer Preview では、Android の次のバージョンでアプリをテストして最適化するためのすべてを備えています。 + +M Developer Preview ツールをダウンロードするだけで、無料ですぐにご利用いただけます。 + +
+ ++ Nexus 5、6、9、Nexus Player(TV 向け)やエミュレータでアプリをテストしましょう。 + +
++ プレビューで複数のアップデートが提供されますので、最新プラットフォームの変更に応じてテストできます。 + +
++ デバイスに初期プレビューをコピーしたら、無線経由でアップデートを入手できます。 + +
++ 新しい実行時パーミッション モデルや省電力機能など、新しいプラットフォームの動作をあらかじめサポートする + +
++ 最初の数週間で開発者から報告のあった問題について優先度を設定し、可能な限り早くテストを行いフィードバックを提供できるようにします。 + +
++ Issue Tracker で問題を報告し、フィードバックをお送りください。 + M Developer コミュニティ で他の開発者とつながりましょう。 + +
+
++ M Developer Preview は 5 月 28 日から最終の Android M SDK まで実行されます。Android M SDK はまもなく、2015 年第三四半期に予定されている正式公開の前にリリースされます。 + + +
+ ++ 開発の主なマイルストーンごとにテスト端末へアップデートを配信する予定としています。 + 暫定マイルストーンは以下のとおりです。 +
+ ++ アップデートは第三四半期後半に予定されている最終 SDK で終了します。最終版では新しい Android に対する正式な API や最終的なシステム動作や機能が提供されます。 + + +
+ ++ Android M でのテストや開発に際しては、Preview アップデートがリリースされるたびに開発環境を最新に保つことを強くお勧めします。 + + プロセスをより容易にするため、既に Preview ビルドがインストールされた端末に無線経由でアップデート(OTA)を配信します。また手動でダウンロードして展開できるシステム イメージもご提供します。 + + +
++ 注: 最終 SDK とシステム イメージは OTA では配信できません。代わりにテスト端末に手動でコピーする必要があります。 + + +
+ ++ Preview アップデートをご利用いただけるようになった際は Android デベロッパー ブログ、このサイト、Android M デベロッパー コミュニティでお知らせします。 + + +
+ ++ M Developer Preview では、ご利用のアプリをさまざまな画面サイズ、ネットワーク、テクノロジー、CPU や GPU チップセット、ハードウェア設計でテストするために必要なあらゆるものを備えています。 + + +
+ ++ 各コンポーネントは Android Studio の SDK Manager でダウンロードできます。 +
+ ++ Nexus 端末向けハードウェア システム イメージは、ダウンロード ページからダウンロードできます。 + +
+ ++ 次のドキュメント リソースで Preview についての詳細をご確認いただけます。 +
+ ++ M Developer Preview でのテストや開発について、次のサポート リソースをご確認いただけます。 + +
+ +
+ Android M Developer Preview は開発リリースのみであり、標準 API レベルはありません。
+アプリのテストで互換性の問題は除外する場合(強く推奨します)、アプリのtargetSdkVersion を “MNC” に設定することで M Developer Preview を対象にできます。
+
+
+
+
+ Android M Developer Preview ではプレビュー API を配信しています。現在 2015 年度第三四半期に予定されている最終 SDK がリリースされるまで、API は正式版ではありません。 + +つまり、時間がたつにつれて API の細かな変更が見込まれます(特にプログラムの最初の数週間)。 + +Android M Developer Preview でアップデートがあればその都度変更の概要をご提供します。 + +
+ ++ プレビュー API は変更される可能性がありますが、実行時パーミッションや省電力機能などのシステムの基幹にかかわる機能には変更はありませんので、すぐにテストしていただけます。 + + +
+ ++ 公開に関して、Google Play では M Developer Preview 対象アプリは公開できません。 +Android M 最終 SDK が利用可能になれば正式な Android M API レベルを対象にして、Google Play でアプリを公開できるようになります。 + +それまでは、Android M 対象のアプリをテスターに配布する場合は電子メールで送付したりご自分のサイトから直接ダウンロードしてもらったりしてください。 + + +
+ ++ アプリのテストをはじめるには: +
+ ++ Android M Developer Preview プログラムへのご参加ありがとうございます。 +
diff --git a/docs/html-intl/intl/ko/preview/api-overview.jd b/docs/html-intl/intl/ko/preview/api-overview.jd new file mode 100644 index 0000000000000..aac9a44924e04 --- /dev/null +++ b/docs/html-intl/intl/ko/preview/api-overview.jd @@ -0,0 +1,521 @@ +page.title=API 개요 +page.keywords=미리 보기, SDK, 호환성 +page.tags=previewresources, androidm +sdk.platform.apiLevel=22-mnc +page.image=images/cards/card-api-overview_16-9_2x.png +@jd:body + + +M 개발자 미리 보기에서는 다가오는 Android 플랫폼 릴리스를 미리 볼 수 있도록 하였습니다. 이 릴리스는 사용자와 앱 개발자를 위한 여러 가지 새 기능을 제공합니다. + + 이 문서에서는 가장 중요한 API를 몇 가지 소개합니다.
+ +M 개발자 미리 보기는 개발자 얼리 어답터와 테스터를 위해 마련된 것입니다. + Android 프레임워크가 나아갈 방향에 영향을 미치는 데 관심이 있으시다면, M 개발자 미리 보기를 시도해 보시고 피드백을 보내주세요! + + +
+ +주의: M 개발자 미리 보기를 사용하는 앱을 Google Play 스토어에 게시하지 마세요. +
+ +참고: 이 문서에서 종종 언급하는 클래스와 메서드 중에는 아직 developer.android.com에서 참조 자료로 이용할 수 없는 것도 있습니다. + 이와 같은 API 요소는 이 문서에서 {@code code style}로 형식 지정되어 있습니다(하이퍼링크 없이). + 이러한 요소에 대한 임시 API 관련 문서가 필요한 경우, 미리 보기 참조를 다운로드하세요. +
+ +이전에 Android용 앱을 게시한 적이 있는 경우, 플랫폼 변경으로 인해 앱이 영향받을 수 있다는 점을 유의하세요. +
+ +완전한 정보는 동작 변경을 참조하세요.
+ +이 미리 보기는 더욱 강력한 앱 연결을 제공하여 Android의 인텐트 시스템을 한층 강화합니다. 이 기능을 사용하면 앱을 본인이 소유한 웹 도메인과 연관시킬 수 있습니다. + 플랫폼은 이 연관 관계를 근거로 특정한 웹 링크를 처리하는 데 사용할 기본 앱을 결정할 수 있고 사용자에게 앱을 선택하라는 메시지를 건너뛸 수 있습니다. 이 기능을 구현하는 방법을 알아보려면 앱 연결을 참조하세요. + + + + +
시스템에서 이제 앱에 대한 완전한 데이터 백업과 복원을 자동으로 수행합니다. 이 동작은 앱 대상 지정 M 미리 보기에 대한 기본으로 활성화되며, 추가 코드를 전혀 추가하지 않아도 됩니다. + 사용자가 Google 계정을 삭제하면 계정의 백업 데이터도 함께 삭제됩니다. + 이 기능의 작동 원리와 파일 시스템에서 백업 내용 구성하는 방법에 대해 알아보려면 앱용 자동 백업을 참조하세요. + +
+ +이 미리 보기에서는 사용자를 인증할 때 지원되는 기기에서 지문 스캔을 사용하도록 해주는 새로운 API를 제공합니다. 또한 기기 잠금 해제 메커니즘(예: 화면 잠금 비밀번호)을 사용해 사용자의 마지막 인증 시간을 확인할 수도 있습니다. + + 이러한 API는 Android Keystore 시스템과 함께 사용하세요. +
+ +지문 스캔을 통해 사용자를 인증하려면 새로운 {@code android.hardware.fingerprint.FingerprintManager} 클래스의 인스턴스를 가져와 {@code FingerprintManager.authenticate()} 메서드를 호출하세요. + + 앱이 지문 센서가 있는 호환되는 기기에서 실행되고 있어야 합니다. + 지문 인증 흐름에 대한 사용자 인터페이스를 앱에 구현해야 하며, UI에 표준 Android 지문 아이콘을 사용해야 합니다. 이 Android 지문 아이콘({@code c_fp_40px.png})은 샘플 앱에 포함되어 있습니다. 지문 인증을 사용하는 앱을 여러 개 개발하는 경우, 각 앱이 사용자의 지문을 따로따로 인증해야 한다는 사실을 명심하세요. + + + + +
+ +앱에서 이 기능을 사용하려면 우선 매니페스트에 {@code USE_FINGERPRINT} 권한을 추가해야 합니다. +
+ ++<uses-permission + android:name="android.permission.USE_FINGERPRINT" /> ++ +
+
+지문 인증의 앱 구현을 확인하려면, 지문 대화 샘플을 참조하세요. + +
+ +이 기능을 테스트하는 경우, 다음 단계를 따르면 됩니다.
++adb -e emu finger touch <finger_id> ++
Windows에서는 {@code telnet 127.0.0.1 <emulator-id>}에 뒤이어 {@code finger touch <finger_id>}를 실행해야 할 수도 있습니다. + +
+앱에서 사용자를 인증할 때 해당 사용자가 기기를 마지막으로 잠금 해제한 시간을 근거로 할 수 있습니다. 이 기능을 사용하면 사용자가 앱에 따라 각기 다른 비밀번호를 기억할 필요가 없어지고, 개발자는 자신만의 인증 사용자 인터페이스를 구현하지 않아도 됩니다. + + 앱에서 이 기능을 사용하려면 사용자 인증에 대한 공개 또는 비밀 키 구현과 함께 사용해야 합니다. +
+ +사용자를 성공적으로 인증한 다음 같은 키를 재사용하기 위한 시간 초과 기간을 설정하려면, 새로운 {@code android.security.keystore.KeyGenParameterSpec.setUserAuthenticationValidityDurationSeconds()} 메서드를 호출하세요. {@link javax.crypto.KeyGenerator} 또는 {@link java.security.KeyPairGenerator}를 설정할 때 사용하면 됩니다. + + + + 현재 이 기능은 대칭형 암호화 작동에 맞게 작동합니다. +
+ +재인증 대화창을 과도하게 표시하는 것을 삼가세요. 우선 앱에서 암호화 객체 사용을 시도해보고, 제한 시간이 만료되면 {@link android.app.KeyguardManager#createConfirmDeviceCredentialIntent(java.lang.CharSequence, java.lang.CharSequence) createConfirmDeviceCredentialIntent()} 메서드를 사용해 앱 내에서 해당 사용자를 재인증하면 됩니다. + + + +
+ +이 기능의 앱 구현을 확인하려면, 확인 자격 증명 샘플를 참조하세요. + +
+ +
+
+이 미리 보기에서는 사용자가 공유 기능을 간편하고 신속하게 이용할 수 있도록 해주는 API를 제공합니다. 이제 앱에서 특정 액티비티를 시작하는 직접 공유 대상을 정의할 수 있습니다. 이와 같은 직접 공유 대상은 공유 메뉴를 통해 사용자에게 노출됩니다. + + 이 기능을 사용하면 사용자가 다른 앱 내의 대상(예: 연락처)에 대해 콘텐츠를 공유할 수 있습니다. + 예를 들어, 직접 공유 대상이 다른 소셜 네트워크 앱에서 액티비티를 시작하면 사용자가 해당 앱에 있는 특정 친구나 커뮤니티와 콘텐츠를 공유할 수 있습니다. + +
+ +직접 공유 대상을 활성화하려면 반드시 {@code android.service.}
+
+{@code chooser.ChooserTargetService} 클래스를 확장하는 클래스를 정의해야 합니다. 매니페스트에서 {@code ChooserTargetService}를 선언하고
+ 해당 선언 내에서 {@code BIND_CHOOSER_TARGET_SERVICE} 권한을 지정하고 {@code SERVICE_INTERFACE} 작업으로 인텐트 필터를 지정합니다.
+
+
다음 예는 매니페스트에서 {@code ChooserTargetService}를 선언할 수 있는 방법입니다. +
++<service android:name=".ChooserTargetService" + android:label="@string/service_name" + android:permission="android.permission.BIND_CHOOSER_TARGET_SERVICE"> + <intent-filter> + <action android:name="android.service.chooser.ChooserTargetService" /> + </intent-filter> +</service> ++ +
{@code ChooserTargetService}에 노출하고자 하는 액티비티마다 {@code <meta-data>} 요소를 하나씩 추가하고, 앱 매니페스트에 {@code "android.service.chooser.chooser_target_service"} 이름을 추가합니다. + + +
+ ++<activity android:name=".MyShareActivity” + android:label="@string/share_activity_label"> + <intent-filter> + <action android:name="android.intent.action.SEND" /> + </intent-filter> +<meta-data + android:name="android.service.chooser.chooser_target_service" + android:value=".ChooserTargetService" /> +</activity> ++ +
+이 미리 보기에서 제공하는 새로운 음성 상호작용 API는 음성 액션과 같이 앱에 대화형 음성 환경을 구축할 수 있도록 합니다. + + {@code android.app.Activity.isVoiceInteraction()} 메서드를 호출하여 액티비티가 음성 액션에 대응하여 시작된 것인지 알아보세요. + + 이 경우에 해당되면, 앱이 {@code android.app.VoiceInteractor} 클래스를 사용하여 사용자로부터 음성 확인을 요청하거나, 선택 항목 목록에서 선택하게 하는 등 여러 가지 일을 할 수 있습니다. + + 음성 액션 구현에 대한 자세한 정보는 음성 액션 개발자 사이트를 참조하세요. + +
+ ++이 미리 보기에서는 사용자가 도우미를 통해 앱에 참여하게 하는 새로운 방식을 제시합니다. 이 기능을 사용하려면, 사용자가 현재 컨텍스트를 사용하기 위해 도우미를 활성화해야 합니다. + 일단 활성화하고 나면 홈 버튼을 길게 눌러 해당 도우미를 어느 앱에서나 불러낼 수 있습니다. +
+앱이 현재 컨텍스트를 도우미와 공유하지 않기로 선택하는 경우, {@link android.view.WindowManager.LayoutParams#FLAG_SECURE} 플래그를 설정하면 됩니다. + 플랫폼이 도우미에게 전달하는 일반적인 일련의 정보 외에도 앱이 추가적인 정보를 공유할 수 있도록 하려면 새로 나온 {@code android.app.Activity.AssistContent} 클래스를 사용할 수 있습니다. + +
+ +도우미에게 앱에서 가져온 추가 컨텍스트를 제공하려면, 다음 단계를 따르면 됩니다.
+ +이 미리 보기에서는 알림 기능에 다음과 같은 API 변경을 추가합니다.
+이 미리 보기에서는 블루투스 스타일러스를 사용하는 사용자 입력에 대한 지원을 개선하여 제공합니다. 사용자는 전화기나 태블릿을 호환되는 블루투스 스타일러스와 페어링하고 이에 연결할 수 있습니다. + 연결된 동안 터치 스크린에서 가져온 위치 정보가 스타일러스에서 가져온 압력 및 버튼 정보와 합쳐져 하나의 터치 스크린을 사용할 때보다 훨씬 폭넓은 표현을 제공합니다. + + 앱이 스타일러스 버튼 누르기를 수신 대기하고 보조 작업을 수행하도록 하려면, 액티비티에 새로운 {@code View.onStylusButtonPressListener} 및 {@code GestureDetector.OnStylusButtonPressListener} 콜백을 등록하면 됩니다. + + +
+ +스타일러스 버튼 상호작용을 감지하려면 {@link android.view.MotionEvent} 메서드와 상수를 사용하세요. +
++앱이 블루투스 저전력 스캔을 수행하는 경우, 새로운 {@code android.bluetooth.le.ScanSettings.Builder.setCallbackType()} 메서드를 사용해 콜백에 알림을 원하는 시점을 지정할 수 있습니다.즉, 정해진 {@link android.bluetooth.le.ScanFilter}에 일치하는 광고 패킷을 처음 찾았을 때와 이것을 일정한 시간 동안 확인하지 못했을 때에만 콜백에 알리도록 하면 됩니다. + + + + 스캔 기능에 대해 이런 식으로 접근하면 이전 버전의 플랫폼에서 제공되었던 것에 비해 훨씬 전력 효율적입니다. + +
+ ++이 미리 보기에서는 Nexus 6 및 Nexus 9 기기에서의 핫스팟 2.0 릴리스 1 사양에 대한 지원을 추가합니다. 앱에 핫스팟 2.0 자격 증명을 프로비저닝하려면 {@link android.net.wifi.WifiEnterpriseConfig} 클래스의 새 메서드를 사용할 수 있습니다(예: {@code setPlmn()} 및 {@code setRealm()}). + + + {@link android.net.wifi.WifiConfiguration} 객체에서는 {@link android.net.wifi.WifiConfiguration#FQDN} 및 {@code providerFriendlyName} 필드를 설정하면 됩니다. 새로 나온 {@code ScanResult.PasspointNetwork} 속성이 감지된 네트워크가 핫스팟 2.0 액세스 지점을 나타내는지 여부를 알려줍니다. + + + +
+ +이제 플랫폼에서 앱이 호환되는 하드웨어에서 디스플레이 해상도를 4K 렌더링으로 업그레이드하도록 요청할 수 있습니다. + 현재의 물리적 해상도를 쿼리하려면 새로운 {@code android.view.Display.Mode} API를 사용할 수 있습니다. + UI가 더 낮은 논리적 해상도에서 그려졌고 더 큰 물리적 해상도에 맞춰 확장된 경우, {@code Display.Mode.getPhysicalWidth()} 메서드가 반환하는 물리적 해상도가 {@link android.view.Display#getSize(android.graphics.Point) getSize()}가 보고하는 논리적 해상도와 다를 수 있다는 점을 유의하세요. + + +
+ +앱이 실행되는 중에 시스템에 물리적 해상도를 변경하도록 요청할 수도 있습니다. 앱의 창에서 {@code WindowManager.LayoutParams.preferredDisplayModeId} 속성을 설정하면 됩니다. + 이 기능은 4K 디스플레이 해상도로 전환하고자 하는 경우 무척 유용합니다. + 4K 디스플레이 모드에서 UI는 계속 원래 해상도(예: 1080p)에서 렌더링되며 4K로 확장되지만, {@link android.view.SurfaceView} 객체는 원래 해상도에서 콘텐츠를 표시할 수 있습니다. + +
+ +이제 M 미리 보기를 실행하는 기기에 대해 테마 속성이 {@link android.content.res.ColorStateList}에서 지원됩니다. + {@link android.content.res.Resources#getColorStateList(int) getColorStateList()} 및 {@link android.content.res.Resources#getColor(int) getColor()} 메서드는 사용이 중단되었습니다. + + 이러한 API를 호출하려면, 대신 새로운 {@code Context.getColorStateList()} 또는 {@code Context.getColor()} 메서드를 호출하세요. + + 이 두 메서드는 v4 AppCompat 라이브러리에서도 {@link android.support.v4.content.ContextCompat}를 통해 이용할 수 있습니다. +
+ +이 미리 보기에서는 Android에서의 오디오 처리에 개선점을 더했습니다.
+이 미리 보기에서는 비디오 처리 API에 새로운 기능을 추가합니다.
+이 미리 보기에는 다음과 같은 새 API를 제공하여 카메라의 플래시에 액세스하고 이미지를 재처리하는 카메라에 액세스할 수 있도록 했습니다. +
+ +카메라 기기에 플래시 장치가 있는 경우, {@code CameraManager.setTorchMode()} 메서드를 호출하여 카메라 기기를 열지 않고도 플래시 장치의 Torch 모드를 켜거나 끌 수 있습니다. + 앱에는 플래시 장치 또는 카메라 기기에 대한 독점적인 소유권이 없습니다. + Torch 모드는 꺼져 있다가 카메라 기기를 이용할 수 없게 될 때마다 이용 불가능한 상태가 되고, Torch 모드를 켜진 상태로 유지하던 다른 카메라 리소스를 이용할 수 없게 되면 이용 불가능하게 됩니다. + + 다른 앱도 {@code setTorchMode()}를 호출하여 Torch 모드를 끌 수 있습니다. + Torch 모드를 켠 마지막 앱이 종료되면 Troch 모드도 꺼집니다. +
+ +Torch 모드 상태에 대해 알림을 받기 위한 콜백을 등록하려면 {@code CameraManager.registerTorchCallback()} 메서드를 호출하면 됩니다. + 콜백을 처음 등록하면 그 즉시, 현재 알려진 모든 카메라 기기(플래시 장치가 있는)의 Torch 모드 상태와 함께 호출됩니다. + + Torch 모드가 성공적으로 켜지거나 꺼지면 {@code CameraManager.TorchCallback.onTorchModeChanged()} 메서드가 불려나옵니다. +
+ +{@link android.hardware.camera2 Camera2} API를 확장하여 YUV를 지원하고 비공개 불투명 형식 이미지 재처리를 지원하게 되었습니다. + 앱은 재처리 기능을 이용할 수 있는지 알아보기 위해 {@code CameraCharacteristics.REQUEST_AVAILABLE_CAPABILITIES}를 통합니다. + 기기가 재처리를 지원하는 경우, 재처리 가능한 카메라 캡처 세션을 생성하려면 {@code CameraDevice.createReprocessableCaptureSession()}을 호출하고 입력 버퍼 재처리를 위한 요청을 생성하면 됩니다. + + +
+ +{@code ImageWriter} 클래스를 사용하여 카메라 재처리 입력에 입력 버퍼 흐름을 연결시키세요. + 빈 버퍼를 가져오려면 다음과 같은 프로그래밍 모델을 따르면 됩니다.
+ +{@code ImageWriter} 객체와 {@code android.graphics.ImageFormat.PRIVATE} 이미지를 함께 사용하는 경우, 앱이 이미지 데이터에 직접 액세스할 수 없습니다. + + 대신, 버퍼 사본 없이 {@code ImageWriter.queueInputImage()} 메서드를 호출하여 {@code ImageFormat.PRIVATE} 이미지를 {@code ImageWriter}에 직접 전달하면 됩니다. + +
+ +이제 {@code ImageReader} 클래스가 {@code android.graphics.ImageFormat.PRIVATE} 형식 이미지 스트림을 지원합니다. + 이로써 앱이 {@code ImageReader} 출력 이미지의 원형 이미지 대기열을 유지하고 하나 이상의 이미지를 선택하여 이들을 {@code ImageWriter}에 보내 카메라 재처리를 할 수 있습니다. + +
+ +이 미리 보기에는 다음과 같은 Android for Work에 대한 새 API가 포함되어 있습니다.
+이외에도 Google Play 서비스에 앱 제한을 설정하면 기기 소유자가 기기에서 활성화된 것을 대신할 대체 Google 계정을 지정하여 FRP를 잠금 해제하는 데 사용할 수 있습니다. +
+
+프로필 또는 기기 소유자는 모든 애플리케이션의 모든 런타임 요청에 대해 권한 정책을 설정할 수 있습니다. {@code DevicePolicyManager.setPermissionPolicy()}를 사용해 사용자에게 정상적으로 권한을 부여하라는 메시지를 표시하거나, 자동으로 권한을 허용하거나 해당 권한을 자동으로 거부하도록 할 수도 있습니다. + + + 후자의 정책이 설정된 경우, 사용자는 앱의 설정 내에 있는 권한 화면 안에서 프로필 또는 기기 소유자가 선택한 내용을 수정할 수 없습니다. + +
+ M 개발자 미리 보기의 모든 API 변경 내용에 대한 상세한 정보는 API 차이점 보고서를 참조하세요. +
diff --git a/docs/html-intl/intl/ko/preview/behavior-changes.jd b/docs/html-intl/intl/ko/preview/behavior-changes.jd new file mode 100644 index 0000000000000..fa9507056b721 --- /dev/null +++ b/docs/html-intl/intl/ko/preview/behavior-changes.jd @@ -0,0 +1,402 @@ +page.title=동작 변경 +page.keywords=미리 보기, SDK, 호환성 +sdk.platform.apiLevel=MNC +@jd:body + +M 개발자 미리 보기에는 새로운 기능 및 특징과 더불어 다양한 시스템 변경과 API 동작 변경 내용이 포함되어 있습니다. + 이 문서에서는 개발자 여러분이 숙지해야 하고 앱을 개발할 때 감안해야 하는 몇 가지 주요 변경 내용을 소개하겠습니다. +
+ +이전에 Android용 앱을 게시한 적이 있는 경우, 이와 같은 플랫폼 변경으로 인해 앱이 영향을 받을 수 있다는 점을 유의하세요. +
+ +이 미리 보기에서는 새 권한 모델을 소개합니다. 여기에서는 이제 사용자가 런타임에 직접 앱 권한을 관리할 수 있게 됩니다. + 이 모델을 사용하면 사용자에게 개선된 가시성과 권한에 대한 제어권을 부여하는 한편 앱 개발자에게는 설치와 자동 업데이트 과정을 간소화해줍니다. 사용자는 설치된 여러 앱에 대해 따로따로 권한을 허용하거나 취소할 수 있습니다. + +
+ +M 미리 보기를 대상으로 하는 앱을 개발하는 경우, 권한 확인과 요청은 런타임에 해야 합니다. + 앱에 어떤 권한이 허용되었는지 판단하려면, 새로운 {@code Context.checkSelfPermission()} 메서드를 호출하면 됩니다. + 권한을 요청하려면 새 {@code Activity.requestPermission()} 메서드를 호출하세요. + 앱이 M을 대상으로 하지 않더라도, 앱을 새 권한 모델에서 테스트해보는 것이 좋습니다. +
+ +앱에서 새 권한 모델을 지원하는 방법에 대한 자세한 내용은 권한 개발자 미리 보기 페이지를 참조하세요. + + 앱에 미친 영향을 평가하는 방법에 대한 팁은 테스트 가이드를 참조하세요. +
+ +이 미리 보기에서는 유휴 상태의 기기 및 앱에 대한 새로운 절전 최적화 기능을 소개합니다.
+ +기기의 플러그가 뽑히고 화면이 꺼진 채로 일정 시간 동안 변화 없는 상태로 유지되면, Doze 상태로 들어갑니다. 이 상태에서는 기기가 시스템을 절전 모드 상태로 유지하려 시도합니다. + 이 모드에서 기기는 정기적으로 잠시 동안 정상 작동을 재개하여 앱 동기화가 일어날 수 있도록 하고 보류된 작업이 있으면 시스템이 이를 수행할 수 있도록 합니다. + +
+ +앱이 Doze 상태에 있는 동안 다음과 같은 제한 사항이 적용됩니다.
+기기가 Doze 모드를 종료하면 보류되어 있던 작업과 동기화를 모두 실행합니다.
+이 기능을 테스트하려면 개발 머신에 M 미리 보기를 실행하는 기기를 연결하여 다음과 같은 명령을 호출하면 됩니다. + +
++$ adb shell dumpsys battery unplug +$ adb shell dumpsys deviceidle step +$ adb shell dumpsys deviceidle -h ++
참고: 다가오는 Google Cloud 메시지 릴리스에서는 개발자에게 우선 순위가 높은 메시지를 지정하게 해줍니다. + + + 앱이 우선 순위가 높은 GCM 메시지를 수신하면 이 앱에는 기기가 Doze 모드에 있더라도 잠시 네트워크 액세스가 허용됩니다. + +
+ +앱에서 Doze를 테스트하는 방법에 대한 팁은 테스트 가이드를 참조하세요. + +
+ +이 미리 보기에서는 시스템이 보기에 앱이 활성 사용 중이 아닌 경우 해당 앱은 유휴 상태라고 판별할 수 있습니다. + 일정 시간이 지나면 앱이 유휴 상태인 것으로 간주되는데, 시스템이 다음과 같은 신호 중 하나를 감지하는 경우는 예외입니다. +
+ +기기의 플러그가 뽑혀 있는 경우, 유휴 상태인 것으로 간주된 앱은 자신의 네트워크 액세스를 비활성화하고 동기화와 작업을 일시 중단시킵니다. + 기기가 전원 공급 장치에 연결되면 이와 같은 앱에 네트워크 액세스가 허용되며 보류 중이었던 작업과 동기화를 모두 실행할 수 있습니다. + 기기가 오랜 시간 동안 유휴 상태인 경우, 유휴 앱에는 하루에 한 번 정도 네트워크 액세스가 허용됩니다. +
+ +이 기능을 테스트하려면 개발 머신에 M 미리 보기를 실행하는 기기를 연결하여 다음과 같은 명령을 호출하면 됩니다. + +
++$ 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> ++ +
참고: 다가오는 Google Cloud 메시지(GCM) 릴리스에서는 개발자에게 우선 순위가 높은 메시지를 지정할 수 있습니다. + + + 앱이 우선 순위가 높은 GCM 메시지를 수신하면 이 앱에는 앱이 유휴 상태에 있더라도 잠시 네트워크 액세스가 허용됩니다. + +
+ +앱에서 앱 대기 모드를 테스트하는 방법에 대한 팁은 테스트 가이드를 참조하세요. + +
+ ++이 미리 보기에서는 사용자가 SD 카드와 같은 외부 저장소 기기를 채택할 수 있습니다. 외부 저장소 기기를 채택하면 기기를 암호화하고 포맷하여 내부 저장소처럼 작동하도록 합니다. + 이 기능을 사용하면 사용자가 앱과 해당 앱의 비공개 데이터를 여러 저장소 기기 사이에서 이동시킬 수 있습니다. + 앱을 이동시키는 경우, 시스템은 매니페스트의 {@code android:installLocation} 기본 설정을 사용합니다. + + +
+ +앱이 다음과 같은 API 또는 필드에 액세스하는 경우, 앱이 내부 및 외부 저장소 기기 사이를 이동하면서 반환하는 파일 경로가 급격하게 달라진다는 점을 유의하세요. 파일 경로를 구축할 때에는 이와 같은 API를 항상 동적으로 호출하는 것을 강력히 권장합니다. 하드코드된 파일 경로를 사용하거나 이전에 구축된 정규화된 파일 경로를 유지하지 마세요. + + +
+ +개발자 미리 보기에서 이 기능을 디버그하려면, 다음 명령을 실행하여 USB On-The-Go(OTG) 케이블을 통해 Android 기기에 연결된 USB 드라이브 채택을 활성화하면 됩니다. +
+ ++$ adb shell sm set-force-adoptable true ++ +
이 미리 보기에서는 Apache HTTP 클라이언트에 대한 지원을 제거합니다. 앱이 이 클라이언트를 사용하고 Android 2.3(API 레벨 9) 이상을 대상으로 하는 경우, {@link java.net.HttpURLConnection} 클래스를 대신 사용하세요. + + 이는 투명한 압축과 응답 캐싱을 통해 네트워크 사용량을 줄이고 전력 소모를 최소화하기 때문에 API가 더 효율적입니다. + Apache HTTP API를 계속 사용하려면 우선 다음과 같은 컴파일-시간 종속성을 {@code build.gradle} 파일에서 선언해야 합니다. + +
+
+android {
+ useLibrary 'org.apache.http.legacy'
+}
+
+Android는 OpenSSL에서 BoringSSL 라이브러리로 옮겨갑니다. + + 앱에서 Android NDK를 사용하는 경우, NDK API의 일부분이 아닌 암호화 라이브러리에 대해 링크를 연결하지 마세요(예:{@code libcrypto.so} 및 {@code libssl.so}). + 이러한 라이브러리는 공개 API가 아니며, 여러 릴리스와 기기에 걸쳐 통보 없이 변경되거나 중단될 수 있으며 스스로를 보안 취약점에 노출시킬 수도 있습니다. + + 대신에 원래 코드를 수정하여 JNI를 통해 Java 암호화 API를 호출하도록 하거나, 직접 선택한 암호화 라이브러리에 대해 정적으로 연결하도록 하세요. + +
+ +볼륨을 직접 설정하거나 특정 스트림을 {@link android.media.AudioManager} 클래스를 통해 음소거하는 것은 이제 더 이상 지원되지 않습니다. + {@link android.media.AudioManager#setStreamSolo(int,boolean) +setStreamSolo()} 메서드는 사용이 중단되었으며, 그 대신 {@code AudioManager.requestAudioFocus()} 메서드를 호출해야 합니다. + 이와 마찬가지로, {@link android.media.AudioManager#setStreamMute(int,boolean) setStreamMute()} 메서드도 사용이 중단되었습니다. 그 대신 {@code AudioManager.adjustStreamVolume()} 메서드를 호출하고 방향 값 {@code ADJUST_MUTE} 또는 {@code ADJUST_UNMUTE}에서 전달해야 합니다. + + +
+ +
+
+사용자가 앱에서 텍스트를 선택하면 이제 텍스트 선택 작업을 표시할 수 있습니다. 예를 들어 잘라내기, 복사 및 붙여넣기를 부동 도구 모음으로 표시하게 됩니다. + + 이 사용자 상호작용 구현은 상황별 작업 모음에서와 비슷합니다. 이 내용은 각각의 보기에 대한 상황별 작업 모드의 활성화에 설명되어 있습니다. + + +
+ +텍스트 선택을 위해 부동 도구 모음을 구현하려면 기존 앱에 다음과 같은 변경을 적용하면 됩니다. +
+Android 지원 라이브러리 수정 버전 22.2를 사용하는 경우, 부동 도구 모음은 이전 버전과 호환되지 않으며 AppCompat이 기본적으로 {@link android.view.ActionMode} 객체의 제어권을 넘겨받는다는 점을 유의하세요. + + + 이렇게 하면 부동 도구 모음이 표시되지 않도록 방지합니다. {@link android.support.v7.app.AppCompatActivity}에서 {@link android.view.ActionMode}를 활성화하려면, {@code android.support.v7.app.AppCompatActivity.getDelegate()}를 호출한 다음 {@code android.support.v7.app.AppCompatDelegate.setHandleNativeActionModesEnabled()}를 반환된 {@link android.support.v7.app.AppCompatDelegate} 객체에서 호출하고 입력 매개변수를 {@code false}로 설정하세요. + + + + + + 이 호출은 {@link android.view.ActionMode} 객체의 제어권을 프레임워크에 돌려줍니다. + M 미리 보기를 실행하는 기기에서 이렇게 하면 프레임워크가 {@link android.support.v7.app.ActionBar} 또는 부동 도구 모음 모드를 지원할 수 있고, 한편 M 미리 보기 이전 기기에서는 {@link android.support.v7.app.ActionBar} 모드만 지원됩니다. + +
+ +이 미리 보기에서는 Android 키노트 제공자가 더 이상 DSA를 지원하지 않습니다. + + ECDSA는 여전히 지원됩니다.
+ +휴식 중일 때 암호화가 필요하지 않은 키도 보안 잠금 화면이 비활성화되거나 재설정될 때(예: 사용자가 또는 기기 관리자가 재설정) 더 이상 삭제되지 않습니다. + 휴식 중일 때 암호화가 필요한 키는 이러한 이벤트 중에 삭제됩니다. +
+ +이 미리 보기에서는 Wi-Fi와 네트워킹 API에 다음과 같은 동작 변경을 도입합니다.
+이 미리 보기에서는 카메라 서비스에서 공유된 리소스에 액세스하는 모델이 이전의 "선착순" 액세스 모델에서 바뀌어 우선 순위가 높은 프로세스를 선호하는 액세스 모델로 변경되었습니다. + + 서비스 동작에 대한 변경 내용은 다음과 같습니다.
+이제 ART 런타임이 {@link java.lang.reflect.Constructor#newInstance(java.lang.Object...) newInstance()} 메서드에 대한 액세스 규칙을 제대로 구현할 수 있습니다. + 이 변경 덕분에 이전 버전에서는 Dalvik이 액세스 규칙을 잘못 확인하던 문제를 해결했습니다. 앱이 {@link java.lang.reflect.Constructor#newInstance(java.lang.Object...) newInstance()} 메서드를 사용하고 액세스 확인을 재정의하고자 하는 경우, {@link java.lang.reflect.Constructor#setAccessible(boolean) setAccessible()} 메서드를 호출하되 입력 매개변수를 {@code true}로 설정한 상태로 사용합니다. + + + + + + 앱이 v7 AppCompat 라이브러리 또는 v7 RecyclerView 라이브러리를 사용하는 경우, 앱을 업데이트하여 이러한 라이브러리의 최신 버전을 사용하도록 해야 합니다. + + + 그렇지 않으면, XML에서 참조되는 모든 사용자 지정 클래스가 업데이트되도록 확인하여 그 클래스 생성자에 액세스할 수 있도록 해야 합니다. +
+ +이 미리 보기에서는 동적 링커의 동작을 업데이트합니다. 동적 링커는 이제 라이브러리의 {@code soname}과 그 경로(공개 버그 6670) 사이의 차이점을 숙지하고 있으며, 이제 {@code soname} 기준 검색도 구현되었습니다. + + + + 이전에 작동한 앱 중에서 {@code DT_NEEDED} 항목이 있는 경우(주로 빌드 머신의 파일 시스템에 있는 절대 경로) 로딩했을 때 실패할 수 있습니다. +
+ +이제 {@code dlopen(3) RTLD_LOCAL} 플래그를 올바르게 구현했습니다. 이때 {@code RTLD_LOCAL}이 기본이므로 {@code dlopen(3)}에 대한 호출 중에서 {@code RTLD_LOCAL}을 명시적으로 사용하지 않으면 영향받을 수 있다는 점을 유의하세요(다만 앱이 명시적으로 {@code RTLD_GLOBAL}을 사용한 경우는 예외입니다). + + {@code RTLD_LOCAL}의 경우, 나중에 {@code dlopen(3)}으로 한 호출로 인해 로딩된 라이브러리에서는 기호를 이용할 수 없게 됩니다({@code DT_NEEDED} 항목에 의해 참조된 것과는 반대입니다). + +
+ + +이제 플랫폼이 APK에 대해 좀 더 엄격한 유효성 검사를 수행합니다. APK는 파일이 매니페스트에서는 선언되었지만 APK 자체에는 없는 경우 손상된 것으로 간주됩니다. + 콘텐츠가 하나라도 제거되면 APK를 다시 서명해야 합니다. +
+ +이 미리 보기에는 Android for Work에 대해 다음과 같은 동작 변경을 포함합니다.
++ M 개발자 미리 보기에서는 새로운 앱 권한 모델을 소개하여 사용자가 앱을 설치하고 업그레이드하는 과정을 간소화할 수 있습니다. + M 미리 보기에서 실행되는 앱이 새 권한 모델을 지원하는 경우, 사용자가 앱을 설치하거나 업그레이드할 때 아무런 권한을 허용하지 않아도 됩니다. 그 대신, 앱이 필요할 때마다 권한을 요청하고 시스템이 사용자에게 해당 권한을 요청하는 대화창을 표시합니다. + + + + +
+ ++ 앱이 새 권한 모델을 지원하는 경우, Android 이전 버전을 실행하는 기기에서도 설치 및 실행할 수 있는 것은 변하지 않습니다. 이 경우, 그러한 기기의 기존 권한 모델을 사용합니다. + + +
+ ++ M 개발자 미리 보기에서는 플랫폼에 새로운 권한 모델을 도입합니다. + 이 새로운 모델의 주요 구성 요소를 다음과 같이 요약해 보았습니다. +
+ +CONTACTS 권한 그룹에는 사용자의 연락처와 프로필 정보를 읽고 쓰는 데 필요한 권한이 들어있습니다.
+
+
+ 설치 시점에 제한된 권한 허용: 사용자가 앱을 설치 또는 업데이트하면 시스템이 해당 앱에 앱이 요청하는 권한 중 {@link android.content.pm.PermissionInfo#PROTECTION_NORMAL PROTECTION_NORMAL}에 포함되는 것을 모두 허용합니다. + + + + 예를 들어 알람 시계와 인터넷 권한은 {@link android.content.pm.PermissionInfo#PROTECTION_NORMAL PROTECTION_NORMAL}에 속하므로 이들 권한은 설치 시점에 자동으로 허용됩니다. + + +
+ +시스템은 이외에도 앱 서명과 시스템 권한을 허용할 수도 있습니다. 이 내용은 시스템 앱 및 서명 권한에 설명되어 있습니다. + + 설치 시 사용자에게 권한을 허용하라는 메시지가 표시되지 않습니다. +
++ 이 권한 모델은 앱이 권한을 필요로 하는 기능에 대해 동작하는 방식을 바꾸어 놓습니다. + 다음은 이 모델에 적응하기 위한 몇 가지 개발 사례를 요약했습니다. + +
+ +
+ + 그림 1. 앱의 '설정'에 있는 권한 화면. +
++ 참고: 앱이 M 개발자 미리 보기를 대상으로 하는 경우, 반드시 새 권한 모델을 사용해야 합니다. + +
+ ++ M 개발자 미리 보기 시작 시점에는 Google 앱 중에 새 권한 모델을 완전히 구현하지 않는 앱도 있습니다. + Google은 이러한 앱을 M 개발자 미리 보기를 시행하면서 시간을 두고 업데이트하여 권한 설정/해제 설정을 제대로 사용하도록 할 예정입니다. + + +
+ ++ 참고: 앱에 자체 API 표면이 있는 경우, 권한을 대리로 허가하기 전에 우선 발신자에게 해당 데이터에 액세스할 필수 권한이 있는지 확인해야 합니다. + + +
+ ++ 보통 사용자가 앱을 설치하면 시스템이 앱에 {@link android.content.pm.PermissionInfo#PROTECTION_NORMAL PROTECTION_NORMAL}만 허용합니다. + + 하지만 시스템이 앱에 더 많은 권한을 허용하는 경우도 몇 가지 있습니다. + +
+ ++ 두 가지 경우 모두, 사용자가 언제든 권한을 취소할 수 있는 것은 변하지 않습니다. 시스템의 설정 화면으로 이동하여 앱 > + + app_name > 권한을 선택하면 됩니다. 이 앱은 계속해서 런타임에 권한을 확인하고 필요한 경우 해당 권한을 요청해야 합니다. + + +
+ ++ 앱이 M 개발자 미리 보기를 대상으로 하지 않더라도, 앱은 M 미리 보기 기기에서도 기존 권한 모델을 계속 사용합니다. + 사용자가 앱을 설치하면 시스템이 사용자에게 앱의 매니페스트에 목록으로 표시된 권한을 모두 허용하도록 요청합니다. + + +
+ ++ 참고: M 개발자 미리 보기를 실행하는 기기에서는 사용자가 어느 앱에 대해서든(레거시 앱 포함) 앱의 설정 화면에서 권한을 끌 수 있습니다. + + 사용자가 레거시 앱에 대한 권한을 끄면, 시스템이 자동으로 적절한 기능을 비활성화합니다. + 앱이 해당 권한을 필요로 하는 작업을 수행하려 시도한다고 해도 그 작업이 반드시 예외를 발생시키는 것은 아닙니다. + + 그 대신에 빈 데이터 세트를 반환하거나 오류를 신호하거나, 기타 예기치 못한 동작을 선보일 수 있습니다. + 예를 들어 권한 없이 캘린더를 쿼리하면 해당 메서드가 빈 데이터 세트를 반환합니다. + +
+ ++ M 미리 보기를 실행하지 않는 기기에서 새 권한 모델을 사용하는 앱을 설치하면 시스템은 해당 앱을 다른 앱과 똑같이 다룹니다. 즉, 설치 시점에 시스템에 사용자에게 선언된 권한 모두를 허용하도록 요청합니다. + + + +
+ ++ 참고: 미리 보기 릴리스에서는 최소 SDK 버전을 M 미리 보기 SDK로 설정해야 미리 보기 SDK와 컴파일할 수 있습니다. + 즉, 개발자 미리 보기 시행 중에는 그러한 앱을 기존 플랫폼에서 테스트할 수 없다는 뜻입니다. + + +
+ ++ 대부분의 경우, 앱에게 어떤 작업을 수행하도록 하려면 두 가지 방식 중 하나를 선택할 수 있습니다. + 첫째로 앱이 작업을 직접 수행하도록 권한을 요청할 수 있습니다. + 또는, 앱에 인텐트를 사용하도록 하여 또 다른 앱이 해당 작업을 수행하도록 할 수 있습니다. + +
+ +
+ 예를 들어 앱이 기기 카메라로 사진을 촬영할 수 있어야 한다고 가정합시다.
+ 그러면 앱은 android.permission.CAMERA 권한을 요청할 수 있습니다. 이렇게 하면 앱이 카메라에 직접 액세스할 수 있습니다.
+
+ 그런 다음 앱이 카메라 API를 사용하여 카메라를 제어하고 사진을 촬영합니다.
+ 이 방식을 사용하면 앱에 사진 촬영 과정에 대해 완전한 제어권을 부여하고, 카메라 UI를 앱에 통합할 수 있습니다.
+
+
+
+ 하지만, 그러한 제어권이 필요하지 않은 경우라면 그저 {@link android.provider.MediaStore#ACTION_IMAGE_CAPTURE ACTION_IMAGE_CAPTURE} 인텐트를 사용해 이미지를 요청하면 됩니다. + + 이 인텐트를 시작하면 사용자에게 카메라 앱을 선택하라는 메시지가 표시되고(기본 카메라 앱이 이미 있는 경우) 그 앱이 사진을 촬영합니다. + + 이 카메라 앱은 촬영한 사진을 개발자의 앱의 {@link android.app.Activity#onActivityResult onActivityResult()} 메서드에 반환합니다. + +
+ ++ 이와 마찬가지로, 전화를 걸어야 하거나 사용자의 연락처에 액세스해야 하는 경우 등에는 적절한 인텐트를 만들거나 적절한 객체에 직접 액세스하도록 권한을 요청할 수 있습니다. + + 이 두 가지 방식에는 각각 장단점이 있습니다. + +
+ ++ 권한을 사용하는 경우: +
+ ++ 인텐트를 사용하는 경우: +
+ ++ 새로운 M 개발자 미리 보기를 대상으로 앱을 개발하는 경우, 새 권한 모델을 사용해야 합니다. + 이는 즉, 매니페스트에 필요한 권한을 선언하는 것 말고도 런타임에 자신이 해당 권한을 가지고 있는지도 확인해야 하며, 그러한 권한을 이미 가지고 있지 않으면 권한을 요청해야 한다는 뜻입니다. + + + +
+ +
+ 새로운 M 개발자 미리 보기 권한 모델을 활성화하려면 앱의 targetSdkVersion 특성을 "MNC"로 설정하고, compileSdkVersion은 "android-MNC"로 설정하세요.
+
+ 이렇게 하면 새 권한 기능이 모두 활성화됩니다.
+
+
+ 미리 보기 릴리스에서는 minSdkVersion을 "MNC"로 설정해야만 미리 보기 SDK와 컴파일할 수 있습니다.
+
+
+ 새 <uses-permission-sdk-m> 요소를 앱 매니페스트에 사용하여 권한이 M 개발자 미리 보기에서만 필요하다는 것을 나타낼 수 있습니다.
+ 권한을 이런 식으로 선언하면 앱이 이전 버전의 기기에 설치될 때마다 시스템에서 사용자에게 메시지를 표시하지도 않고 앱에 권한을 허용하지도 않습니다. <uses-permission-sdk-m> 요소를 사용하면 새 권한을 앱의 업데이트된 버전에 추가하면서도 사용자가 업데이트를 설치할 때 권한을 허용하라고 강제로 시키지 않아도 됩니다.
+
+
+
+
+
+
+
+ 앱이 M 개발자 미리 보기를 갖춘 기기에서 실행되는 경우, <uses-permission-sdk-m>은 <uses-permission>과 똑같이 동작합니다.
+
+
+ 시스템은 사용자가 앱을 설치할 때 권한을 허용하라는 메시지를 표시하지 않고, 앱이 필요할 때마다 권한을 요청하게 됩니다.
+
+
+ 앱이 새로운 M 개발자 미리 보기 권한 모델을 사용하는 경우, 앱이 M 미리 보기에서 실행되는 기기에서 처음 시작되었을 때 사용자에게 모든 권한을 허용하도록 요청하지 않습니다. + + 대신, 앱은 필요할 때마다 권한을 요청합니다. + 앱이 권한을 요청하면 시스템이 사용자에게 대화창으로 표시합니다. + +
+ +
+ 앱이 SDK 22 이하를 탑재한 기기에서 실행되는 경우, 앱은 기존 권한 모델을 사용합니다.
+ 사용자가 앱을 설치하면 앱이 자신의 매니페스트에서 요청하는 모든 권한을 허용하라는 메시지가 표시되는데, 이때 <uses-permission-sdk-m>이라는 레이블이 붙은 권한은 예외입니다.
+
+
+
+ 이 권한 모델은 M 개발자 미리 보기를 실행하는 기기에서만 지원됩니다.
+ 이러한 메서드 중에서 호출하려면 앱은 우선 {@link android.os.Build.VERSION#CODENAME Build.VERSION.CODENAME} 값을 확인하여 자신이 어느 플랫폼에서 실행 중인지 확인해야 합니다.
+
+
+ 기기가 M 개발자 미리 보기에서 실행 중인 경우, {@link android.os.Build.VERSION#CODENAME CODENAME}은 "MNC"입니다.
+
+
사용자가 권한을 필요로 하는 무언가를 하려고 시도하면, 앱은 자신이 현재 이 작업을 수행하는 데 필요한 권한을 가지고 있는지 확인합니다.
+ 이렇게 하기 위해 앱은 Context.checkSelfPermission( )을 호출합니다.
+
+permission_name 사용자가 앱의 권한을 언제든 취소할 수 있기 때문에 앱은 사용자가 해당 권한을 이미 허용했다는 것을 알고 있더라도 확인 작업을 수행해야 합니다.
+
+
+ 예를 들어, 사용자가 사진 촬영 앱을 사용하고자 한다면 앱은 Context.checkSelfPermission(Manifest.permission.CAMERA)를 호출합니다.
+
+
+ 표 1. 권한과 권한 그룹.
+| 권한 그룹 | +권한 | +
|---|---|
android.permission-group.CALENDAR |
+
+
|
+
android.permission-group.CAMERA |
+
+
|
+
android.permission-group.CONTACTS |
+
+
|
+
android.permission-group.LOCATION |
+
+
|
+
android.permission-group.MICROPHONE |
+
+
|
+
android.permission-group.PHONE |
+
+
|
+
android.permission-group.SENSORS |
+
+
|
+
android.permission-group.SMS |
+
+
|
+
앱이 자신에게 필요한 권한을 이미 가지고 있지 않은 경우, 앱은 Activity.requestPermissions(String[], int) 메서드를 호출하여 적절한 권한(여러 개일 수 있음)을 요청합니다.
+
+ 앱은 원하는 권한을 요청하면서 정수 "요청 코드"를 요청합니다.
+
+ 이 메서드는 비동기화 방식으로 기능합니다. 이는 즉각적으로 반환되며, 사용자가 대화 상자에 응답한 다음에는 시스템이 결과를 가지고 앱의 콜백 메서드를 호출하여 앱이 requestPermissions()에 전달한 "요청 코드"와 같은 코드를 전달합니다.
+
+
+
다음 코드는 앱에 사용자의 연락처를 읽을 권한이 있는지 코드 확인을 하고, 필요한 경우 해당 권한을 요청합니다. +
+ +
+if (checkSelfPermission(Manifest.permission.READ_CONTACTS)
+ != PackageManager.PERMISSION_GRANTED) {
+ requestPermissions(new String[]{Manifest.permission.READ_CONTACTS},
+ MY_PERMISSIONS_REQUEST_READ_CONTACTS);
+
+ // MY_PERMISSIONS_REQUEST_READ_CONTACTS is an
+ // app-defined int constant
+
+ return;
+}
+
+
+
+ 앱이 권한을 요청하면 시스템이 사용자에게 대화 상자를 표시합니다.
+ 사용자가 응답하면 시스템은 앱의 Activity.onRequestPermissionsResult(int, String[], int[])를 불러내 이를 사용자 응답에 전달합니다.
+
+ 앱은 해당 메서드를 재정의해야 합니다. 이 콜백에는 개발자가 requestPermissions()에 전달한 것과 같은 요청 코드가 전달됩니다.
+
+ 예를 들어 어느 앱이 READ_CONTACTS 액세스를 요청한다면 다음과 같은 콜백 메서드를 가지고 있을 수 있습니다.
+
+
+
+@Override
+public void onRequestPermissionsResult(int requestCode,
+ String permissions[], int[] grantResults) {
+ switch (requestCode) {
+ case MY_PERMISSIONS_REQUEST_READ_CONTACTS: {
+ if (grantResults[0] == PackageManager.PERMISSION_GRANTED) {
+
+ // permission was granted, yay! do the
+ // calendar task you need to do.
+
+ } else {
+
+ // permission denied, boo! Disable the
+ // functionality that depends on this permission.
+ }
+ return;
+ }
+
+ // other 'switch' lines to check for other
+ // permissions this app might request
+ }
+}
+
+
+ 사용자가 권한을 허용하면 시스템은 앱 매니페스트에 그 기능 영역에 대해 목록으로 표시된 모든 권한을 해당 앱에 부여합니다. + 사용자가 요청을 거부하면 적절한 조치를 취해야 합니다. + 예를 들어 이 권한에 좌우되는 메뉴 작업을 모두 비활성화할 수 있습니다. + + +
+ +
+ 시스템이 사용자에게 권한을 허용하도록 요청하면 사용자에게는 시스템에 해당 권한을 다시 요청하지 말라고 지시할 선택권이 있습니다.
+ 그런 경우, 앱이 해당 권한을 요청하기 위해 requestPermissions()를 사용하면 시스템이 즉시 요청을 거부합니다.
+
+ 이 경우 시스템은 사용자가 명시적으로 개발자의 요청을 다시 거부한 것처럼 onRequestPermissionsResult()를 호출합니다.
+
+ 이러한 이유로, 앱은 사용자와의 직접적인 상호작용이 일어났다고 가정해서는 안 됩니다.
+
+
+ M 개발자 미리 보기를 대상으로 삼고 앱을 개발하는 경우, 이 앱이 권한을 적절하게 처리하는지 테스트해보아야 합니다. + 앱이 실행될 때 특정 권한을 가지고 있다고 가정해서는 안 됩니다. + 앱을 처음 시작할 때에는 아무런 권한도 없을 가능성이 높고, 사용자가 언제든 권한을 취소하거나 복원할 수 있기 때문입니다. + + +
+ ++ 앱을 테스트하여 모든 권한 관련 상황에서 제대로 작동하는지 확인하는 것이 좋습니다. + M 미리 보기 SDK에서는 새로운 Android 디버그 브리지(adb) 명령을 제공하여 여러분이 시도해 보아야 하는 권한 설정이 무엇이든 앱을 테스트할 수 있도록 하였습니다. + + + +
+ ++ M 미리 보기 SDK 플랫폼 도구에서는 여러 가지 새로운 명령을 제공하여 앱이 권한을 처리하는 방식을 테스트해볼 수 있습니다. + +
+ +
+ adb
+ install 명령의 새로운 -g 선택 항목을 사용하면 앱을 설치하고 해당 앱의 매니페스트에 목록으로 표시된 모든 권한을 허용합니다.
+
+
+$ adb install -g <path_to_apk> ++ +
+ 새로운 ADB 패키지 관리자(pm) 명령을 사용하면 설치된 앱에 권한을 허용하고 취소할 수 있습니다. 이 기능은 자동화 설정에서 유용하게 쓰일 수 있습니다. + + +
+ +
+ 권한을 허용하려면, 패키지 관리자의 grant 명령을 사용하세요.
+
+$ adb pm grant <package_name> <permission_name> ++ +
+ 예를 들어 com.example.myapp 패키지 권한을 허용하여 오디오를 녹음하려면 이 명령을 사용하면 됩니다. + +
+ ++$ adb pm grant com.example.myapp android.permission.RECORD_AUDIO ++ +
+ 권한을 취소하려면, 패키지 관리자의 revoke 명령을 사용하세요.
+
+$ adb pm revoke <package_name> <permission_name> ++ +
+ 새 권한 모델을 사용하면 사용자에게 보다 원활한 환경을 제공하고, 앱을 더욱 쉽게 설치하며 앱이 어떤 작업을 하고 있는지 바로 확인할 수 있습니다. + + 새 모델의 장점을 최대한 활용할 수 있도록 다음과 같은 모범 사례를 추천해 드립니다. + +
+ + ++ 권한을 요청할 때마다 사용자에게는 결정을 내리라는 강요를 하는 셈입니다. + 사용자가 요청을 거절하면 앱의 기능이 저하됩니다. + 때문에 이러한 요청을 하는 횟수를 최소한으로 줄이는 것이 좋습니다. +
+ ++ 예를 들어 앱이 권한을 요청하는 대신 인텐트를 사용해 필요한 기능을 얻을 수 있는 경우도 꽤 많습니다. + + 앱이 전화기의 카메라를 사용해 사진을 촬영해야 하는 경우, 앱은 {@link android.provider.MediaStore#ACTION_IMAGE_CAPTURE MediaStore.ACTION_IMAGE_CAPTURE} 인텐트를 사용할 수 있습니다. + + + 앱이 인텐트를 실행하면 시스템이 사용자에게 메시지를 표시해 이미 설치된 카메라 앱을 선택하여 사진을 촬영하도록 합니다. + + +
+ ++ 사용자에게 엄청나게 많은 수의 권한 요청을 한꺼번에 들이밀면 사용자가 부담을 느끼고 앱을 종료해버리는 결과를 초래할 수 있습니다. 대신 권한이 필요할 때마다 요청하는 것이 좋습니다. + + +
+ ++ 일부 경우에는 앱에 절대적으로 꼭 필요한 권한이 한 개 이상 있을 수도 있습니다. 그런 경우에는 앱이 시작되자마자 해당 권한을 모두 요청하는 것을 권장합니다. + + 예를 들어 사진 앱을 만들면 앱이 기기 카메라로 액세스할 수 있는 권한이 필요합니다. + 사용자가 앱을 처음으로 시작할 때 카메라를 사용할 권한을 요청받아도 놀라지는 않을 것입니다. + + 하지만 같은 앱에 사용자의 연락처과 사진을 공유하는 기능도 있다고 가정한다면 이 경우 해당 권한을 첫 시작 시점에 요청하는 것은 별로 권장할 만한 일이 아닙니다. + + 대신, 사용자가 "공유" 기능을 요청하려 할 때까지 기다렸다가 그 때 해당 권한을 요청하면 됩니다. + +
+ ++ 앱이 튜토리얼을 제공하는 경우, 튜토리얼 시퀀스가 다 끝날 무렵에 앱의 필수 권한을 요청하는 것이 이치에 맞을 수 있습니다. + +
+ +
+ 개발자가 requestPermissions()를 호출하면 시스템이 표시하는 권한 대화창에는 앱이 원하는 권한이 무엇인지는 나타나 있지만 그것이 필요한 이유는 설명하지 않습니다.
+
+ 사용자가 이런 것을 의아하게 여기는 경우가 있을 수 있습니다.
+ 우선 사용자에게 앱이 왜 그런 권한을 원하는지 설명한 다음 requestPermissions()를 호출하는 것이 좋습니다.
+
+
+ 예를 들어 사진 앱인 경우 위치 서비스를 이용하고자 할 수 있습니다. 그래야 사진에 지오태그를 표시할 수 있기 때문입니다.
+ 일반적인 사용자는 사진에 위치 정보를 담을 수 있다는 점을 모를 수도 있고, 그러면 사진 앱이 왜 위치를 알고 싶어 하는지 의아하게 여길 수 있습니다.
+
+ 그러므로 이런 경우에는 앱이 사용자에게 이런 기능에 대해 미리 알려드린 후 requestPermissions()를 호출하는 것이 좋습니다.
+
+
+
+ 이를 수행하기 위한 한 가지 방법은 이러한 요청을 앱 튜토리얼에 넣는 것입니다. 튜토리얼에는 앱의 각 기능을 표시할 수 있고, 그러면서 어느 권한이 필요한지 설명할 수도 있기 때문입니다.
+
+ 예를 들어 사진 앱의 튜토리얼에서 "연락처 목록의 지인들과 사진 공유" 기능을 시연한 다음 사용자에게 앱이 사용자의 연락처를 보려면 권한을 부여해야 한다고 알리면 됩니다.
+
+
+ 그런 다음, 앱이 requestPermissions()를 호출하여 사용자에게 해당 액세스를 요청합니다.
+ 물론 튜토리얼을 따르지 않는 사용자도 있게 마련이므로 앱의 정상 작동 중에 권한을 확인하고 요청해야 합니다.
+
+
+
+ Android M 개발자 미리 보기를 시작하신 여러분, 환영합니다. 이 프로그램은 Android의 다음 버전에 대해 앱을 테스트하고 최적화하는 데 필요한 모든 것을 제공해 드립니다. + + 이 프로그램은 무료이며, M 개발자 미리 보기 도구만 다운로드하면 시작하실 수 있습니다. + +
+ ++ Nexus 5, 6, 9, Player(TV용)와 에뮬레이터에서 앱을 실행하고 테스트해 보세요. + +
++ 미리 보기 시행 중에 여러 번의 업데이트를 제공할 예정입니다. 이로써 여러분은 항상 최신 플랫폼 변경에 대해 테스트할 수 있습니다. + +
++ 일단 기기를 최초 미리 보기에 플래시하고 나면 OTA로 업데이트를 받을 수 있습니다. + +
++ 작업을 일찍 시작하여 새 런타임 권한 모델과 절전 기능 등 새로운 플랫폼 동작을 지원합니다. + +
++ Google에서는 처음 몇 주 동안 개발자가 보고한 문제에 우선 순위를 부여할 예정입니다. 가능한 빨리 테스트하고 피드백을 보내 주세요. + +
++ 문제를 보고하고 Google의 문제 추적기를 사용해 피드백을 보내 주세요. + M 개발자 커뮤니티를 이용하면 다른 개발자들과 의견을 주고받을 수 있습니다. + +
+
++ M 개발자 미리 보기는 5월 28일부터 최종 Android M SDK가 출시될 때까지 실행됩니다. 최종 버전은 2015년 3사분기 중으로 예정된 공개 릴리스 직전에 출시할 계획입니다. + + +
+ ++ 개발 중 중요 단계에 다다를 때마다 여러분의 테스트 기기를 위해 업데이트를 전달해 드리겠습니다. + 잠정적인 중요 단계는 다음과 같습니다. +
+ ++ 이러한 업데이트는 최종 SDK(3사분기 후반)로 막을 내릴 것이며, 이것으로 Android 새 버전에 대한 공식 API뿐만 아니라 최종 시스템 동작 및 기능도 제공하게 됩니다. + + +
+ ++ Android M에서 테스트와 개발을 수행하는 동안 미리 보기 업데이트가 출시되는 것에 맞춰 개발 환경을 최신 상태로 유지할 것을 강력히 권장합니다. + + 이 과정을 보다 단순화하기 위해 이미 미리 보기 빌드에 플래시한 기기에는 OTA(over-the-air) 업데이트를 제공할 예정이며, 이외에도 수동으로 다운로드하고 플래시할 수 있는 시스템 이미지도 제공할 계획입니다. + + +
++ 참고: 최종 SDK와 시스템 이미지는 OTA로 전달할 수 없습니다. 그 대신 개발자 본인의 테스트 기기에서 수동으로 플래시해야 합니다. + + +
+ ++ 미리 보기 업데이트를 이용할 수 있게 될 때마다 Android 개발자 블로그, 해당 사이트 및 Android M 개발자 커뮤니티를 통해서 알려드릴 것입니다. + + +
+ ++ M 개발자 미리 보기에는 기존 앱을 여러 가지 화면 크기, 네트워크 기술, CPU/GPU 칩세트 및 하드웨어 아키텍처에서 테스트하는 데 필요한 모든 것이 포함되어 있습니다. + + +
+ ++ 이러한 구성 요소는 Android Studio에서 SDK Manager를 통해 다운로드할 수 있습니다. +
+ ++ Nexus 기기에 대한 다음과 같은 하드웨어 시스템 이미지는 다운로드 페이지에서 다운로드할 수 있습니다. + +
+ ++ 다음과 같은 관련 문서 리소스는 미리 보기에 대해 익히는 데 유용합니다. +
+ ++ M 개발자 미리 보기에서 테스트하고 개발하는 데 유용한 지원 리소스를 소개합니다. + +
+ +
+ Android M 개발자 미리 보기는 개발 전용 릴리스이며 표준 API 레벨이 없습니다.
+ 앱을 테스트하기 위해 호환성 동작에서 옵트아웃하고자 하는 경우(강력히 권장함), M 개발자 미리 보기를 대상으로 지정하면 됩니다. 앱의 targetSdkVersion을 “MNC”로 지정하세요.
+
+
+
+
+ Android M 개발자 미리 보기에서는 미리 보기 API를 제공합니다. —이 API는 최종 SDK가 출시될 때까지 공식적인 버전으로 인정되지 않습니다. 최종 SDK 릴리스는 현재 2015년 삼사분기 무렵으로 예정되어 있습니다. + + 이는 즉, 시간이 지나면서 사소한 API 변경이 있을 것이라는 점을 예상해야 한다는 뜻입니다. 특히 프로그램 초반 몇 주 동안은 유의해야 합니다. + + Android M 개발자 미리 보기를 업데이트할 때마다 변경 내용을 요약해서 제공해 드릴 것입니다. + +
+ ++ 미리 보기 API는 변경될 수 있지만, 런타임 권한과 절전 기능과 같은 기본 시스템 동작은 안정적이며 지금 바로 테스트 가능한 상태입니다. + + +
+ ++ 게시에 관해서는, Google Play에서는 M 개발자 미리 보기를 대상으로 삼는 앱의 게시를 방지합니다. + Android M 최종 SDK를 이용할 수 있게 되면 공식 Android M API 레벨을 대상으로 지정할 수 있고, 그때 Google Play에 앱을 게시하면 됩니다. + + 그때까지는 테스터들에게 Android M을 대상으로 지정한 앱을 배포하고자 하는 경우 이메일이나 본인의 사이트에서 직접 다운로드를 통해 하시면 됩니다. + + +
+ ++ 앱 테스트를 시작하려면 +
+ ++ Android M 개발자 미리 보기 프로그램에 참가해 주셔서 대단히 감사합니다! +
diff --git a/docs/html-intl/intl/pt-br/preview/api-overview.jd b/docs/html-intl/intl/pt-br/preview/api-overview.jd new file mode 100644 index 0000000000000..33e8c1f6f46fd --- /dev/null +++ b/docs/html-intl/intl/pt-br/preview/api-overview.jd @@ -0,0 +1,521 @@ +page.title=Visão geral da API +page.keywords=preview,sdk,compatibility +page.tags=previewresources, androidm +sdk.platform.apiLevel=22-mnc +page.image=images/cards/card-api-overview_16-9_2x.png +@jd:body + + +O M Developer Preview fornece uma visualização avançada no próximo lançamento + para a plataforma Android, oferecendo novos recursos para desenvolvedores e usuários +de aplicativos. Este documento fornece uma introdução às APIs mais notáveis.
+ +O M Developer Preview foi feito para novos desenvolvedores +adotantes e testadores. Caso tenha interesse + em influenciar a direção da estrutura do Android, +experimente o M Developer + Preview e envie-nos feedback!
+ +Cuidado: não publique aplicativos +que usam o M Developer Preview na Google Play Store.
+ +Observação: este documento frequentemente +menciona classes e métodos que ainda não possuem material de referência disponível em developer.android.com. Esses elementos de API +são formatados em {@code code style} neste documento (sem hyperlinks). Para a +documentação de API preliminar destes elementos, faça o download da referência da prévia.
+ +Caso tenha publicado anteriormente um aplicativo para Android, saiba que ele pode ser afetado +pelas alterações na plataforma.
+ +Consulte alterações de comportamento para obter mais informações.
+ +Esta prévia aprimora o sistema de intenções do Android fornecendo vínculo de aplicativo mais poderoso. +Este recurso permite que você associe um aplicativo com um domínio de web próprio. Com base nesta +associação, a plataforma pode determinar o aplicativo padrão a ser usado para lidar com um link da web +em particular e ignorar a solicitação aos usuários para selecionar um aplicativo. Para aprender como implementar este aplicativo, consulte +vínculo de aplicativo. + +
O sistema agora realiza backup automático completo de dados e restauração para aplicativos. Este comportamento +é ativado por padrão para aplicativos com M Preview; não é necessário mais código adicional. Se +os usuários excluírem as contas da Google, os dados de backup também serão excluídos. Para aprender como este recurso +funciona e como configurar o backup no sistema do arquivo, consulte +backup automático para aplicativos.
+ +Esta prévia oferece novas APIs para permitir que você autentique os usuários usando digitalizadores de impressão digital em dispositivos +suportados e verifique o quão recentemente os usuários autenticaram pela última vez usando o +mecanismo de desbloqueio por dispositivo (como senha de tela de bloqueio). Use essas APIs em conjunto com +o sistema Android Keystore.
+ +Para autenticar os usuários por meio de digitalização de impressão digital, adquira uma instância da nova classe +{@code android.hardware.fingerprint.FingerprintManager} e chame o método +{@code FingerprintManager.authenticate()}. O aplicativo deve ser executado em um dispositivo +compatível com sensor de impressão digital. Deve-se implementar a interface do usuário para o fluxo de autenticação +de impressão digital no aplicativo e usar o ícone de impressão digital padrão do Android na IU. +O ícone de impressão digital do Android ({@code c_fp_40px.png}) é incluído no +aplicativo de exemplo. Caso esteja desenvolvendo vários aplicativos que usam +autenticação de impressão digital, observe que cada aplicativo deve autenticar a impressão digital do usuário independentemente. +
+ +Para usar este recurso no aplicativo, adicione primeiro a permissão {@code USE_FINGERPRINT} no +manifesto.
+ ++<uses-permission + android:name="android.permission.USE_FINGERPRINT" /> ++ +
+
+Para ver a implementação do aplicativo da autenticação com impressão digital, consulte o + + exemplo de caixa de diálogo de impressão digital.
+ +Caso esteja testando este recurso, siga estas etapas:
++adb -e emu finger touch <finger_id> ++
No Windows, talvez seja necessário executar {@code telnet 127.0.0.1 <emulator-id>} seguido de +{@code finger touch <finger_id>}. +
+O aplicativo pode autenticar os usuários com base no quão recentemente o dispositivo foi desbloqueado pela última vez. Este +recurso libera o usuário de ter que lembrar de senhas específicas de aplicativo extras e evita +a necessidade de implementar a própria interface do usuário de autenticação. O aplicativo deve usar este recurso +em conjunto com uma implementação de chave secreta ou pública para a implementação de usuário.
+ +Para definir uma duração de tempo limite em que a mesma chave pode ser usada novamente +após o usuário autenticar, chame o novo método +{@code android.security.keystore.KeyGenParameterSpec.setUserAuthenticationValidityDurationSeconds()} + ao definir um {@link javax.crypto.KeyGenerator} ou +{@link java.security.KeyPairGenerator}. Este recurso funciona para operações criptográficas +simétricas.
+ +Evite exibir o diálogo de nova autenticação excessivamente — os aplicativos devem tentar +usar o objeto criptográfico primeiro e, se o tempo limite expirar, usar o método +{@link android.app.KeyguardManager#createConfirmDeviceCredentialIntent(java.lang.CharSequence, java.lang.CharSequence) createConfirmDeviceCredentialIntent()} + para autenticar novamente o usuário dentro do aplicativo. +
+ +Para ver uma implementação de aplicativo deste recurso, consulte o + +exemplo de confirmação de credencial.
+ +
+
+Esta prévia fornece as APIs para tornar o compartilhamento intuitivo e rápido para os usuários. É possível +definir os alvos de compartilhamento direto que iniciam uma atividade específica no aplicativo. +Esses alvos de compartilhamento direto são expostos aos usuários por meio do menu Compartilhar. Este recurso permite que os usuários +compartilhem conteúdos aos alvos, como contatos, dentro de outros aplicativos. Por exemplo: o alvo de compartilhamento direto +pode iniciar uma atividade em outro aplicativo de rede social, o que permite que o usuário compartilhe o conteúdo diretamente +para um amigo ou comunidade específica neste aplicativo.
+ +Para ativar os alvos de compartilhamento direto, deve-se definir uma classe que estende a classe
+{@code android.service.}
+{@code chooser.ChooserTargetService}. Declare o
+{@code ChooserTargetService} no manifesto. Dentro desta declaração, especifique a permissão
+{@code BIND_CHOOSER_TARGET_SERVICE} e um filtro de intenções na ação
+{@code SERVICE_INTERFACE}.
O seguinte exemplo mostra como se deve declarar o {@code ChooserTargetService} no +manifesto.
++<service android:name=".ChooserTargetService" + android:label="@string/service_name" + android:permission="android.permission.BIND_CHOOSER_TARGET_SERVICE"> + <intent-filter> + <action android:name="android.service.chooser.ChooserTargetService" /> + </intent-filter> +</service> ++ +
Para cada atividade que quiser expor ao {@code ChooserTargetService}, adicione um elemento +{@code <meta-data>} com o nome +{@code "android.service.chooser.chooser_target_service"} no manifesto do aplicativo. +
+ ++<activity android:name=".MyShareActivity” + android:label="@string/share_activity_label"> + <intent-filter> + <action android:name="android.intent.action.SEND" /> + </intent-filter> +<meta-data + android:name="android.service.chooser.chooser_target_service" + android:value=".ChooserTargetService" /> +</activity> ++ +
+Esta prévia fornece uma API de interação por voz que, junto com +ações de voz +, permite a criação de experiências por voz nos aplicativos. Chame o método +{@code android.app.Activity.isVoiceInteraction()} para determinar se a atividade +foi iniciada em resposta à ação de voz. Caso tenha sido iniciada, o aplicativo pode usar a classe +{@code android.app.VoiceInteractor} para solicitar uma confirmação de voz do usuário, +selecionar a partir de uma lista de opções e muito mais. Para aprender mais sobre a implementação de ações de voz, consulte +o site de desenvolvedor de ações de voz. +
+ ++Esta prévia oferece uma nova maneira de usuários se envolverem com os aplicativos com um assistente. Para usar este +recurso, o usuário deve possibilitar que o assistente use o contexto atual. Quando ativado, +o usuário pode invocar um assistente dentro de qualquer aplicativo mantendo o botão Iniciar pressionado.
+O aplicativo pode optar por não compartilhar o contexto atual com o assistente configurando o sinalizador +{@link android.view.WindowManager.LayoutParams#FLAG_SECURE}. Além do conjunto +padrão de informações que a plataforma passa ao assistente, o aplicativo pode compartilhar +informações adicionais usando a nova classe {@code android.app.Activity.AssistContent}.
+ +Para fornecer ao assistente contexto adicional do aplicativo, siga estas etapas:
+ +Esta prévia adiciona as seguintes alterações de API às notificações:
+Esta prévia fornece um suporte aprimorado para a entrada de usuário usando um Bluetooth Stylus. Os usuários podem +parear e conectar um Bluetooth Stylus compatível com o telefone ou tablet. Quando conectado, as informações +de posição da tela tátil são fundidas com as informações de botão e pressão do Stylus +para fornecer um alcance maior de expressão em comparação à tela tátil sozinha. O aplicativo pode escutar o pressionar +de botões do Stylus e realizar ações secundárias registrando os novos retornos de chamada +{@code View.onStylusButtonPressListener} e {@code GestureDetector.OnStylusButtonPressListener} + na atividade.
+ +Use as constantes e os métodos {@link android.view.MotionEvent} para detectar as interações +de botão do Stylus:
++Se o aplicativo realizar digitalizações de baixa energia por Bluetooth, é possível usar o novo método +{@code android.bluetooth.le.ScanSettings.Builder.setCallbackType()} para especificar +que você quer que os retornos de chamada sejam notificados apenas quando um pacote de propaganda correspondente ao conjunto +{@link android.bluetooth.le.ScanFilter} for encontrado primeiro e quando +ele não for visto por um período. Esta abordagem de digitalização é mais eficiente +do que a fornecida na versão anterior da plataforma. +
+ ++Esta prévia adiciona suporte ao Hotspot 2.0 Release 1 nos dispositivos Nexus 6 e Nexus 9. Para fornecer +as credenciais de Hotspot 2.0 no aplicativo, use os novos métodos da classe +{@link android.net.wifi.WifiEnterpriseConfig}, como {@code setPlmn()} e +{@code setRealm()}. No objeto {@link android.net.wifi.WifiConfiguration}, é possível definir os campos +{@link android.net.wifi.WifiConfiguration#FQDN} e {@code providerFriendlyName}. +A nova propriedade {@code ScanResult.PasspointNetwork} indica se uma rede detectada representa +um ponto de acesso Hotspot 2.0. +
+ +A plataforma agora permite que aplicativos solicitem que a resolução seja aprimorada para renderização 4K +em hardware compatível. Para consultar a resolução física atual, use as novas APIs +{@code android.view.Display.Mode}. Se a IU for desenhada em uma resolução lógica +menor e for redimensionada para uma resolução física maior, saiba que a resolução física que o método +{@code Display.Mode.getPhysicalWidth()} retorna pode ser diferente da resolução +física informada por {@link android.view.Display#getSize(android.graphics.Point) getSize()}.
+ +É possível solicitar que o sistema altere a resolução física no aplicativo à medida que ele é executado configurando +a propriedade {@code WindowManager.LayoutParams.preferredDisplayModeId} da janela do aplicativo. Este +recurso é útil se quiser alternar para a resolução de exibição 4K. Enquanto estiver no modo de exibição 4K, +a IU continua a ser renderizada na resolução original (como 1080 p) e é escalonada para 4K, mas os objetos +{@link android.view.SurfaceView} podem exibir o conteúdo na resolução nativa.
+ +Os atributos de tema agora são suportados no +{@link android.content.res.ColorStateList} para dispositivos que executam o M Preview. Os métodos +{@link android.content.res.Resources#getColorStateList(int) getColorStateList()} e +{@link android.content.res.Resources#getColor(int) getColor()} ficaram obsoletos. Caso esteja chamando +essas APIs, chame os novos métodos {@code Context.getColorStateList()} ou +{@code Context.getColor()}. Esses métodos também estão disponíveis na biblioteca +v4 appcompat via {@link android.support.v4.content.ContextCompat}.
+ +Esta prévia adiciona aprimoramentos ao processamento de áudio no Android, incluindo:
+Esta prévia adiciona novas capacidades às APIs de processamento de vídeo, incluindo:
+Esta prévia inclui as seguintes novas APIs para acessar a lanterna da câmera +e para o reprocessamento da câmera de imagens:
+ +Se um dispositivo de câmera tem uma unidade de flash, é possível chamar o método {@code CameraManager.setTorchMode()} +para ligar ou desligar o modo de tocha da unidade de flash sem abrir o dispositivo da câmera. O aplicativo +não tem propriedade exclusiva da unidade de flash ou do dispositivo de câmera. O modo de tocha é desativado +e torna-se indisponível sempre que o dispositivo de câmera estiver indisponível ou quando outros +recursos de câmera que mantêm a tocha ativada ficam indisponíveis. Outros aplicativos também podem chamar {@code setTorchMode()} +para desativar o modo de tocha. Quando o aplicativo que ativou o modo +de tocha for fechado, o modo é desativado.
+ +É possível registrar um retorno de chamada para ser notificado sobre o estado da tocha chamando o método +{@code CameraManager.registerTorchCallback()}. Na primeira vez que o retorno de chamada é registrado, +ele é imediatamente chamado com o estado do modo de tocha de todos os dispositivos de câmera conhecidos com +uma unidade de flash. Se o modo de tocha é ativado ou desativado, o método +{@code CameraManager.TorchCallback.onTorchModeChanged()} é invocado.
+ +A API {@link android.hardware.camera2 Camera2} é estendida para suportar YUV e reprocessamento +de imagem de formato opaco privado. O aplicativo determina se as capacidades de reprocessamento estão disponíveis +via {@code CameraCharacteristics.REQUEST_AVAILABLE_CAPABILITIES}. Se um dispositivo suporta o reprocessamento, +é possível criar uma sessão de captura de câmera de reprocessamento chamando +{@code CameraDevice.createReprocessableCaptureSession()} e criando solicitações para o reprocessamento +do buffer de entrada.
+ +Use a classe {@code ImageWriter} para conectar o fluxo de buffer de entrada à entrada de reprocessamento +da câmera. Para obter um buffer vazio, siga este modelo de programação:
+ +Caso esteja usando um objeto {@code ImageWriter} junto com uma imagem +{@code android.graphics.ImageFormat.PRIVATE}, o aplicativo não poderá acessar os dados +da imagem diretamente. Em vez disso, passe a imagem {@code ImageFormat.PRIVATE} diretamente ao +{@code ImageWriter} chamando o método {@code ImageWriter.queueInputImage()} sem nenhuma +cópia de buffer.
+ +A classe {@code ImageReader} agora suporta as transmissões de imagem +de formato {@code android.graphics.ImageFormat.PRIVATE}. Este suporte permite que o aplicativo mantenha uma fila de imagem circular de imagens de saída +{@code ImageReader}, selecione uma ou mais imagens e envie-as para +{@code ImageWriter} para o reprocessamento de câmera.
+ +Esta prévia inclui as seguintes novas APIs para Android for Work:
+Além disso, ao configurar as restrições do aplicativo nos serviços Google, o dono do dispositivo pode especificar contas +Google alternativas para desbloquear o FRP para substituir as contas ativadas no dispositivo.
+
+Um perfil ou dono do dispositivo pode definir uma política +de permissão para todas as solicitações do tempo de execução de todos os aplicativos que usam +{@code DevicePolicyManager.setPermissionPolicy()}, seja para solicitar ao usuário para conceder +a permissão como normal ou automaticamente conceder ou negar a permissão silenciosamente. Se a política posterior +for definida, o usuário não poderá modificar a seleção feita pelo perfil ou dono do dispositivo dentro da tela de permissões +do aplicativo em configurações.
+ Para obter uma vista detalhada de todas as alterações de API no M Developer Preview, consulte o relatório de diferenças de API. +
diff --git a/docs/html-intl/intl/pt-br/preview/behavior-changes.jd b/docs/html-intl/intl/pt-br/preview/behavior-changes.jd new file mode 100644 index 0000000000000..cd99bbd449e33 --- /dev/null +++ b/docs/html-intl/intl/pt-br/preview/behavior-changes.jd @@ -0,0 +1,402 @@ +page.title=Mudanças de comportamento +page.keywords=preview,sdk,compatibility +sdk.platform.apiLevel=MNC +@jd:body + +Junto com novas capacidades e recursos, o M Developer Preview inclui uma variedade +de mudanças do sistema e alterações no comportamento da API. Este documento destaca algumas +das alterações principais que você deve entender e levar em consideração nos aplicativos.
+ +Caso tenha publicado anteriormente um aplicativo para Android, saiba que ele pode ser afetado + pelas alterações na plataforma.
+ +Esta prévia introduz um novo modelo de permissões em que os usuários podem gerenciar diretamente + as permissões do aplicativo no tempo de execução. Este modelo fornece aos usuários uma visibilidade aprimorada e controle sobre permissões, + ao mesmo tempo em que agiliza os processos de atualização automática e instalação para os desenvolvedores de aplicativos. +Os usuários podem conceder ou revogar as permissões individualmente para os aplicativos instalados.
+ +Nos aplicativos direcionados para o M Preview, certifique-se de verificar e solicitar as permissões + no tempo de execução. Para determinar se o aplicativo recebeu uma permissão, chame + o novo método {@code Context.checkSelfPermission()}. Para solicitar uma permissão, chame o novo método + {@code Activity.requestPermission()}. Mesmo se o aplicativo não é direcionado para o M, + deve-se testá-lo sob o novo modelo de permissões.
+ +Para obter mais detalhes sobre o suporte do novo modelo de permissões no aplicativo, consulte a página de prévia de desenvolvedor + +Permissões. Para obter dicas sobre como avaliar o impacto no aplicativo, + consulte o guia de teste.
+ +Esta prévia introduz novas otimizações de economia de energia para dispositivos e aplicativos ociosos.
+ +Se o dispositivo estiver desconectado e parado com a tela desligada por um período, + o modo Soneca será ativado, onde ele tentará manter o sistema em um estado ocioso. Neste modo, + os dispositivos retomam as operações normais periodicamente por breves períodos para que a sincronização de aplicativos + possa ocorrer e para que o sistema possa realizar quaisquer operações pendentes.
+ +As seguintes restrições se aplicam aos aplicativos durante a Soneca:
+Quando o dispositivo sair do modo soneca, quaisquer sincronizações e trabalhos pendentes são executados.
+É possível testar este recurso conectando o dispositivo executando o M Preview + à máquina de desenvolvimento e chamando os seguintes comandos: +
++$ adb shell dumpsys battery unplug +$ adb shell dumpsys deviceidle step +$ adb shell dumpsys deviceidle -h ++
Observação: o próximo lançamento do + +Google Cloud Messaging permite que você designe + mensagens de alta prioridade. Se o aplicativo recebe mensagens de alta prioridade do GCM, + um acesso breve à rede é concedido mesmo quando o dispositivo está no modo soneca. +
+ +Consulte o +guia de teste para obter dicas sobre +como testar a soneca nos aplicativos.
+ +Com esta prévia, o sistema pode determinar quais aplicativos estão em espera quando +não estão em uso ativo. O aplicativo é considerado em espera após um período, a não ser que o sistema detecte +algum destes sinais:
+ +Se o dispositivo estiver desconectado, o aplicativo considerado ocioso terá o acesso +à rede desativado e as sincronizações e os trabalhos suspensos. Quando o dispositivo está conectado em uma fonte de alimentação, + esses aplicativos têm acesso à rede permitido e podem executar quaisquer sincronizações e trabalhos pendentes. Se o dispositivo permanece ocioso por longos períodos, + os aplicativos ociosos têm acesso à rede permitido aproximadamente uma vez por dia.
+ +É possível testar este recurso conectando o dispositivo executando o M Preview + à máquina de desenvolvimento e chamando os seguintes 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> ++ +
Observação: o próximo lançamento do + +Google Cloud Messaging (GCM) permite que você +designe mensagens de alta prioridade. Se o aplicativo recebe mensagens de alta prioridade do GCM, +um acesso breve à rede é concedido mesmo quando o aplicativo está ocioso. +
+ +Consulte o +guia de teste para obter dicas sobre como +testar a espera dos aplicativos.
+ ++Com esta prévia, os usuários podem adotar dispositivos de armazenamento externo como cartões SD. Adotar um dispositivo +de armazenamento externo criptografa e formata o dispositivo para agir como um armazenamento interno. Este recurso +permite que os usuários movam aplicativos e dados privados desses aplicativos entre dispositivos de armazenamento. Ao mover aplicativos, +o sistema respeita a preferência +{@code android:installLocation} +no manifesto.
+ +Se o aplicativo acessar as seguintes APIs ou campos, saiba que os caminhos de arquivos retornados +serão alterados dinamicamente quando o aplicativo for movido entre os dispositivos de armazenamento externo e interno. +Ao compilar caminhos de arquivos, é recomendado que essas APIs sempre sejam chamadas dinamicamente. +Não use caminhos de arquivo criptografados nem persista em caminhos de arquivo completamente qualificados que foram compilados anteriormente.
+ +Para depurar este recurso na prévia de desenvolvedor, é possível ativar a adoção +de uma unidade USB que está conectada a um dispositivo Android por meio de um cabo USB On-The-Go (OTG) executando este comando:
+ ++$ adb shell sm set-force-adoptable true ++ +
Esta prévia remove o suporte para o cliente Apache HTTP. Se o aplicativo estiver usando este cliente e for direcionado +para Android 2.3 (nível da API 9) ou mais recente, use +a classe {@link java.net.HttpURLConnection}. Esta API é mais eficiente, pois reduz o uso de rede por meio de compressão transparente e armazenamento +em cachê de respostas, além de minimizar o consumo de energia. Para continuar usando as APIs do Apache HTTP, +deve-se primeiro declarar a dependência de tempo de compilação no arquivo {@code build.gradle}: +
+
+android {
+ useLibrary 'org.apache.http.legacy'
+}
+
+O Android está mudando da biblioteca OpenSSL para +BoringSSL +. Caso esteja usando o Android NDK no aplicativo, não vincule contra bibliotecas criptográficas +que não fazem parte da API de NDK, como {@code libcrypto.so} e {@code libssl.so}. Estas bibliotecas não são APIs públicas +e podem mudar ou apresentar erros sem notificar entre liberações e dispositivos. +Além disso, você pode se expor a vulnerabilidades de segurança. Em vez disso, +modifique o código nativo para chamar as APIs de criptografia Java via JNI ou para vincular estaticamente +com relação a uma biblioteca criptográfica de sua escolha.
+ +Ajustar o volume diretamente ou desativar o áudio de transmissões específicas por meio da classe {@link android.media.AudioManager} +não são mais recursos suportados. O método {@link android.media.AudioManager#setStreamSolo(int,boolean) +setStreamSolo()} é obsoleto e deve-se chamar o método +{@code AudioManager.requestAudioFocus()}. De forma semelhante, o método +{@link android.media.AudioManager#setStreamMute(int,boolean) setStreamMute()} é +obsoleto; em vez disso, chame o método {@code AudioManager.adjustStreamVolume()} +e passe o valor da direção de {@code ADJUST_MUTE} ou {@code ADJUST_UNMUTE}.
+ +
+
+Quando os usuários selecionam o texto no aplicativo, agora é possível exibir ações de seleção de texto como +Recortar, Copiar e Colar na +barra de ferramentas flutuante. A implementação da interação do usuário é semelhante ao processo +da barra de ação contextual, como descrito em + +Ativação do modo de ação contextual para vistas individuais.
+ +Para implementar uma barra de ferramentas flutuante para seleção de texto, faça as seguintes alterações nos aplicativos +existentes:
+Caso esteja usando a +biblioteca de suporte Android revisão 22.2, saiba que as barras de ferramentas flutuantes não +têm compatibilidade com versões anteriores e que o appcompat tem controle sobre os objetos {@link android.view.ActionMode} por +padrão. Isto evita que barras de ferramentas flutuantes sejam exibidas. Para ativar o suporte de +{@link android.view.ActionMode} em um +{@link android.support.v7.app.AppCompatActivity}, chame +{@code android.support.v7.app.AppCompatActivity.getDelegate()} e, em seguida, chame +{@code android.support.v7.app.AppCompatDelegate.setHandleNativeActionModesEnabled()} no objeto +{@link android.support.v7.app.AppCompatDelegate} retornado e defina +o parâmetro de entrada para {@code false}. Esta chamada retorna o controle dos objetos {@link android.view.ActionMode} +à estrutura. Em dispositivos que são executados no M Preview, isto permite que a estrutura suporte os modos de +{@link android.support.v7.app.ActionBar} ou de barra de ferramenta flutuante, enquanto que, para dispositivos anteriores ao M Preview, +somente os modos {@link android.support.v7.app.ActionBar} são suportados.
+ +Com esta prévia, +o provedor Android Keystore não suporta mais +DSA. ECDSA ainda é suportado.
+ +As chaves que não exigem criptografia em rest não precisam ser excluídas quando a tela de bloqueio segura +é desativada ou redefinida (por exemplo, pelo usuário ou por um administrador do dispositivo). As chaves que exigem +criptografia serão excluídas durante esses eventos.
+ +Esta prévia introduz as seguintes alterações de comportamento nas APIs de rede e Wi-Fi.
+Nesta prévia, o modelo para acessar recursos compartilhados no serviço de câmera foi alterado +do antigo modelo de acesso “primeiro a chegar, primeiro a ser atendido” para um modelo de acesso onde +os processos de alta prioridade são favorecidos. As mudanças no comportamento do serviço incluem:
+O tempo de execução de ART agora implementa adequadamente as regras de acesso +para o método {@link java.lang.reflect.Constructor#newInstance(java.lang.Object...) newInstance()}. Esta +alteração corrige um problema onde o Dalvik estava verificando as regras de acesso incorretamente em versões anteriores. +Se o aplicativo usa o método +{@link java.lang.reflect.Constructor#newInstance(java.lang.Object...) newInstance()} e você quer +substituir as verificações de acesso, chame o método +{@link java.lang.reflect.Constructor#setAccessible(boolean) setAccessible()} com o parâmetro +de entrada definido como {@code true}. Se o aplicativo usar a +biblioteca v7 appcompat ou a +biblioteca v7 recyclerview, +deve-se atualizá-lo para usar as versões mais recentes dessas bibliotecas. Caso contrário, certifique-se +de que as classes personalizadas mencionadas a partir do XML sejam atualizadas para que os construtores de classe estejam acessíveis.
+ +Esta prévia atualiza o comportamento do vinculador dinâmico. O vinculador dinâmico agora entende +a diferença entre um {@code soname} da biblioteca e o seu caminho +( +erro público 6670), e a pesquisa por {@code soname} +agora está implementada. Os aplicativos que anteriormente trabalhavam e têm entradas {@code DT_NEEDED} inválidas +(geralmente, caminhos absolutos no sistema de arquivo na máquina de programação) podem falhar ao serem carregados.
+ +O sinalizador {@code dlopen(3) RTLD_LOCAL} agora está corretamente implementado. Observe que +{@code RTLD_LOCAL} é o padrão. Portanto, chamadas para {@code dlopen(3)} que não usam explicitamente +{@code RTLD_LOCAL} serão afetadas (a não ser que o aplicativo tenha usado explicitamente {@code RTLD_GLOBAL}). Com +{@code RTLD_LOCAL}, os símbolos não estarão disponíveis para as bibliotecas carregadas por chamadas posteriores a +{@code dlopen(3)} (o oposto ocorre quando mencionado por entradas {@code DT_NEEDED}).
+ + +A plataforma agora realiza validações mais estritas de APKs. Um APK é considerado corrompido se um arquivo +for declarado no manifesto, mas não estiver presente no próprio APK. Um APK deve ser atribuído novamente se qualquer +conteúdo for removido.
+ +Esta prévia inclui as seguintes mudanças de comportamento para Android for Work:
++ O M Developer Preview introduz um novo modelo de permissões de aplicativo +que agiliza o processo de instalação e atualização de aplicativos para os usuários. Se um aplicativo + que está sendo executado no M Preview suporta o novo modelo de permissões, o usuário não precisa conceder + permissões ao instalar ou atualizar o aplicativo. Em vez disso, o aplicativo + solicita as permissões à medida que precisar e o sistema exibe um diálogo + ao usuário pedindo a permissão. +
+ ++ Se um aplicativo suportar o novo modelo de permissões, ele + ainda poderá ser instalado e executado em versões mais antigas do Android, usando o antigo modelo + de permissões nesses dispositivos. +
+ ++ Com o M Developer Preview, a plataforma introduz um novo modelo + de permissões. Eis um resumo dos componentes essenciais deste novo modelo: +
+ +CONTACTS contém permissões para ler e escrever
+ informações de perfil e contatos do usuário.
+ Permissões limitadas concedidas no tempo de instalação: Quando o usuário + instala ou atualiza o aplicativo, o sistema concede todas + as permissões que o aplicativo solicita que estão em {@link + android.content.pm.PermissionInfo#PROTECTION_NORMAL PROTECTION_NORMAL}. + Por exemplo: as permissões de internet e despertador estão em {@link + android.content.pm.PermissionInfo#PROTECTION_NORMAL PROTECTION_NORMAL}. Portanto, + as permissões são concedidas automaticamente no tempo de instalação. +
+ +O sistema pode também conceder as permissões de sistema e assinatura de aplicativo, + como descrito em permissões de assinatura + e aplicativos do sistema. O usuário não é alertado a conceder permissões + no tempo de instalação.
++ Este modelo de permissões altera a forma como o aplicativo se comporta diante os recursos + que precisam de permissões. Eis um resumo das práticas de desenvolvimento que devem + ser seguidas para ajustar para este modelo: +
+ +
+ + Figura 1. Tela de permissões nas configurações do aplicativo. +
++ Observação: se um aplicativo direcionar o M Developer Preview, ele + deve usar o novo modelo de permissões. +
+ ++ No momento do lançamento do M Developer Preview, + nem todos os aplicativos Google implementam completamente o novo modelo de permissões. A Google está atualizando estes aplicativos + durante o curso do M Developer Preview para respeitar adequadamente a configuração + de alternação de permissões. +
+ ++ Observação: se o aplicativo tiver a própria superfície de API, + não represente permissões sem antes garantir que o autor da chamada tenha as permissões necessárias + para acessar esses dados. +
+ ++ Geralmente, quando um usuário instala um aplicativo, o sistema somente fornece ao aplicativo o + {@link android.content.pm.PermissionInfo#PROTECTION_NORMAL + PROTECTION_NORMAL}. No entanto, sob algumas circunstâncias, o sistema concede + ao aplicativo mais permissões: +
+ ++ Em ambos os casos, o usuário ainda pode revogar as permissões a qualquer + momento acessando a tela de configurações do sistema e escolhendo Aplicativos + > app_name > Permissões. O aplicativo + deve continuar com a verificação das permissões no tempo de execução e solicitá-las + se necessário. +
+ ++ Se um aplicativo não direciona para o M Developer Preview, ele deve continuar a usar + o modelo antigo de permissões mesmo nos dispositivos M Preview. Quando o usuário instala + o aplicativo, o sistema pede para que ele conceda todas as permissões + listadas no manifesto do aplicativo. +
+ ++ Observação: em dispositivos que são executados no M Developer Preview, + um usuário pode desativar as permissões para qualquer aplicativo (incluindo aplicativos de legado) + na tela de configurações do aplicativo. Se um usuário desativa as permissões de um aplicativo de legado, o sistema + silenciosamente desativa a funcionalidade adequada. Quando um aplicativo tentar realizar + uma operação que requer esta permissão, a operação não necessariamente causará + uma exceção. Em vez disso, ele retornará um conjunto de dados vazio, + sinalizará um erro ou exibirá um comportamento inesperado. Por exemplo, caso queira + consultar um calendário sem permissão, o método retorna um conjunto de dados vazio. +
+ ++ Se instalar um aplicativo usando o novo modelo de permissões em um dispositivo + que não está executando o M Preview, + o sistema o tratará da mesma forma que qualquer outro aplicativo: o sistema pedirá + para que o usuário conceda todas as permissões declaradas no momento da instalação. +
+ ++ Observação: para a liberação de prévia, deve-se definir a versão mínima de SDK + para o M Preview SDK para compilar com o SDK de prévia. Isto significa que você + não poderá testar tais aplicativos em plataformas mais antigas durante a prévia + de desenvolvedor. +
+ ++ Em vários casos, é possível escolher entre duas maneiras para que o aplicativo realize + uma tarefa. É possível fazer com que o aplicativo solicite uma permissão para realizar a operação + por conta própria. Alternativamente, é possível fazer com que o aplicativo use uma intenção para que outro aplicativo + realize a tarefa. +
+ +
+ Por exemplo, imagine que o aplicativo precisa da função de tirar fotos com
+ a câmera do dispositivo. O aplicativo pode solicitar a permissão
+android.permission.CAMERA, que permite que ele acesse
+ a câmera diretamente. O aplicativo então usará as APIs da câmera
+ para controlar a câmera e tirar uma foto. Esta abordagem fornece ao aplicativo
+ controle completo sobre o processo de fotografia e permite
+ que você incorpore a IU da câmera.
+
+ No entanto, caso não precise de tal controle, é possível apenas usar uma intenção {@link + android.provider.MediaStore#ACTION_IMAGE_CAPTURE ACTION_IMAGE_CAPTURE} + para solicitar uma imagem. Ao iniciar a intenção, o usuário deve escolher + um aplicativo de câmera (se não houver um aplicativo padrão de câmera) + para tirar a foto. O aplicativo da câmera retorna a imagem ao método {@link + android.app.Activity#onActivityResult onActivityResult()} do aplicativo. +
+ ++ De forma semelhante, caso precise realizar uma ligação, + acessar os contatos do usuário etc., é possível fazer estas ações criando uma intenção adequada + ou solicitar a permissão e o acesso aos objetos adequados diretamente. Essas são + as vantagens e desvantagens de cada abordagem. +
+ ++ Se usar permissões: +
+ ++ Se usar uma intenção: +
+ ++ Se um aplicativo direciona o novo M Developer Preview, ele deve usar o novo + modelo de permissões. Isto significa que, além de declarar as permissões necessárias no manifesto, + deve-se também verificar se o aplicativo + tem as permissões no tempo de execução e, + caso ainda não as tenha, solicitá-las. +
+ +
+ Para possibilitar o modelo de permissões do M Developer Preview, configure o atributo
+targetSdkVersion do aplicativo para "MNC" e
+compileSdkVersion para "android-MNC". Isto ativará
+ todos os novos recursos de permissão.
+
+ Para a liberação de uma prévia, deve-se definir minSdkVersion para
+"MNC" para compilar com o SDK de prévia.
+
+ É possível usar o novo elemento <uses-permission-sdk-m> no manifesto do aplicativo
+ para indicar que uma permissão é necessária apenas no M Developer Preview. Se você
+ declarar uma permissão desta maneira, sempre que o aplicativo for instalado
+ em um dispositivo mais antigo, o sistema não solicitará ao usuário
+ nem concederá a permissão ao aplicativo. Usando o elemento <uses-permission-sdk-m>
+, é possível adicionar novas permissões
+ a versões atualizadas do aplicativo sem forçar os usuários a conceder permissões
+ ao instalar a atualização.
+
+ Se o aplicativo está sendo executado em um dispositivo com M Developer Preview, o
+<uses-permission-sdk-m> se comporta da mesma forma que
+<uses-permission>.
+ O sistema não solicita ao usuário que conceda quaisquer permissões ao instalar o aplicativo
+ e o aplicativo solicita as permissões à medida que forem necessárias.
+
+ Se o aplicativo usa o novo modelo de permissões do M Developer Preview, + o usuário não recebe solicitações para conceder todas as permissões quando o aplicativo é iniciado pela primeira vez em um dispositivo + que está sendo executado no M Preview. Em vez disso, o aplicativo solicita as permissões à medida + que forem necessárias. Quando um aplicativo solicita uma permissão, o sistema exibe uma caixa de diálogo + ao usuário. +
+ +
+ Se o aplicativo executar em um dispositivo que tem SDK 22 ou inferior,
+ ele usará o antigo modelo de permissões. Quando o usuário instala o aplicativo, ele é solicitado a conceder
+ todas as permissões que o aplicativo lista no manifesto,
+ exceto as permissões que forem marcadas com <uses-permission-sdk-m>.
+
+ Este modelo de permissões é suportado apenas em dispositivos que estão executando
+ o M Developer Preview. Antes de chamar qualquer um destes métodos,
+ o aplicativo deve verificar em qual plataforma está sendo executado
+ verificando o valor de {@link android.os.Build.VERSION#CODENAME
+ Build.VERSION.CODENAME}. Se o dispositivo estiver sendo executado no M Developer Preview,
+ {@link android.os.Build.VERSION#CODENAME CODENAME} será "MNC".
+
Quando o usuário tenta fazer algo que requer uma permissão,
+ o aplicativo verifica se tem a permissão para realizar esta operação. Para fazer isto,
+ o aplicativo chama
+ Context.checkSelfPermission(permission_name). O aplicativo
+ deve realizar isto para verificar se sabe que o usuário já concedeu esta permissão,
+ levando em consideração que o usuário pode revogar
+ as permissões do aplicativo a qualquer momento. Por exemplo,
+ se um usuário quiser usar um aplicativo para tirar uma foto, o aplicativo chamará
+ Context.checkSelfPermission(Manifest.permission.CAMERA).
+ Tabela 1. Permissões e grupos de permissões.
+| Grupo de permissões | +Permissões | +
|---|---|
android.permission-group.CALENDAR |
+
+
|
+
android.permission-group.CAMERA |
+
+
|
+
android.permission-group.CONTACTS |
+
+
|
+
android.permission-group.LOCATION |
+
+
|
+
android.permission-group.MICROPHONE |
+
+
|
+
android.permission-group.PHONE |
+
+
|
+
android.permission-group.SENSORS |
+
+
|
+
android.permission-group.SMS |
+
+
|
+
Se o aplicativo já não tem a permissão necessária, ele chama o método
+ Activity.requestPermissions(String[], int) para solicitar
+ as permissões necessárias. O aplicativo passa
+ as permissões que deseja e também um "código de solicitação" do inteiro.
+ Este método funciona de forma assíncrona: ele retorna imediatamente e,
+ depois que o usuário responde à caixa de diálogo, o sistema chama
+ o método de retorno de chamada do aplicativo com os resultados, passando o mesmo "código de solicitação" que o aplicativo passou
+ para requestPermissions().
O seguinte código verifica se o aplicativo tem a permissão + para ler os contatos do usuário e solicita a permissão, se necessário:
+ +
+if (checkSelfPermission(Manifest.permission.READ_CONTACTS)
+ != PackageManager.PERMISSION_GRANTED) {
+ requestPermissions(new String[]{Manifest.permission.READ_CONTACTS},
+ MY_PERMISSIONS_REQUEST_READ_CONTACTS);
+
+ // MY_PERMISSIONS_REQUEST_READ_CONTACTS is an
+ // app-defined int constant
+
+ return;
+}
+
+
+
+ Quando um aplicativo solicita as permissões, o sistema apresenta uma caixa de diálogo
+ ao usuário. Quando o usuário responde, o sistema invoca o
+ Activity.onRequestPermissionsResult(int, String[], int[])
+ do aplicativo, passando a ele a resposta do usuário. O aplicativo precisa substituir este método. O retorno de chamada
+ recebe o mesmo código de solicitação passado para
+ requestPermissions(). Por exemplo, se um aplicativo solicita o acesso
+ READ_CONTACTS, ele pode ter o seguinte
+ método de retorno de chamada:
+
+@Override
+public void onRequestPermissionsResult(int requestCode,
+ String permissions[], int[] grantResults) {
+ switch (requestCode) {
+ case MY_PERMISSIONS_REQUEST_READ_CONTACTS: {
+ if (grantResults[0] == PackageManager.PERMISSION_GRANTED) {
+
+ // permission was granted, yay! do the
+ // calendar task you need to do.
+
+ } else {
+
+ // permission denied, boo! Disable the
+ // functionality that depends on this permission.
+ }
+ return;
+ }
+
+ // other 'switch' lines to check for other
+ // permissions this app might request
+ }
+}
+
+
+ Se o usuário concede a permissão, o sistema fornece ao aplicativo todas as permissões + que o manifesto do aplicativo lista para esta área funcional. Se o usuário negar a solicitação, + deve-se tomar a ação adequada. Por exemplo, deve-se desativar + quaisquer ações de menu que dependam desta permissão. + +
+ +
+ Quando o sistema pede para que o usuário conceda uma permissão, esse usuário tem a opção
+ de dizer ao sistema para que não peça esta permissão novamente. Nesse caso,
+ quando um aplicativo usa requestPermissions() para solicitar esta permissão,
+ o sistema nega imediatamente. Neste caso, o sistema chama
+ onRequestPermissionsResult() da mesma forma que faria se o usuário tivesse
+ rejeitado explicitamente a solicitação novamente. Por este motivo, o aplicativo
+ não pode presumir que uma interação direta com o usuário ocorreu.
+
+ Se o aplicativo for direcionado para o M Developer Preview, deve-se testar + se ele lida com as permissões corretamente. Não se pode presumir que o aplicativo + terá qualquer permissão quando executado. Quando o aplicativo é iniciado pela primeira vez, + é provável que não tenha permissões. O usuário pode revogar e restaurar permissões + a qualquer momento. +
+ ++ Deve-se testar o aplicativo para garantir que ele se comporte corretamente em todas + as situações de permissão. Com o M Preview SDK, fornecemos os novos comandos + de Android + Debug Bridge (adb) para possibilitar que o aplicativo seja testado com quaisquer + configurações de permissões necessárias. +
+ ++ As ferramentas da plataforma M Preview SDK fornecem vários comandos novos para permitir + que você teste como o aplicativo lida com permissões. +
+ +
+ É possível usar a nova opção -g do comando adb
+ install, que instala o aplicativo
+ e fornece todas as permissões listadas em seu manifesto:
+
+$ adb install -g <path_to_apk> ++ +
+ É possível usar os novos comandos do gerenciador + de pacotes (pm) de ADB para conceder e revogar as permissões de um aplicativo instalado. + Esta funcionalidade pode ser útil para testes automatizados. +
+ +
+ Para conceder uma permissão, use o comando grant do gerenciador de pacote:
+
+$ adb pm grant <package_name> <permission_name> ++ +
+ Por exemplo: para conceder a permissão do pacote com.example.myapp para gravar áudios, + use este comando: +
+ ++$ adb pm grant com.example.myapp android.permission.RECORD_AUDIO ++ +
+ Para revogar uma permissão, use o comando revoke do gerenciador de pacote:
+
+$ adb pm revoke <package_name> <permission_name> ++ +
+ O novo modelo de permissões fornece aos usuários uma experiência mais suave + e facilita a instalação de aplicativos, deixando-os mais confortáveis + com o que os aplicativos estão fazendo. Sugerimos que você siga as práticas recomendadas para aproveitar + todas as vantagens do novo modelo. +
+ + ++ Sempre que você pede uma permissão, o usuário é forçado a tomar uma decisão. + Se o usuário negar a solicitação, a funcionalidade do aplicativo será reduzida. + Deve-se minimizar o número de solicitações realizadas. +
+ ++ Por exemplo: o aplicativo pode frequentemente adquirir a funcionalidade necessária usando + uma intenção em vez + de solicitar permissões. Se o aplicativo precisa tirar fotos com a câmera do telefone, + é possível usar uma intenção {@link + android.provider.MediaStore#ACTION_IMAGE_CAPTURE + MediaStore.ACTION_IMAGE_CAPTURE}. Quando o aplicativo executa a intenção, + o sistema pede para que o usuário escolha um aplicativo de câmera já instalado + para tirar a foto. +
+ ++ Se você confrontar o usuário com várias solicitações de permissão de uma só vez, + é possível que ele se sinta oprimido e saia do aplicativo. + Em vez disso, deve-se solicitar as permissões somente quando necessário. +
+ ++ Em alguns casos, uma ou mais permissões podem ser absolutamente essenciais para o aplicativo. + Nesta situação, faz sentido solicitar todas as permissões assim + que o aplicativo é iniciado. Por exemplo: se você fizer um aplicativo de fotografia, + ele precisará de acesso à câmera do dispositivo. Quando o usuário iniciar o aplicativo + pela primeira vez, ele não se surpreenderá quando receber + uma solicitação de permissão para usar a câmera. Mas, se o mesmo aplicativo tiver um recurso + para compartilhar fotos com os contatos do usuário, não se deve + pedir esta permissão na primeira inicialização. Em vez disso, espere o usuário tentar usar + o recurso de compartilhamento para pedir a permissão. +
+ ++ Se o aplicativo fornecer um tutorial, faz sentido solicitar as permissões + necessárias no final da sequência do tutorial. +
+ +
+ O diálogo de permissões exibido pelo sistema ao chamar
+ requestPermissions() diz quais permissões o aplicativo requer,
+ mas não diz o porquê. Em alguns casos, o usuário pode achar isto confuso.
+ É uma boa ideia explicar ao usuário o porquê da necessidade das permissões
+ para o aplicativo antes de chamar requestPermissions().
+
+ Por exemplo: um aplicativo de fotografia pode precisar usar serviços de localização
+ para poder marcar as fotos geograficamente. Um usuário normal pode não entender que uma foto
+ pode conter informações de localização e ficar confuso quando
+ o aplicativo de fotografia quiser saber a localização. Portanto, neste caso, é uma boa ideia o aplicativo explicar
+ ao usuário sobre este recurso antes de chamar
+ requestPermissions().
+
+ Uma maneira de fazer isto é incorporar estas solicitações em um tutorial do aplicativo. O tutorial pode exibir cada um dos recursos
+ do aplicativo e, à medida que fizer isto,
+ pode também explicar quais permissões são necessárias. Por exemplo, o tutorial do aplicativo de fotografia
+ pode demonstrar os recursos de compartilhamento de fotos com os contatos e,
+ em seguida, dizer ao usuário que ele precisa fornecer as permissões
+ para que o aplicativo possa visualizar os contatos. O aplicativo pode então chamar requestPermissions() para solicitar
+ ao usuário este acesso. É claro que nem todos os usuários seguirão o tutorial.
+ Portanto, ainda é necessário verificar e solicitar as permissões durante
+ a operação normal do aplicativo.
+
3oSMd`L3GuG8MWHL@EQ-y>6$^BMxTDn%%YNb$%&?m{pm%5-c
z`bB!1+e=Zcri EZ;X_nXinVr-vmhL_IiD+5qCF-^j@m?OEZa)#S9|
zvJ}f^I^zN>Q`m_a!lDPGnWsV<*Jp!W!WcqTy|LzRij+1XUO}vwVXYYJB^Yjkf9+v!
zI+<4c&An}&*9Ez3H^Haf@%+HaiP36Z_0wG17Kz2i5@$cyNqdl`7gpV~nkF&w%-MK%
zTI%vJ11&&7tLDOO4YXsUUN+U5!jDpW{P&y)UE5h%hG!sY+#FDd^{On}Rz3LTnZ@x3
zOOpgf_vSe&Fxk|BSi6LklmPU*KvrGJ^y3zuP$#