BEN POIESZ: Hola a todos. Soy Ben Poiesz. Soy el gerente de producto
de Android Framework. Quería agradecer a todos por
aguantar un viernes con comisiones. Así que vamos a
hablar sobre algunas de las mejores prácticas,
algunas de las cosas nuevas [INAUDIBLES] de las que se
habló en la conferencia magistral. Y entrar un poco
en los detalles, en el meollo de la cuestión. Pero primero, comencemos
por dónde estamos y hacia dónde vamos.
Y hoy
tenemos una situación en la que los usuarios saben
qué son los permisos, pero no tienen el nivel de control
que queremos que tengan. También tenemos un
problema para los desarrolladores que están actualizando sus
aplicaciones: están tomando decisiones realmente difíciles
sobre si agrego este permiso. ¿ Quiero que
mi tasa de aceptación se vea afectada? Y por eso estamos buscando
resolver eso también. Y el último es la
fricción de instalación que también tenemos. Cuando haces clic en
el botón Instalar, en realidad no se instala. Recibe un mensaje que dice: "Oye,
aquí hay un montón de información que probablemente no
quieras leer en este momento". Pero se
lo mostraremos y
presionará el botón Aceptar y luego
lo descargaremos e instalaremos por usted. Entonces, la pregunta que nos hemos
hecho mucho durante los últimos años y meses
analizando este problema es: ¿ cómo podemos mejorarlo? Y esto es lo que se nos
ocurrió.
Por eso, la idea es que queremos que
esto sea mucho más sencillo de entender para los usuarios. Y la idea es que
si es más simple y se centra en las
cosas que les interesan a los usuarios, entonces tendrán más poder
y tendrán aún más control. La otra parte
es que queremos que los desarrolladores tengan el control
de que pueden solicitar estos permisos en
tiempo de ejecución, en el momento en que tenga sentido que
proporcionen contexto al usuario sobre
por qué los desea. Y el último es también
mejorar cierta información al usuario sobre la auditoría. Y la idea de
la auditoría ( hablaremos de ello un
poco) es que, si comprende qué
aplicaciones hacen qué (qué es normal, qué es
diferente), los usuarios también pueden tomar decisiones informadas
sobre comportamientos extraños.
Y aquí está la lista de
permisos en su totalidad. La keynote no contó con
el set completo, por cierto. Entonces comenzamos con
Ubicación y Cámara, que son bastante sencillas. El siguiente es el micrófono,
por lo que el micrófono está separado de la cámara. Entonces la cámara controla
fotos y videos. Entonces, si estás grabando un video
con audio, querrás solicitar ambos. El teléfono incluye el
estado del teléfono y la marcación. Entonces, si su aplicación
realiza una funcionalidad que realiza llamadas con frecuencia o
intenta administrar las llamadas, querrá solicitar esto. Estos son los grupos, por
cierto, sólo por un momento.
Olvidé mencionar. Todavía existen los
permisos individuales que solicita. Estos son sólo los
grupos de alto nivel. Y hablaremos sobre la
distinción de carga un poco más adelante. Para SMS, así como para
controlar y leer SMS en tu aplicación. Y luego los dos siguientes son bastante
sencillos: Contactos y Calendario, cada uno de los cuales
está separado para acceso de lectura y escritura a
sus Contactos y Calendario, respectivamente. Y el último
trata sobre Sensores. Y los sensores son complicados. Los usuarios todavía no entienden
muy bien esto. Se trata de monitores de frecuencia cardíaca
, información corporal y sensores corporales. Y este es un espacio nuevo
que está evolucionando bastante rápido y queríamos
asegurarnos de que se tuviera en cuenta en el
nuevo modelo de permisos. Entonces, lo que esto nos da es que
ahora lo preguntamos en tiempo de ejecución: no necesitamos recibir
un mensaje cuando hace clic en el botón Instalar. La instalación ahora hace
lo que dice: se instala.
Esto también significa que las actualizaciones
ahora pueden realizarse automáticamente. Y así, cuando estás
impulsando tus aplicaciones, estas incluyen nuevos permisos. Esos permisos
ya no se otorgan durante la instalación, se otorgan en tiempo de ejecución. Entonces, todos esos archivos binarios APK se pueden
enviar de inmediato. ¿ Y qué sucede
entonces en tiempo de ejecución? ¿ Cuándo preguntas? ¿ Cómo preguntas? Y aquí es donde
puedes preguntarle al usuario, en un
momento que tenga sentido en tu aplicación, a qué
quieres tener acceso. En este caso, aquí tenemos
Hangouts pidiendo la posibilidad de gestionar llamadas telefónicas. Estos son únicos para cada usuario. Por lo tanto, esto ya no se
aplica a todos los usuarios de su dispositivo.
Es individual para
cada usuario de Android. Y aquí hay una nota especial. Hablaremos de esto en las
Mejores Prácticas un poco más adelante; se trata de
No volver a preguntar. En la primera solicitud,
los usuarios no verán esta casilla de verificación. Entonces solo tendrás la
pregunta y Permitir/Denegar. Permitir/Denegar en este
mundo es mucho tiempo. No es una respuesta única,
es una respuesta para siempre. Pero los desarrolladores pueden
volver a preguntar en caso de decir que no. Y el truco es que, en
la segunda solicitud y en las siguientes,
después de que el usuario dice que no, tiene un
botón de silencio donde puede decir: no me vuelvas a preguntar. Y esto es un claro indicador
para nosotros a nivel del sistema operativo de que el usuario y el desarrollador
no están realmente en la misma página sobre lo que se
les pide.
Y lo que sucederá
es que la solicitud de función por parte del desarrollador va
directamente a la respuesta sin respuesta. No solicitamos la interfaz de usuario, no
molestamos al usuario porque ha
indicado esta bandera. Entonces la idea es que, en la primera
solicitud, no hay penalización. Así que siéntete libre de usarlo. En las solicitudes posteriores,
asegúrese de que usted y el usuario estén en sintonía sobre
lo que está hablando. Y cubriremos esto nuevamente
en las Mejores Prácticas, porque es un punto importante
que queremos resaltar en la experiencia. La otra parte está
en Configuración del sistema. Y así, en la
Configuración del sistema ahora, los usuarios no solo pueden ver
todos los permisos, sino que también pueden ver los nuevos grupos. Y tienen pequeños
interruptores de palanca al lado de estos grupos. Y así, en cada aplicación
de su dispositivo, los usuarios ahora
podrán alternar estos interruptores.
Esto significa que
pueden mirar algo, pueden encender cosas
que están apagadas, apagar cosas que están encendidas. No hay penalización si
apagan cosas. Entonces, si un usuario dice que
no a algo, tiene la posibilidad
de volver a preguntar. Luego recibirán ese mensaje,
como mencioné antes, para decirles que no vuelvan a preguntar si ha
sido con demasiada frecuencia. Y la idea es que esto
esté siempre disponible, en cualquier momento, en todas las aplicaciones. Y esa es una gran distinción
a la hora de capacitar realmente a los usuarios para que utilicen estos controles. También tenemos una vista vertical. Y así, en la
vista vertical, puedo mirar la cámara. Y esta es la auditoría que
mencioné antes, en la que un usuario puede ver
cada aplicación. ¿ Quién usa la cámara? Y puedo decir, oh,
estos tienen sentido. Yo uso estos. Oh, estos no
tienen mucho sentido para mí.
Déjame apagarlos. Y si la aplicación, entonces, se
está ejecutando y pueden decir, apagaste la cámara por mí,
pero hago cosas realmente interesantes con la cámara. Deberías volver a activar esto. Y dices, oh, haces
cosas interesantes con la cámara. Te volveré a encender. Y eso
conducirá a… ¿qué haces? Tenemos este mundo. ¿ Cuáles son entonces las mejores
prácticas para el desarrollador? Y el truco es que,
para muchas personas, supongo que te sientes un poco nervioso
, como desarrollador. Y empiezas a sentir, ¿
qué va a hacer el usuario? ¿ Qué va a pasar? No estoy realmente seguro. Y estas mejores prácticas de las que
vamos a hablar no son conjeturas. Esto debería
ser realmente predecible. Los usuarios deben entender
por qué lo preguntas.
Y cuando los usuarios comprendan
cuál es tu propuesta de valor y
te expliques claramente, dirán que
sí la mayor parte del tiempo. Y esa es la idea. Entonces hablemos de
algunas de esas prácticas. Y todas estas
prácticas, por cierto, no es necesario que las hagas todas. Esto solo cubre
una variedad de cosas que tienen sentido,
dependiendo de las situaciones y de cómo estructura
su aplicación. Entonces, la idea aquí
es, con una cálida bienvenida, presentarle al usuario lo que
hace su aplicación. Verás esto en
Google Now como ejemplo. Es una aplicación que pide
muchos permisos. Está muy integrado
con tu experiencia. Y por eso dejan muy
claro en la aplicación Google Now cuál
es su propuesta de valor para el usuario.
Y cuando eso se hace,
tiene sentido pedir las cosas por adelantado. Y en este caso,
tenemos Hangouts solicitando SMS. Y también solicitará
otros permisos. Pero la idea es que, cuando
lo preguntas por adelantado y tiene sentido dónde está tu aplicación:
Hangouts, [? en este caso ?]– gestiona y envía SMS
y mensajería en general. No existe una disonancia real
entre la aplicación, cuál es su caso de uso, cuáles
son las expectativas del usuario para esta aplicación
y lo que pide. Si apareciera y preguntara
por Calendar de la nada, probablemente me rascaría la cabeza
preguntándome qué está pasando. Y aquí es donde no
necesitamos brindar esa educación para estas solicitudes iniciales,
donde tiene sentido según la funcionalidad
de su aplicación.
Para cosas que son un
poco más atrevidas o tal vez no es necesario solicitarlo por
adelantado y es una característica particular,
y aquí estamos viendo Keep por primera vez. Y aquí tiene una opción
para grabar, donde puedo grabar
una nota de voz y la transcribirá. Y este es un gran
caso en el que ahora tiene sentido para mí, el
usuario, en este caso hacer clic en el botón de grabar. Y sigue preguntándome si
pueden grabar audio. Y yo digo, por supuesto que puedes. Y esta es la
estructura que queremos tener donde usted y
el usuario estén en la misma página. Esto también evita casos
de doble solicitud que hemos visto
en otras plataformas donde tenemos
modelos de tiempo de ejecución similares. Y realmente queremos
evitar un doble mensaje. Y la idea es que, si
preguntas la primera vez, no hay penalización
por la primera solicitud.
Adelante, pregunta. Si dicen que no, no te
preocupes. Y luego descubra cuál es
la mejor manera de volver a preguntar en algún momento futuro. Tal vez esperes
hasta la próxima vez que presionen el botón de grabar. Y diga, oye, estás
presionando el botón de grabar. ¿ Quieres
grabar una nota de voz? Yo digo, lo hago. Entonces esa es la idea. Además, no siempre
necesitas permisos. Y lo más
destacado es que tenemos una variedad de
intenciones del sistema en la plataforma. Estos son para la cámara,
para hacer llamadas telefónicas y para conseguir contactos.
Estos no requieren permisos. La razón por la que no
requieren permisos es porque el usuario es
quien presiona el botón, selecciona el contacto y
toma la foto. Y así su aplicación
puede invocarlos libremente. Entonces, cuando esta es una
opción, es muy preferible utilizar estos enfoques porque
no requieren ninguna solicitud previa. Y le permite al usuario
saber que al desarrollador le importa mi
capacidad para configurar acciones. La siguiente es, ¿qué pasa
si su aplicación necesita una variedad de
cosas para hacer su trabajo? Y como ejemplo
aquí usando Hangouts, Hangouts es un cliente de mensajería. Por lo tanto, necesitaría cosas como el
permiso del teléfono de contactos y SMS.
Y entonces tenemos una opción para
permitir que un desarrollador solicite múltiples permisos de una sola vez. Ahora, como está viendo
en la animación aquí, los presentamos uno a la
vez al usuario. La idea es que haya
equilibrio en la forma de presentar
estas múltiples solicitudes. Si tienen sentido y
son relativamente limitados, obtendrá una rápida
comprensión del usuario y una respuesta rápida. Si intentas arruinar
todo desde el principio, probablemente obtendrás
algunos no. Entonces la idea es
hacer las cosas que tengan sentido para el usuario. El siguiente es dar
una respuesta de inmediato. Si pides algo,
considéralo como un intercambio. Te voy a dar
algunos de mis datos. ¿ Qué vas a hacer por mí? Y entonces, en el caso de la Tierra,
es realmente obvio. Acérquese a donde se
encuentra actualmente. Pero hay muchos
otros que son específicos de su aplicación. Pero piense siempre en
cuál es mi retorno de la inversión.
Cuando el usuario lo
piensa, ¿ qué le voy
a devolver? En los casos en los que
solicita algo y
el usuario no entiende de inmediato por qué lo
solicitó, se preguntará por qué lo activó
y es posible que lo apague. Lo siguiente es mirar
los documentos de diseño de materiales que tenemos en línea y las
pautas que están en línea. Es realmente
útil observar el estado vacío. Y piense en cómo, si
tiene una función, tal vez tenga una
vista de búsqueda y su vista de búsqueda dependa de
ciertos permisos para completar sus datos. ¿ Cómo se presenta
un estado vacío? ¿ O cómo presentas
la sugerencia de que esto es mejor si tuvieras esto? Entonces, ese tipo de
estructuras permiten a los usuarios comprender
mejor su propuesta de valor y lograr que digan que sí a los
diferentes permisos que desea tener.
Y entonces entremos en eso un
poco, más en el meollo de la cuestión
que mencioné antes. Y esto es que,
en una M, no exigimos que todas las aplicaciones
admitan permisos de tiempo de ejecución. Sin embargo, si está
en un dispositivo M y está compilando contra
MSDK con un objetivo de API 23, estará en
el modelo de permisos. Y lo que esto
significará es que necesitas escribir
un código realmente complejo. Lo sé, es bastante duro.
Pero lo que tenemos aquí solo
destaca las dos API principales que
querrá ver. Uno es checkSelfpermissions
y el otro es requestPermissions. Entonces, la idea es que
verifiques, oye, ¿ qué permisos tengo
disponibles en este momento? Si le falta
algo que necesita, puede solicitar
esos permisos y luego continuar
con su funcionalidad, suponiendo que haya ido bien. Y esa es su estructura. No tiene que preocuparse
por las devoluciones de llamadas en tiempo de ejecución, donde se pregunta: ¿qué pasa si
estoy en medio de una operación y el usuario
me desactiva el permiso en la configuración? No te preocupes,
matamos tu proceso.
Sin embargo, lo bueno de
eso, a diferencia de que te
maten, es que es el mismo método que si
tuvieras poca memoria. Así que no hay ningún
modo o manejo especial que hacer aquí. Se trata de la misma manera que
una condición de poca memoria. Pero lo que sucede entonces es que,
cuando inicias en la secuencia de tu aplicación
, simplemente verificas los valores de tus permisos. Si siempre hace
eso al inicio y verifica los resultados y
los almacena en caché, estará bien.
No cambiarán contigo. Sólo cambiarán
cuando tú lo pidas y se irán en el sentido positivo. Nunca desaparecerán contigo. Cuando se vayan, te
matarán y te traerán de vuelta. Así que no tienes que preocuparte
por el manejo del tiempo de ejecución. La última es que quizás
estés pensando furiosamente: ¿ dónde uso los permisos? ¿ Cuáles son mis API que
utilizan permisos? ¿ Cómo voy a comprobarlos? Y esto es lo que hemos
agregado en Android Studio. Y si estuviste en esa charla,
ellos lo mencionaron, así que compararé
su mención de mis cosas con las suyas.
Agregaron anotaciones. Y las anotaciones
introducen nuevas advertencias y errores de Lint, de modo que cuando
usas Studio y agregas una
función que necesita un permiso (en
este caso, estoy usando Location Manager para obtener
la ubicación del usuario). Recibiré una advertencia que
dice: "Oye, tu APK en realidad no declara
el permiso necesario para usar esta función". Además, notaremos que si
no tiene un cheque, no está protegiendo
esta llamada en particular. Y le ofrecemos una
versión con plantilla donde podemos completar
[? un poco?] fragmento de código repetitivo para ayudarle a
realizar una solicitud.
Y de esa manera, todo se
trata de nuestras M Apps en el MSDK. Y entonces quizás se pregunte
qué pasa con todas estas aplicaciones L y pre-M
que existen. ¿ Cómo se van a
comportar en este modelo? Porque si te
diste cuenta antes, dije muchas cosas sobre
estos diferentes controles. Y una cosa que
será diferente es que, en el
momento de la instalación, seguirás viendo el
diálogo actual. Entonces, debido a que las aplicaciones
anteriores a M no entienden lo que significa que se les quiten los
permisos o lo que significa
comenzar sin nada, las trataremos de manera
un poco diferente.
Así que todavía vamos
a avisar al usuario. Habrá una mención de
esta aplicación como nuestra aplicación heredada en juego. Y durante la instalación, se le
otorgarán los mismos permisos que hoy. Además, las actualizaciones
ahora se bloquearán como lo están hoy, en lugar
de las fluidas de las que hablé antes. Sin embargo, lo siguiente
está en el panel de Configuración.
Los usuarios aún
podrán desactivar la configuración de sus aplicaciones. Ahora bien, esto no le causará
excepciones de seguridad. Eso sucedería
en el nuevo modelo si su aplicación está en MSDK. Pero en este caso,
lo que hacemos es identificar que esta aplicación
está compilada en un SDK más antiguo y comenzamos a suministrarle
datos de estado vacío. Y si preguntáramos,
bueno, ¿cuál es la ubicación? Yo diría que la
ubicación no está disponible. Es un estado de error válido. Dirías, ¿
hay algún contacto? No, no hay contactos.
Cuando quieres guardar un contacto,
decimos, sí, lo guardamos. No, no lo guardamos. Entonces, cuando lo revises,
encontrarás que está vacío. Esto puede generar algunos
comportamientos extraños en las aplicaciones. Los usuarios recibirán una advertencia. Entonces, cuando
apagan algo, simplemente no queremos permitir que el
usuario lo apague y asuma que todo estará bien. O si la aplicación empieza a
comportarse de forma extraña. Por eso tenemos esta
advertencia para asegurarnos de que los usuarios sepan que este
es un control que tienen. Pero también es posible que necesiten
regresar y volver a encenderla o tal vez tengan que
deshacerse de la aplicación si terminan teniendo
un comportamiento extraño. Un ejemplo podría
ser: hago Hangouts y veo que está usando la
cámara y aparentemente no
me resulta obvio que necesita la cámara. Lo apago. Unas semanas más tarde,
tengo una llamada de Hangout y el vídeo no funciona. Y preguntas, ¿por qué? Y es posible que no vayan, oh,
porque apagué la cámara y tengo que
regresar y encenderla.
Con suerte, Hangouts
no tendrá ese problema porque será una
aplicación moderna. Pero sólo por ejemplo. La última es que, cuando las cosas
están desactivadas en una aplicación anterior a M, porque no está en el MSDK,
no puede solicitar permisos. Y aquí es donde realmente
buscamos que los desarrolladores de aplicaciones adopten el modelo lo más
rápido posible. Y esto realmente sólo
tiene sentido para los usuarios cuando
solo tenemos un modelo, donde todo es tiempo de ejecución. A diferencia del
híbrido que tendremos al principio. He usado la metáfora
de que esto es cambiar del lado izquierdo del camino
al lado derecho del camino. Al principio será un poco
complicado. Y por eso realmente queremos
asegurarnos de que las aplicaciones se muevan. Hemos tratado de brindar
muchos incentivos para que los desarrolladores se muevan,
especialmente en cuanto a poder preguntar varias
veces, poder hacer preguntas en masa y hacer que
las actualizaciones sean más fluidas cuando se agregan nuevos permisos. Y con eso,
termino temprano. Entonces, si planeas
regresar a casa, podrás hacerlo temprano.
Pero si no, muchas
preguntas y respuestas. Supongo que hay muchas preguntas aquí. Así que me quedaré aquí durante el próximo…
Creo que tenemos 24 minutos. Y si tienen preguntas,
no duden en acercarse al micrófono y probar esto. Además, hay un ejemplo de código completo
en el sitio web. Tenemos fragmentos de código
de todo esto. Hay un gran artículo sobre
permisos, sobre las mejores prácticas y sobre los comportamientos.
Habrá más información
sobre las mejores prácticas, comportamientos y pautas de la interfaz de usuario, así que
consulte desarrollador.android.com para obtener nuevas actualizaciones. Y con eso, gracias. A por ello. AUDIENCIA: Hola. Es genial tener
finalmente permisos granulares. A veces me recuerda a iOS. Hablando de eso, ¿
hay alguna manera de dar una
explicación de por qué solicitamos el permiso? BEN POIESZ: No en este momento. Estamos viendo
las opciones de una nota del desarrollador en el
diálogo que les estaba mostrando. Hay un
poco de complejidad cuando el sistema operativo indica
información sobre el camino de un
desarrollador de aplicaciones. ¿ Es esa una premisa falsa,
es legítima? Entonces estamos tratando
de resolver cuál es la forma correcta
de presentar el equilibrio. Esta es una declaración
del desarrollador mientras está en la interfaz de usuario del sistema.
Si siente que
necesita explicarle al usuario por qué quiere algo, le
recomiendo encarecidamente el enfoque que mencionamos
antes: pregunte primero. No hay penalización
si el usuario dice que no. Si dicen que no, presente
la racionalización. Preséntales tu
propuesta de valor. Si todavía dicen que no, que así sea. Pero la idea es
la primera solicitud, los usuarios que entienden
su valor solicitan, obtienen un diálogo. Genial. Los usuarios que no lo hagan,
obtendrán un no y verán su
propuesta de valor.
Si todavía dicen que no, que así sea. AUDIENCIA: ¿Qué pasó con
el resto de los permisos? Si tengo una aplicación que
quiere escanear Wi-Fi, ¿ adónde va? BEN POIESZ: Sí, habrá
mucha refactorización que haremos bajo el capó. Y un examen de conciencia
sobre los permisos. Una de las cosas que
no mencionamos es que existen
permisos peligrosos y permisos normales. Todo lo que esté
marcado como normal, no tienes que preocuparte
de que te lo quiten. Estos todavía se
otorgan automáticamente. No hay ningún interruptor
para desactivarlos. Cosas como Wi-Fi, estamos
cambiando algunas de las semánticas sobre cómo se solicitan
y algunas de las reglas sobre cómo
obtener direcciones Mac.
Entonces, uno de los elementos con más matices (
lo mencionaré ahora para que puedas
descubrirlo más tarde) es si estás tratando de averiguar la
dirección Mac de dispositivos Bluetooth remotos al realizar escaneos de Wi-Fi. Estos devolverán no a menos que
tenga activamente el permiso de ubicación, ya que normalmente
las direcciones remotas de Mac para Bluetooth y
Wi-Fi tienden a tratar de encontrar y
triangular su ubicación. Así que hemos hecho algunas reestructuraciones
y cosas de comportamiento bajo el capó. En realidad, esto ya está algo
documentado, pero habrá más
información al respecto. Si nos fijamos en desarrollador.com,
el punto destacado actual sobre permisos, en
realidad menciona algunas de esas cosas
específicamente sobre Wi-Fi.
AUDIENCIA: OK, gracias. BEN POIESZ: Sí. AUDIENCIA: Puede que me
lo haya perdido, pero no existe una categoría para
permisos de estilo Internet, ¿ verdad? BEN POIESZ: Correcto. AUDIENCIA: ¿Eso
significa que, de forma predeterminada, todos los permisos similares a los de Internet están
básicamente permitidos para la aplicación? BEN POIESZ: Sí. AUDIENCIA: Entonces, ¿significa que
podría tener una aplicación de linterna, pero [INAUDIBLE]
obtener información [INAUDIBLE] y luego enviar datos a… BEN POIESZ: Sí, entonces una
aplicación de linterna podría tener Internet? Sin embargo, entonces tendría que
solicitar todos los permisos para extraer datos de su dispositivo. Entonces, la idea es que, debido a que
estamos impidiendo el acceso a los datos por adelantado, es
posible que tenga Internet, pero no
tendrá nada que nos preocupe.
Al menos eso es lo que
debería preocupar al usuario. AUDIENCIA: OK, gracias. AUDIENCIA: Entonces, ¿
consideró un modelo de zona de pruebas en lugar de simplemente
devolver información nula? ¿ Y cuál es la posibilidad
de que eso ocurra en el futuro? BEN POIESZ: Sí, el
sandboxing es algo que hemos estado analizando para
algunas cosas diferentes, pero no es algo que
planeemos hacer, al menos en este momento. La idea era tratar de
minimizar… sandbox, ¿ te refieres a
proporcionar datos falsos? A diferencia de…
AUDIENCIA: Sí, datos falsos. O solo ciertos
datos, como si quisieran guardar un contacto,
podemos permitirles tener acceso a ese contacto. BEN POIESZ:
Creas una nueva edición. Ahora la aplicación está funcionando
y el conjunto de datos está desunido. Y el usuario realmente
nota comportamientos extraños, donde si
ve un conjunto nulo, se vuelve mucho más obvio. Entonces, cuando voy al Calendario
y mi aplicación Calendario no muestra entradas del calendario. Y es mucho más obvio
lo que está pasando. AUDIENCIA: Gracias. AUDIENCIA: ¿Se ha
pensado en otorgar un equivalente
al selector de controlador de intención de una sola vez? Entonces, ¿otorgar permiso para realizar la
acción que estoy haciendo ahora mismo, pero no
permiso general de ahora en adelante? BEN POIESZ: Sí,
estamos analizando diferentes
formas en que los desarrolladores pueden solicitar diferentes tipos de datos.
Estamos tratando de verlos
como: cosas que son solo una vez, cosas que nuestro usuario elige
o cosas que son un acceso independiente más general. Lo que intentamos hacer
es equilibrar la fatiga del usuario al ver demasiados. Entonces, al menos
ahora, estamos tratando de evitar el uso de una sola vez para
estos grupos de permisos. Pero para las intenciones
que estás mencionando, esa es la forma en que estamos
estructurando solo una vez, es disparar la intención. Y ese es un
selector único. Pero gracias por el comentario. AUDIENCIA: ¿Puede aclararnos sobre
la opción No volver a preguntar? Entonces, si un usuario selecciona eso y,
digamos, en el campo [? ¿Mantener aplicación?] Pulsaron el
botón Grabar nuevamente. ¿ Recibimos una excepción de seguridad? ¿ O? BEN POIESZ: No,
obtendrás un no rápido por eso. Entonces, si un usuario dice,
no me vuelvas a preguntar, invocas la
verificación [INAUDIBLE]. El sistema operativo responderá
muy rápidamente con un no. Tienes la información
para saber que el usuario dijo no volver a preguntar. Cuando el usuario dice no vuelvas a preguntar
, eres consciente de ello.
Hay algunas
estrategias diferentes que puedes adoptar, dependiendo de la
importancia de la característica. Podría simplemente decir,
ocultemos el botón de grabación. Podría simplemente decir, tal vez
deberíamos mantener el botón de grabar. Si lo presionan nuevamente,
volvemos al juego. Pero en general deberías
considerar la opción No volver a preguntar casi como la opción nuclear.
Lo utilizamos como una
señal de disonancia entre el desarrollador
y el usuario. AUDIENCIA: Y en ese
momento, si mantuviéramos la opción en la pantalla,
presentaríamos un mensaje que diría: "Oye, deshabilitaste este permiso,
por lo que no podemos hacer esto". ¿ Tenemos una
intención directa con la configuración? BEN POIESZ: Tiene
la intención de llevarlos a la página de la aplicación
, pero no específicamente a la
página de permisos. Por eso queríamos darle
mucha importancia cuando el usuario dice: no vuelvas a preguntar. Pero tendrás recurso. AUDIENCIA: Gracias. AUDIENCIA: Hola. Tengo una pregunta
sobre la compatibilidad. Entonces, ¿aún podré
crear un único APK dirigido a Android M? ¿ Y aprovechar este
nuevo modelo de permisos y hacer que funcione
correctamente en los dispositivos más antiguos que no lo admiten? BEN POIESZ: No.
Sí. No estoy seguro de que alguien
me creyera si dijera que no. Entonces sí. Entonces, la estructura es que,
dado que todavía estás declarando los
permisos detallados, los individuales,
porque se asignan a
los grupos más grandes que estás viendo,
realmente no necesitas hacer nada especial. en los mayores. [ ? Supportlib ?]
Principalmente no funciona para las diferentes funciones cuando
llamas, verificas las concesiones de permisos y solicitas permisos. Todas esas cosas quedan anuladas. Por lo tanto, no tiene que hacer
nada especial en su código para trabajar con sistemas operativos más antiguos. Simplemente sigue haciendo lo que
estás haciendo, declara unos. Hay una… es más
una característica avanzada, pero estás preguntando sobre
ella… es, digamos que tienes un permiso que deseas agregar. No lo tienes hoy. Desea agregarlo
solo en dispositivos M, porque no quiere
recibir el impacto en los dispositivos L. Y entonces tenemos una
opción de Manifiesto que puede definir y que le
permitirá solo solicitar este nuevo permiso y
declararlo en m dispositivos.
De esta manera, sus dispositivos L no se
verán afectados por sus solicitudes y no requerirán que usted
simplemente las acepte. Pero puedes obtener el
flujo libre por adelantado. Es una elección. Si los quieres
todos, hazlo; si solo lo quieres en los
nuevos, hazlo también. AUDIENCIA: Gracias. BEN POIESZ: Sí. AUDIENCIA: Hola. En caso de legado
[? desarrollo?] Aplicaciones, ¿se le permitiría al usuario
desactivar los permisos? BEN POIESZ: Sí. AUDIENCIA: ¿Hay alguna
forma de desactivar eso? BEN POIESZ: ¿Desactivar? ¿ Poder
desactivar los permisos? AUDIENCIA: Sí. BEN POIESZ: ¿En qué sentido? ¿ Por quién? AUDIENCIA: Para aplicaciones de desarrollo. BEN POIESZ: Para
aplicaciones de desarrollo. AUDIENCIA: Donde el administrador quiere
controlar sus dispositivos. BEN POIESZ: Oh, te entiendo. Entonces, en el caso del propietario del dispositivo
y del perfil, ¿ cuáles son los Android
[? ¿Trabaja?] características que tenemos en Android,
existe la posibilidad de establecer políticas en torno a
los permisos. Dave mencionó un
dispositivo de montaña rusa: es un
dispositivo de un solo uso propiedad de la empresa, como un quiosco. Entonces podría decir: Quiero que
esta aplicación se ejecute.
Quiero que sus permisos se
apliquen a estos valores. Y entonces, como
propietario de un dispositivo en ese escenario, puede dictar los términos. El propietario del dispositivo
no es el administrador del dispositivo, es un concepto diferente. Pero en nuestros
casos es necesario poder tener
un control más estricto. Pero en general, somos
bastante sensibles a la hora de asegurarnos de que los usuarios tengan
todo el poder de esto. AUDIENCIA: Entonces el desarrollo heredado
no tendrá esos permisos. BEN POIESZ: Correcto. Administrador del dispositivo, estamos haciendo la
transición. Entonces tal vez un aparte. Pero estamos haciendo la transición
a un conjunto de funciones más orientada al consumidor en
lugar de un conjunto de funciones corporativas . Siendo el propietario del dispositivo y el
propietario del perfil las herramientas con mejor alcance
y mayor longevidad que el administrador del dispositivo.
AUDIENCIA: OK, gracias. AUDIENCIA: ¿Este código tiene
algún parentesco con la función Apps Ops que fue brevemente… BEN POIESZ: Me quedé en blanco. ¿ Qué fue eso? Estaba esperando
algo que preguntar. Aprendimos mucho de App Ops. Creo que muchos de los
aspectos técnicos de esto son cómo implementamos el
comportamiento alternativo para L. Pero descubrimos, por sí solo, que
sin una revisión, un replanteamiento y una reestructuración más holísticos
de cómo otorgamos los permisos, no funcionó. tiene mucho sentido. Pero tiene algunos
fundamentos a partir de eso. AUDIENCIA: Gracias. AUDIENCIA: Puedo
ver casos en los que puede resultar realmente molesto para
el usuario pedir permiso en tiempo de ejecución. ¿ Existe algún plan para
seguir permitiendo que las personas soliciten permisos todos a la
vez con anticipación? BEN POIESZ: Entonces es
algo que estamos analizando y lo
seguiremos muy de cerca para ver qué está pasando. Yo soy muy
sensible a eso. La razón es que, si terminamos
cansando al usuario con estos, en realidad no
ayudas a las personas.
Y entonces existe este
equilibrio para asegurarnos de que tengamos suficientes
mensajes, pero no tantos como para que a los usuarios les dé
igual. Sólo vete. Así que vamos a estar
atentos a eso. Por el momento, la
razón (para ser franco) por la que lo estructuramos de manera que le
permitimos solicitar muchas pero luego puede
presentarlas una a la vez es que tenemos la API para que pueda
solicitar varias cosas. Y tenemos, entonces, derecho,
en algún momento, a cambiar la UI. Bueno, podríamos decir,
OK, creemos que es más apropiado mostrar
múltiples y una sola vez, en lugar de 101. La razón por la que no lo hicimos fue que, afortunadamente,
muchos equipos fueron
muy honestos con nosotros internamente sobre lo que
planeaban hacer si que existió. Y extrapolamos lo que harían a lo que
vimos en torno a los desarrolladores externos . Y sentimos que la mayoría de las aplicaciones
probablemente simplemente pedirían todo por
adelantado y luego volverían a preguntar individualmente. Y podría decirse que eso es peor que
la situación que tenemos hoy. Esa es la
razón principal por la que no lo hicimos, pero es algo a lo que
estamos atentos.
AUDIENCIA: Gracias. AUDIENCIA: Al igual
que en el anterior, ¿ qué sucede con las
aplicaciones que escuchan intenciones e inician servicios
sin ninguna interfaz de usuario, incluso durante la instalación de la aplicación ? BEN POIESZ: Entonces, para ser honesto, no entiendo las aplicaciones que
no tienen ninguna interfaz de usuario pero necesitan permisos.
Pero hay maneras
de conseguir algo. Si no tiene una
forma adecuada de solicitar algo, digamos que es un servicio en segundo plano
y que es difícil presentarse. Una es que puedes invocar
una actividad directamente. También podrías presentar una
notificación. Y la notificación podría ser
: "Oye, activa este permiso". Y hacen clic en él y
puedes invocar estos diálogos desde la notificación. Entonces tienes algún recurso. Pero la idea es que, incluso si
está en segundo plano, debe poder
presentar su Roi de manera efectiva y su caso de uso al
usuario para explicar por qué desea que se le otorgue ese permiso. AUDIENCIA: Hola. Entonces, si un usuario ha negado
un permiso dos veces y ha dicho,
no me vuelvas a preguntar.
Pero resulta que el
permiso es realmente crítico para que la
aplicación funcione. Dijiste que deberíamos mostrar
algunos mensajes que digan que esto es necesario para activarlo. ¿ Habrá la intención
de que podamos llevarlo directamente
a la configuración de permisos de su aplicación? BEN POIESZ: Sí, entonces puedes
intentar ir directamente a Configuración al nivel superior. Si te han dicho,
no vuelvas a preguntar, solo puedes intentarlo al
nivel de tu aplicación. Si no lo han dicho,
no vuelva a preguntar, entonces tal vez sea la
segunda solicitud y no hayan dicho esa
versión apocalíptica, usted intenta ir directamente a
su página de permisos. Y esa es una diferencia que
hacemos para intentar equilibrar la afirmación del usuario
de que ya no quiere que se le pregunte más. Entonces, en general [INAUDIBLE]
lo importante para modelar es preguntar primero.
Eso es genial. Pero la segunda pregunta,
asegúrese de que el usuario esté en la misma página que usted
antes de volver a preguntar. Y eso es algo así como
filtros o, oye, hago esto. ¿ Está bien? Y ellos dicen, sí. Bien, ahora avisa. Considere que el segundo mensaje
es el más… tenga cuidado con el segundo mensaje, porque
podrían marcar la casilla. AUDIENCIA: Entonces, si ya
fue denegado y dicen, no vuelvas a preguntar, no puedes
ir a la página de configuración de permisos . Pero si no lo han hecho… BEN POIESZ: Si no han
marcado No preguntar de nuevo, entonces puedes ir directamente
a la página de permisos.
Si es así, no puedes. AUDIENCIA: OK, gracias. BEN POIESZ: Sí. AUDIENCIA: Hola. ¿ Las aplicaciones instaladas por OEM siguen
sujetas a las mismas comprobaciones de permisos de tiempo de ejecución? BEN POIESZ: Esa es
una buena pregunta. Entonces sí, lo son. Estamos trabajando en
algunas políticas específicas para evitar situaciones tontas, como
cosas en las que las llamadas no funcionan y cosas así. Pero en general sí. Queremos que
sea un modelo en tiempo de ejecución, por lo que queremos que la
gente pregunte. AUDIENCIA: OK, gracias. BEN POIESZ: Sí. AUDIENCIA: Mencionó
brevemente las intenciones del sistema que implican permisos. Mi pregunta es específicamente
sobre los Contactos. Cuando tienes el selector de personas,
te otorga permisos. En la práctica, creo que
solo se le da permiso al nombre completo y
al número de teléfono. Ni la dirección de correo electrónico
ni nada más. ¿ Existe alguna posibilidad de que puedas
volver a echarle un vistazo? BEN POIESZ: Sí,
lo revisaré nuevamente.
AUDIENCIA: Gracias. AUDIENCIA: ¿Qué pasa si
ha incluido una biblioteca que requiere
permisos y luego la compilamos? BEN POIESZ: Sí. Debes saber qué
piden y necesitan tus bibliotecas. O la biblioteca debería
atender las solicitudes por usted o informarle muy claramente
lo que pueden estar necesitando. Puede crear una
situación extraña para el desarrollador si incluye una biblioteca
y necesita un permiso y comienza a explotar
porque no comprende el nuevo modelo. Pero los compilas
en el nuevo SDK, pero tal vez no estén
listos para el nuevo SDK. Entonces algo a tener en cuenta. No tengo una buena solución para ti,
aparte de decirte que estés atento. AUDIENCIA: Hola. ¿ Tiene algún plan para
diferenciar entre permisos obligatorios y opcionales? BEN POIESZ: No. PÚBLICO: OK. BEN POIESZ: Puedo darte un
poco más de explicación.
Pero la idea es que sentimos
que mucha gente, si hubiera una
opción requerida, muy rápidamente se requeriría la mayoría de las cosas
. Y pensamos que para las aplicaciones
en las que realmente son necesarias, probablemente debería
tener sentido para el usuario según el propósito de
la aplicación. Usaré WhatsApp como ejemplo,
ya que estaban en la keynote. Ellos, desde el principio, quieren
verificar su número de teléfono. Así es como se
aseguran de que eres el propietario del
número de teléfono y hacen referencia a todos tus enlaces.
Entonces, si dices que no a eso,
espero que digan: No sé qué
quieres que haga. Así que creo que habrá
casos bastante claros en los que las aplicaciones adoptarán ese comportamiento, en los que
no necesitarán que el sistema operativo ayude en esa aplicación. AUDIENCIA: OK, gracias. AUDIENCIA: Entonces mi
pregunta ya fue formulada sobre las bibliotecas. ¿ Y qué tan preocupado está
por el comportamiento que romperá con las
bibliotecas antiguas y todo eso? Y también el problema
que se va a crear con los
proveedores de análisis, porque requieren mucho… BEN POIESZ: Lo necesitan. AUDIENCIA: Dependencias
que desconocemos. Eso es algo de qué
preocuparse. BEN POIESZ: Sí,
Lint lo va a marcar.
Así que al menos deberías
poder saberlo. Si miras Lint, te lo
hará saber. AUDIENCIA: Será
algo de [INAUDIBLE]. Entonces cambia mi pregunta. Hablaste de
una biblioteca de soporte que iba con
compatibilidad con versiones anteriores. ¿ Qué estás echando ahí? BEN POIESZ: ¿Eh? AUDIENCIA: ¿Qué estás
poniendo ahí? BEN POIESZ: ¿Qué es? AUDIENCIA: Sí. BEN POIESZ: Es
esencialmente si estás llamando al nuevo código
en tu aplicación.
Así es como me dirijo a API 23. Queremos
asegurarnos de que no explote cuando
ejecute otros sistemas operativos si ejecuta ese código. AUDIENCIA: Entonces el
[? método?] Las comprobaciones estarán en las
bibliotecas de soporte, ¿verdad? BEN POIESZ: No, hay versiones
de ellos en la biblioteca de soporte para sistemas operativos más antiguos, pero están en el
SDK adecuado, el [? SO-SDK. ?] AUDIENCIA: OK, gracias. AUDIENCIA: Vi
que Android M también tiene una nueva capacidad de actualización automática
. ¿ Sabe si los permisos se
transferirán además como parte de esto? BEN POIESZ: ¿Actualización automática? AUDIENCIA: Entonces, si
desinstalara y reinstalara, ¿ tendría todos los
datos anteriores sincronizados con Google Drive? BEN POIESZ: Sí. Los permisos no son
parte de eso. Cuando se desinstale la aplicación
, comenzaremos de nuevo como
si fuera una situación nueva. AUDIENCIA: Está bien. BEN POIESZ: Muy bien. gracias a todos.