Publicado por Quan To, Administrador del programa, seguridad de Android
Hace un año, agregamos las recompensas de seguridad para Android al ya consolidado Programa de recompensas por vulnerabilidades de Google ...Read More

Publicado por Quan To, Administrador del programa, seguridad de Android
Hace un año, agregamos las recompensas de seguridad para Android al ya consolidado Programa de recompensas por vulnerabilidades de Google. Ofrecimos hasta USD 38 000 por cada informe que usamos para corregir vulnerabilidades y proteger a los usuarios de Android.

Desde entonces, hemos recibido de parte de los investigadores más de 250 informes de vulnerabilidad que aportaron solidez a la seguridad de Android y de los dispositivos móviles. Más de la tercera parte de estos informes estuvieron relacionados con Media Server, para la cual se aplicó protección en Android N a fin de darle mayor resistencia a las vulnerabilidades.

Aunque el programa se centra en dispositivos Nexus y su objetivo principal es mejorar la seguridad de Android, más de la cuarta parte de los problemas informados se relacionaron con código desarrollado y empleado fuera del proyecto de código abierto de Android. La corrección de estos errores de controladores del kernel y de los dispositivos ayuda a mejorar la seguridad del contexto más amplio de la industria móvil (e incluso de algunas plataformas no móviles).

Cifras

A continuación, se ofrece un resumen breve del primer año del Programa de recompensas por vulnerabilidades (VRP) de Android:

• Entregamos remuneraciones por más de USD 550 000 a 82 personas. Esto equivale a USD 2200 en promedio por recompensa y USD 6700 por investigador.
• Recompensamos a nuestro mejor investigador, @heisecode, con USD 75 750 por la entrega de 26 informes de vulnerabilidad.
• Pagamos USD 10 000 o más a 15 investigadores.
• No constó de dinero la recompensa principal por una cadena completa de vulnerabilidades de seguridad remotas destinada a comprometer la seguridad de TrustZone o Verified Boot.

Damos nuestro agradecimiento a aquellos que enviaron informes de vulnerabilidades de alta calidad el año pasado.

Mejoras en el VRP de Android

Trabajamos constantemente para mejorar el programa, y hoy aplicaremos algunos cambios respecto de todos los informes de vulnerabilidades presentados después del 1 de junio de 2016.


¡Elevaremos los montos de recompensa!

A partir de ahora, ofreceremos un aumento del 33% por informes de vulnerabilidades de alta calidad con pruebas de concepto. Por ejemplo, la recompensa por un informe de vulnerabilidades críticas que incluya una prueba de concepto aumentará de USD 3000 a 4000.
Para quienes proporcionen un informe de vulnerabilidades de alta calidad con pruebas de concepto, una prueba de CTS o una revisión, el aumento será del 50%.
Aumentaremos de USD 20 000 a 30 000 nuestras recompensas por vulnerabilidades de seguridad remotas o próximas del kernel.
La recompensa por cadenas de vulnerabilidades de seguridad o vulnerabilidades de seguridad remotas destinadas a comprometer la seguridad de TrustZone o Verified Boot aumentará de USD 30 000 a 50 000.
Todos los cambios, y las condiciones adicionales del programa, se explican de manera más detallada en nuestras Reglas del Programa. Si te interesa ayudarnos a encontrar vulnerabilidades de seguridad, visita Bug Hunter University para ver cómo presentar informes de vulnerabilidades de alta calidad. Recuerda: cuanto mejor sea el informe, mayor será tu paga. También actualizamos recientemente nuestras clasificaciones de severidad. Asegúrate de observarlas también.



Agradecemos a todos aquellos que nos ayudaron a aumentar la seguridad de Android. Juntos, hicimos un enorme esfuerzo investigativo en materia de seguridad que permitió reforzar Android. Esto recién comienza, y esperamos obtener aún más logros en el futuro.

Read More

Publicado por Dmitry Malykhanov, Developer Advocate
El vinculador dinámico de Android M y N, relacionado con otras mejoras en la plataforma de Android, tiene requisitos más estrictos para redactar código nativo compatible que sea nuevo y se aplique a varias plataformas. Es necesario que el código nativo de una aplicación cumpla con las reglas y recomendaciones para garantizar una transición fluida hacia versiones de Android recientes.

A continuación, detallamos cada cambio relacionado con la carga de código nativo, las consecuencias y los pasos que puedes seguir para evitar problemas.

Herramientas necesarias: hay un ejecutable <arch>-linux-android-readelf (p. ej., arm-linux-androideabi-readelf o i686-linux-android-readelf) para cada arquitectura en el NDK (dentro de las cadenas de herramientas). Sin embargo, puedes usar readelf para cualquier arquitectura porque solo realizaremos una inspección básica. En Linux, debes tener instalado el paquete “binutils” para readelf y el paquete de “pax-utils” para scanelf.

API privada (aplicada desde la API 24)

Las bibliotecas privadas deben usar únicamente API públicas y no deben establecer vínculos con bibliotecas de plataformas no incluidas en el NDK. A partir de la API 24, esta regla rige y las aplicaciones ya no pueden cargar bibliotecas de plataformas no relacionadas con el NDK. La regla se aplica a través del vinculador dinámico. Por lo tanto, independientemente de la manera en que se intente cargar bibliotecas públicas a través del código, no es posible acceder a ellas: Las entradas System.loadLibrary(...), DT_NEEDED y las llamadas directas a dlopen(...) experimentarán errores de la misma manera.

La experiencia de los usuarios con la aplicación debe ser uniforme en todas las actualizaciones, y los desarrolladores no deben llevar a cabo actualizaciones de emergencia de aplicaciones para manejar cambios de plataforma. Por ese motivo, recomendamos no usar símbolos de C/C++ privados. Los símbolos privados no se comprueban como parte del conjunto de pruebas de compatibilidad (CTS) que deben superar todos los dispositivos Android. Es posible que no existan o que se comporten de manera diferente. Esto aumenta las probabilidades de que las aplicaciones en las cuales se usan experimenten errores en dispositivos específicos o en versiones futuras, lo que les sucedió a muchos desarrolladores cuando en Android 6.0 Marshmallow se realizó un cambio de OpenSSL a BoringSSL.

Con el propósito de reducir el impacto de esta transición para los usuarios, hemos identificado un conjunto de bibliotecas que se usa mucho en las aplicaciones más instaladas de Google Play y para las cuales podemos brindar compatibilidad en el corto plazo (incluidas libandroid_runtime.so, libcutils.so, libcrypto.so y libssl.so). A fin de darte más tiempo para la transición, por el momento ofreceremos compatibilidad para estas bibliotecas. Por ello, si ves una advertencia en la cual se indique que tu código no funcionará en una versión futura, corrígelo cuanto antes.

$ readelf --dynamic libBroken.so | grep NEEDED
 0x00000001 (NEEDED)                     Shared library: [libnativehelper.so]
 0x00000001 (NEEDED)                     Shared library: [libutils.so]
 0x00000001 (NEEDED)                     Shared library: [libstagefright_foundation.so]
 0x00000001 (NEEDED)                     Shared library: [libmedia_jni.so]
 0x00000001 (NEEDED)                     Shared library: [liblog.so]
 0x00000001 (NEEDED)                     Shared library: [libdl.so]
 0x00000001 (NEEDED)                     Shared library: [libz.so]
 0x00000001 (NEEDED)                     Shared library: [libstdc++.so]
 0x00000001 (NEEDED)                     Shared library: [libm.so]
 0x00000001 (NEEDED)                     Shared library: [libc.so]

Posibles problemas: a partir de la API 24, el vinculador dinámico no cargará bibliotecas privadas. Esto evitará que se cargue la aplicación.

Resolución: vuelve a escribir tu código nativo de modo que use únicamente API públicas. Como solución transitoria, se pueden copiar al proyecto las bibliotecas de plataformas sin dependencias complejas (libcutils.so). La solución a largo plazo implica copiar el código correspondiente al árbol de proyectos. No se debe acceder a las API de SSL, medios y clases internal y binder de JNI desde el código nativo. Cuando sea necesario, el código nativo debe llamar a los métodos de API de Java públicas correspondientes.

Se encuentra disponible una lista completa de bibliotecas públicas dentro del NDK, en platforms/android-API/usr/lib.

Nota: SSL/crypto es un caso especial. En las aplicaciones, NO deben usarse la plataforma libcrypto ni las bibliotecas libssl de manera directa, incluso en plataformas anteriores. En todas las aplicaciones, debe usarse el proveedor de seguridad GMS para garantizar la protección de estas contra vulnerabilidades conocidas.

Encabezados de sección faltantes (aplicados desde la API 24)

Cada archivo ELF contiene información adicional en los encabezados de sección. Estos encabezados deben estar presentes, ya que el vinculador dinámico los usa para comprobaciones. Algunos desarrolladores intentan eliminarlos en un intento por ocultar el ejecutable y evitar la ingeniería inversa. (Esto en verdad no sirve porque es posible reconstruir la información eliminada a través de herramientas ampliamente disponibles).

$ readelf --header libBroken.so | grep 'section headers'
  Start of section headers:          0 (bytes into file)
  Size of section headers:           0 (bytes)
  Number of section headers:         0
$ 

Resolución: quita de tu compilación los pasos adicionales con los cuales se eliminen los encabezados de sección.

Reubicaciones de texto (aplicadas desde la API 23)

A partir de la API 23, los objetos compartidos no deben contener reubicaciones de texto. Es decir, el código debe cargarse como esté y no debe modificarse. Este enfoque reduce el tiempo de carga y mejora la seguridad.

Las reubicaciones de texto en general se deben al ensamblador de redacción manual y no independiente de la posición. Esto no es común. Usa la herramienta scanelf según lo descrito en nuestra documentación para ampliar el diagnóstico:

$ scanelf -qT libTextRel.so
  libTextRel.so: (memory/data?) [0x15E0E2] in (optimized out: previous simd_broken_op1) [0x15E0E0]
  libTextRel.so: (memory/data?) [0x15E3B2] in (optimized out: previous simd_broken_op2) [0x15E3B0]
[skipped the rest] 

Si no dispones de la herramienta scanelf, es posible realizar una verificación básica con readelf como alternativa. Busca una entrada o el marcador de TEXTREL. Con cualquiera bastará. (El valor correspondiente a la entrada de TEXTREL es irrelevante y normalmente equivale a 0; con la simple presencia de la entrada de TEXTREL se declara que .so contiene reubicaciones de texto). En este ejemplo, se encuentran ambos indicadores:

$ readelf --dynamic libTextRel.so | grep TEXTREL
 0x00000016 (TEXTREL)                    0x0
 0x0000001e (FLAGS)                      SYMBOLIC TEXTREL BIND_NOW
$

Nota: es técnicamente posible disponer de un objeto compartido con la entrada o el marcador de TEXTREL sin reubicaciones de texto reales. Esto no sucede con el NDK, pero si generas archivos ELF por tu cuenta asegúrate de que en ellos no se soliciten reubicaciones de texto, ya que el vinculador dinámico de Android se rige por la entrada o el marcador.

Posibles problemas: Las reubicaciones imponen páginas de código editables y aumentan, de manera poco económica, el número de páginas desfasadas en la memoria. El vinculador dinámico ha emitido advertencias sobre reubicaciones de texto desde Android K (API 19), y a partir de la API 23 no carga código que las contenga.

Resolución: reescribe el ensamblador para que sea independiente de la posición, a fin de garantizar que no se necesiten reubicaciones de texto. Mira la documentación de Gentoo para hallar fórmulas.

Entradas DT_NEEDED no válidas (aplicadas desde la API 23)

Aunque las dependencias de bibliotecas (entradas DT_NEEDED de los encabezados ELF) pueden ser rutas de acceso absolutas, en Android esto no tiene sentido porque no puedes controlar el destino en el cual el sistema instalará tu biblioteca. Una entrada de DT_NEEDED debe ser igual al SONAME de la biblioteca que se necesita. Esto hará que el vinculador dinámico se encargue de hallar la biblioteca en el tiempo de ejecución.

Antes de la API 23, el vinculador dinámico de Android ignoraba la ruta de acceso completa y usaba solo el basename (la sección posterior a la última “/”) al consultar las bibliotecas requeridas. A partir de la API 23, el vinculador de tiempo de ejecución cumple a la perfección con el DT_NEEDED y, por lo tanto, no puede cargar la biblioteca si no está presente en la ubicación exacta del dispositivo especificada.

Algo aún peor... algunos sistemas de compilación tienen errores por los cuales insertan entradas DT_NEEDED que apuntan a un archivo en el host de compilación, algo que no puede hallarse en el dispositivo.

$ readelf --dynamic libSample.so | grep NEEDED
 0x00000001 (NEEDED)                     Shared library: [libm.so]
 0x00000001 (NEEDED)                     Shared library: [libc.so]
 0x00000001 (NEEDED)                     Shared library: [libdl.so]
 0x00000001 (NEEDED)                     Shared library:
[C:\Users\build\Android\ci\jni\libBroken.so]
$

Posibles problemas: antes de la API 23 se usaba el basename de la entrada DT_NEEDED, pero a partir de esta, el tiempo de ejecución de Android intenta cargar la biblioteca usando la ruta de acceso especificada, y esta no existe en el dispositivo. Hay cadenas de herramientas y sistemas de compilación de terceros dañados que usan una ruta de acceso en un host de compilación en lugar del SONAME.

Resolución: asegúrate de que se haga referencia a todas las bibliotecas requeridas únicamente a través de SONAME. Es mejor dejar que el vinculador de tiempo de ejecución las encuentre y cargue, ya que la ubicación puede cambiar de un dispositivo a otro.

SONAME faltante (en uso a partir de la API 23)

Cada objeto compartido ELF (“biblioteca nativa”) debe tener un atributo SONAME (nombre de objeto compartido). La cadena de herramientas del NDK agrega este atributo de manera predeterminada. Por lo tanto, su ausencia es señal de una mala configuración de la cadena de herramientas o del sistema de compilación. La ausencia de un SONAME puede ocasionar problemas en el tiempo de ejecución, como la carga de la biblioteca incorrecta. Se usa el nombre del archivo en su lugar cuando falta este atributo.

$ readelf --dynamic libWithSoName.so | grep SONAME
 0x0000000e (SONAME)                     Library soname: [libWithSoName.so]
$

Posibles problemas: los conflictos de espacio de nombres pueden hacer que se cargue la biblioteca incorrecta en el tiempo de ejecución. Esto generará fallos cuando no se encuentren los símbolos necesarios o cuando uses una biblioteca incompatible con la ABI que no sea la esperada.

Resolución: el NDK actual genera el SONAME correcto de manera predeterminada. Asegúrate de usar el NDK actual y de no haber configurado tu sistema de compilación de modo que genere entradas de SONAME incorrectas (con la opción de vinculador -soname).

Recuerda que los códigos multiplataforma claros creados con un NDK actual no generarán problemas en Android N. Te sugerimos revisar tu compilación de código nativo para que produzca ejecutables correctos.

En Google, comprendemos la importancia que tiene la calidad en tu aplicación para ampliar tu base de usuarios, aumentar la satisfacción del cliente y potenciar tus ingresos. Cuando vimos en detalle los datos de las reseñas de 1 estrella en Google Play, observamos que más del 50% de estas reseñas se relacionan con errores y fallos de la aplicación.

Muestreo de reseñas en Google Play Store, mayo de 2016

Read More

En Google, comprendemos la importancia que tiene la calidad en tu aplicación para ampliar tu base de usuarios, aumentar la satisfacción del cliente y potenciar tus ingresos. Cuando vimos en detalle los datos de las reseñas de 1 estrella en Google Play, observamos que más del 50% de estas reseñas se relacionan con errores y fallos de la aplicación.

Muestreo de reseñas en Google Play Store, mayo de 2016

Clasificación de reseñas de 1 estrella en Google Play Store

Para muchos desarrolladores, hallar y resolver estos problemas antes del lanzamiento puede ser una tarea muy desafiante. A medida que el ecosistema de Android continúa creciendo rápidamente, puede resultar abrumador el esfuerzo de lograr que una aplicación siga ofreciendo alta calidad y buen rendimiento, y se adapte bien a tus usuarios. A medida que tu base de usuarios crece, es posible que solo puedas acceder a algunos de los dispositivos para realizar pruebas. También resulta difícil acceder a dispositivos que no están disponibles en tu país. A su vez, la configuración de una infraestructura de prueba adecuada que facilite pruebas antes del lanzamiento es un proceso que requiere mucho tiempo y dinero, además de mantenimiento continuo.

Configuración de una infraestructura con un conjunto variado de dispositivos para pruebas

Para optimizar la prueba de aplicaciones móviles, presentamos Test Lab de Firebase para Android, una plataforma en la que puedes automatizar pruebas con las mismas herramientas que Google usa para probar sus propios productos. Con unos pasos sencillos, puedes iniciar tus pruebas en nuestros dispositivos físicos para garantizar la mejor calidad posible en tus aplicaciones.

Tus pruebas, nuestros dispositivos

La realización de pruebas de aplicaciones de Android normalmente implica escribir pruebas de instrumentación para agregar a script las interacciones con la aplicación. Si ya has escrito pruebas con Espresso, UI Automator 2.0 o Robotium, puedes comenzar a ejecutarlas hoy en dispositivos alojados por Test Lab de Firebase.

No escribas pruebas... regístralas

Crear pruebas de instrumentación es más sencillo con Android Studio 2.2 (o versiones posteriores), mediante la herramienta denominadaGrabadora de pruebas Espresso. Lo único que debes hacer es iniciar tu aplicación en el modo de grabación. La grabadora de pruebas registrará y almacenará todas tus interacciones con la aplicación, y luego generará en Espresso el código de prueba que duplicará estas interacciones. Después podrás mejorar y ejecutar estas pruebas en Test Lab de Firebase.

¿No tienes pruebas redactadas? Usa la nuestra

Aunque no escribas tus propias pruebas, puedes usar Test Lab de Firebase. Tenemos una prueba totalmente automatizada conocida comoprueba Robo, que rastreará tu aplicación al realizar interacciones con su interfaz de usuario. No es necesario que escribas una sola línea de código para acceder a los beneficios de esta cobertura automatizada.

Realiza pruebas a escala; tú eliges los dispositivos

Con cada prueba que realices, seleccionarás entre varios fabricantes y modelos de dispositivos, versiones de Android y configuraciones (ahora también se encuentran disponibles dispositivos virtuales a modo de versión beta). Test Lab de Firebase realizará tus pruebas en varios dispositivos simultáneamente para cumplir con tus selecciones lo más rápido posible. Cuando las pruebas finalicen, los resultados se almacenarán en el proyecto de Firebase.

Realiza pruebas a tiempo y con frecuencia

Las pruebas funcionan mejor cuando tienen lugar durante el proceso de desarrollo, no cuando la publicación de tu aplicación en Google Play es inminente. Para simplificar este proceso, Test Lab de Firebase te permitirá invocar pruebas de manera directa desde las herramientas que ya usas; por ejemplo, Android Studio y la consola de Firebase. Nuestrainterfaz de línea de comandos te permite realizar pruebas a través de tu configuración de integración continua. A su vez, después de registrarte para recibir el informe previo al lanzamiento en la Consola de Google Play para desarrolladores, se ofrecerá una prueba Robo de cinco minutos para cada versión nueva de una aplicación que publiques en un canal alfa o beta. Estos resultados de prueba se volverán visibles en la Consola de Google Play Store.

Visualización de resultados de prueba en la consola de Firebase

Precios

El informe previo al lanzamiento de la Consola de Google Play, generado por pruebas Robo, se encuentra actualmente disponible sin cargo. Para realizar más pruebas personalizadas con Test Lab de Firebase, los clientes del plan de facturación Blaze pagarán USD 5 por hora de dispositivos físicos y, después del 1 de octubre de 2016, USD 1 por hora de dispositivos virtuales. Antes de esta fecha, habrá disponibles dispositivos virtuales sin cargo. Consulta nuestra página de precios para obtener información.

¡Comienza a mejorar la calidad de tu aplicación hoy!

Realizar tu primera prueba en Test Lab de Firebase será fácil. Puedes seguir nuestro codelab paso a paso. En él, podrás ver varias situaciones para tu primera prueba. También puedes consultar nuestradocumentación completa aquí. Si tienes dudas o experimentas inconvenientes, has consultas en el grupo de Google de Firebase.

¡Te deseamos mucha suerte en tus pruebas!Publicado por Doug Stevenson, Developer Advocate, y Ahmed Gad, Gerente de producto

Publicado por Tamzin Taylor, Directora de socios estratégicos, Google Play

Hoy lanzamos una serie de videos en tres partes llamada “Tips for your news app on Google Play” (consejos para tu aplicación de noticias en Google Play), en la que podrás hallar consejos aplicables e incorporar prácticas recomendadas para desarrollar, lanzar y monetizar una aplicación de noticias de alta calidad. La serie de videos complementa el recientemente publicado ...Read More

Publicado por Tamzin Taylor, Directora de socios estratégicos, Google Play

Hoy lanzamos una serie de videos en tres partes llamada “Tips for your news app on Google Play” (consejos para tu aplicación de noticias en Google Play), en la que podrás hallar consejos aplicables e incorporar prácticas recomendadas para desarrollar, lanzar y monetizar una aplicación de noticias de alta calidad. La serie de videos complementa el recientemente publicado News Publisher Playbook (manual para editores de noticias).

Mira la serie de videos para aprender lo siguiente:

• Diez consejos sobre cómo diseñar y desarrollar tu aplicación de noticias;
• Diez consejos para ayudarte a lanzar tu aplicación de noticias y comenzar a atraer lectores;
• Diez consejos para captar a tus lectores y monetizar tu aplicación de noticias.

También puedes acceder al nuevo News Publisher Playbook en la Play Store para desarrollar una estrategia móvil de noticias exitosa en Android. En este se incluyen, entre otros aspectos, consejos sobre cómo optimizar sitios web móviles, crear una edición de Newsstand en Google Play y mejorar tu aplicación nativa.

Envíanos tus comentarios

Una vez que veas la serie de videos, nos encantará recibir tus comentarios para poder continuar ayudándote a alcanzar el éxito y lograr tus objetivos de negocios. Deja un comentario o un “Me gusta” y suscríbete en el canal de YouTube para desarrolladores de Android.

También mira nuestros demás videos de la serie Consejos para alcanzar el éxito en Google Play, incluido el recientemente publicado Diez consejos para crear una aplicación para miles de millones de usuarios.

Si deseas conocer más prácticas recomendadas para tener éxito en Google Play, obtén la nueva aplicación Playbook for Developers.

Publicado por Adam Champy, Gerente de producto del SDK de Google Cast
Google Cast permite a los desarrolladores llevar fácilmente las experiencias móviles a las pantallas y los altavoces más atractivos del hogar.Read More

Publicado por Adam Champy, Gerente de producto del SDK de Google Cast
Google Cast permite a los desarrolladores llevar fácilmente las experiencias móviles a las pantallas y los altavoces más atractivos del hogar.

En Google I/O, anunciamos nuestro nuevo SDK de Google Cast. El propósito de este nuevo SDK es lograr que el desarrollo para Cast sea más ágil, confiable y fácil de mantener. Hemos presentado una gestión de estado completa que te ayuda a implementar la abstracción correcta entre tu aplicación y Google Cast. También hemos brindado una experiencia de usuario de Cast completa, lo cual nos permitió cumplir con la lista de comprobación de diseño de Google Cast.

Hoy lanzaremos este SDK para aplicaciones emisoras de Android e iOS, e incluiremos un video introductorio, documentación completa, aplicaciones de ejemplo de referencia y tutoriales de codelab para ambas plataformas. Según los comentarios iniciales de los desarrolladores, las implementaciones por primera vez pueden implicar un considerable ahorro de tiempo de desarrollo en comparación con nuestros previos SDK.

Algunos de los anuncios que realizamos se materializarán en los próximos meses. Entre ellos se incluyen un controlador expandido y la personalización del minicontrolador, para agilizar aún más el desarrollo.

Visita nuestro sitio para desarrolladores de Cast para obtener información sobre las API y el SDK nuevos, y únete a nuestra comunidad de desarrolladores de Google+ eng.co/googlecastdev, donde podrás tratar este asunto con otros desarrolladores.

SwiftShader es una biblioteca de software pensada para la representación de gráficos de alto rendimiento en la CPU. En Google, ya se usa en varios productos, como Chrome, las herramientas de desarrollo de Android y los servicios en la nube. A partir de hoy, Swiftshader será totalmente de código abierto. Esto ampliará su abanico de aplicaciones potenciales.Read More

Publicado por Nicolas Capens, Ingeniero de software y Pixel Pirate

SwiftShader es una biblioteca de software pensada para la representación de gráficos de alto rendimiento en la CPU. En Google, ya se usa en varios productos, como Chrome, las herramientas de desarrollo de Android y los servicios en la nube. A partir de hoy, Swiftshader será totalmente de código abierto. Esto ampliará su abanico de aplicaciones potenciales.

Desde 2009, en Chrome se ha usado SwiftShader para habilitar la representación 3D en sistemas que admiten por completo la representación con aceleración mediante hardware. Aunque el contenido 3D como WebGL se escribe para una GPU, algunos dispositivos de los usuarios no cuentan con hardware gráfico capaz de ejecutarlo. En otros dispositivos, pueden existir errores graves en los controladores por los que la representación 3D podría no ser confiable o incluso posible. En Chrome, se aplica SwiftShader en estos sistemas a fin de garantizar la disponibilidad del contenido web 3D para todos los usuarios.

Sin SwiftShader en una máquina con una GPU inadecuada (izquierda), Chrome no puede ejecutar el experimento de WebGL Globe. Con SwiftShader habilitado (derecha), en la misma máquina se puede representar por completo el contenido.

SwiftShader implementa la misma API de gráficos OpenGL ES que se usa en Chrome y Android. La conversión de SwiftShader al código abierto permitirá que otros proveedores de navegadores admitan contenido 3D de manera universal y supondrá un avance para la toda la plataforma web. En particular, la compatibilidad incondicional con WebGL permite a los desarrolladores web crear contenido más atractivo; por ejemplo, juegos informales, aplicaciones educativas, software de creación de contenido colaborativo, exhibiciones de productos y recorridos visuales, entre otras opciones. SwiftShader también se usa en la nube y hace posible la representación en sistemas sin GPU.


A fin de brindar a los usuarios el mejor rendimiento, en SwiftShader se usan varias técnicas para realizar cálculos de manera eficaz en la CPU. En contraposición a la más frecuente optimización en tiempo de compilación, la generación de código dinámico permite adaptar el código a las tareas en cuestión en tiempo de ejecución. Este enfoque complejo se simplifica usando Reactor, un lenguaje C++ personalizado e integrado de sintaxis imperativa e intuitiva. En SwiftShader también se aplican operaciones vectoriales de tipo SIMT, combinadas con tecnología de múltiples subprocesos, para un mayor paralelismo entre los núcleos y las unidades vectoriales disponibles de la CPU. Esto permite la representación en tiempo real para usos como la representación de aplicaciones en Android.


Los desarrolladores pueden acceder al código fuente de SwiftShader desde su repositorio de git. Regístrate en la lista de distribución para mantenerte actualizado respecto de los desarrollos más recientes y colaborar con otros desarrolladores de SwiftShader de la comunidad de código abierto.

Publicado por Dave Burke, Vicepresidente de ingeniería

Hoy comenzará  la implementación de Android 7.0 Nougat para usuarios. El proceso se iniciará con dispositivos Nexus. Al mismo tiempo, incorporaremos el código fuente de Android 7.0 al proyecto de código abierto de Android (AOSP). Esto extenderá la disponibilidad de esta nueva versión de Android al ecosistema más amplio.Read More

Publicado por Dave Burke, Vicepresidente de ingeniería

Android 7.0 Nougat

Hoy comenzará la implementación de Android 7.0 Nougat para usuarios. El proceso se iniciará con dispositivos Nexus. Al mismo tiempo, incorporaremos el código fuente de Android 7.0 al proyecto de código abierto de Android (AOSP). Esto extenderá la disponibilidad de esta nueva versión de Android al ecosistema más amplio.

Hemos trabajado con ustedes durante los últimos varios meses con el propósito de recibir sus comentarios sobre esta versión y garantizar que sus apps estén listas para los usuarios que las ejecutarán en dispositivos Nougat.

El contenido de Nougat

Android Nougat refleja las contribuciones enviadas desde todas partes del mundo por miles de seguidores y desarrollares como ustedes. En Android Nougat, hay más de 250 funciones importantes, como el modo RV de Android. Trabajamos en todos los niveles de la pila de Android de Nougat (desde la manera en que el sistema operativo lee datos de sensores hasta la manera en que envía píxeles a la pantalla) a fin de que su diseño estuviera especialmente concebido para brindar experiencias de RV móvil de alta calidad.

A su vez, en Nougat se ofrecen varias funciones nuevas para aportar más potencia, productividad y seguridad a Android. Presenta un nuevo compilador JIT/AOT con el objetivo de mejorar el rendimiento del software, agilizar las instalaciones de apps y ocupar menos espacio. También incorpora compatibilidad con plataformas paraVulkan, una API multiplataforma de baja sobrecarga para gráficos 3D de alto rendimiento. La compatibilidad con ventanas múltiples permite a los usuarios ejecutar dos apps al mismo tiempo y Direct Reply hace posible que respondan directamente a las notificaciones, sin necesidad de abrir la app. Como siempre, Android cuenta con poderosas capas de seguridad y encriptación para preservar sus datos privados. Por ello, Nougat ofrece nuevas funciones como la encriptación basada en archivos, actualizaciones ininterrumpidas y Direct Boot.

Podrán encontrar todos los recursos para desarrolladores de Nougat aquí. Se incluye información detallada sobre cambios de comportamiento y nuevas funciones que pueden usar en tus apps. Hay información general disponible aquí sobre las novedades para desarrolladores, y pueden ver todas las funciones nuevas para usuarios de Nougat aquí.

Modo de ventanas múltiples de Android Nougat.

Los próximos usuarios

A partir de hoy, y con un plan de implementación que se extenderá durante las próximas varias semanas, habrá disponible una actualización de software a Android 7.0 Nougat para Nexus 6, Nexus 5X, Nexus 6P, Nexus 9, Nexus Player, Pixel C y General Mobile 4G (Android One). Los dispositivos registrados en el Programa de Android Beta también recibirán esta versión final.

A su vez, nuestros socios lanzarán muchos dispositivos apetecibles con Android Nougat, como el próximo LG V20. Este será el primer smartphone que vendrá con Android Nougat de forma predeterminada.

Debido a que Nougat comenzará a funcionar en todos estos dispositivos nuevos, es el momento de que publiquen sus actualizaciones de apps para Google Play. Recomendamos realizar compilaciones con la API 24 y, de manera ideal, orientadas a ella. Si aún están probando cambios de último momento, una excelente estrategia para hacerlo es usar la función de pruebas beta de Google Play con el fin de recibir comentarios anticipados de un grupo de usuarios reducido (incluidos usuarios de Android 7.0 Nougat) y luego realizar una implementación por etapas a medida que lancen la app actualizada para todos los usuarios.

Lo que viene para Nougat

Dispondremos un nuevo cronograma de mantenimiento regular para Nougat durante los trimestres venideros. De hecho, ya comenzamos a trabajar en la primera versión de mantenimiento de Nougat, en la que se proporcionarán ajustes y mejoras de manera continua, y planeamos ponerla a su disposición este otoño en una versión preliminar para desarrolladores. ¡No se pierdan lo que viene!

Pronto cerraremos los casos de errores abiertos registrados para compilaciones de Developer Preview, pero esperamos continuar recibiendo comentarios. Si continúan observando un problema que registraron en el seguimiento de versiones preliminares, simplemente registren un nuevo problema para Android 7.0 en el seguimiento de problemas del AOSP.

Gracias por ser parte de la versión preliminar, que compartimos a principios de este año con el objetivo de que todos tengan la oportunidad de aportar solidez a la próxima versión de Android. Sus comentarios permanentes han sido extremadamente beneficiosos para dar forma a esta versión final, no solo para los usuarios, sino también para el ecosistema de Android en su totalidad.

Publicado originalmente en el Blog para desarrolladores de Android
Publicado por Sam Dutton y Ankur Kotwal, Developer Advocates, y Liz Yepsen, Administradora del programa ...Read More

Publicado originalmente en el Blog para desarrolladores de Android
Publicado por Sam Dutton y Ankur Kotwal, Developer Advocates, y Liz Yepsen, Administradora del programa

“ADVERTENCIA DE LÍMITE MÁXIMO”. “NO HAY CONEXIÓN”. “EL ANCHO DE BANDA ES INSUFICIENTE PARA REPRODUCIR ESTE RECURSO”.

Estas son advertencias comunes para muchos usuarios de teléfonos inteligentes de todo el mundo.

A fin de crear productos que funcionen para miles de millones de usuarios, los desarrolladores deben enfrentarse a desafíos claves: conectividad limitada o intermitente, compatibilidad con dispositivos, diferentes tamaños de pantalla, altos costos en datos y baterías de corta duración. El mes pasado, en Google I/O presentamos por primera vez developers.google.com/billions junto con recursos para Android y la Web. Hoy, puedes ver las presentaciones en video sobre Android o la Web.

Estas prácticas recomendadas pueden permitir que los desarrolladores alcancen a miles de millones de usuarios al proporcionar un rendimiento excepcional con diferentes conexiones, planes de datos y dispositivos.g.co/dev/billions te ayudará a:

Realizar de manera fluida la transición entre entornos de velocidades bajas a intermedias o sin conexión

Tus usuarios van de un lugar a otro; los entornos que frecuentan pueden variar de la conectividad inalámbrica y las altas velocidades a la transmisión de datos irregular o costosa. Administra estas transiciones almacenando datos, poniendo solicitudes en cola, optimizando el manejo de imágenes y realizando funciones centrales sin conexión.

Brindar el contenido correcto para el contexto indicado

Ten en cuenta el contexto. ¿De qué manera y dónde consumen tu contenido tus usuarios? La selección de texto y medios que funcionen bien con diferentes tamaños de áreas de visualización, la economía textual (para facilitar el desplazamiento en el momento), una IU simple que no genere distracción respecto del contenido y la eliminación del contenido redundante pueden permitir que se aprecie más la calidad de tu aplicación y, al mismo tiempo, proporcionar beneficios reales, como la reducción de la transferencia de datos. Una vez aplicadas estas prácticas, las opciones de localización pueden ampliar la llegada al público y la captación.

Brindar optimizaciones para hardware móvil

Asegúrate de que el contenido de tu aplicación o tu Web se someta a mantenimiento y funcione bien para el segmento de mercado más amplio posible, abarque todas las versiones de los sistemas operativos en uso y, al mismo tiempo, cumpla con las prácticas recomendadas. Para ello, realiza pruebas en dispositivos virtuales o reales de los mercados de destino. Para las aplicaciones nativas de Android se deben establecer SDK mínimos y de destino. A su vez, recuerda que los teléfonos de bajo costo tienen memoria RAM de capacidad más reducida. Por lo tanto, las aplicaciones deben adaptar el consumo de manera correspondiente y minimizar el número de elementos en segundo plano. Para obtener información detallada sobre cómo minimizar el tamaño del APK, lee esta serie de publicaciones de Medium. En la Web, optimiza la carga de JavaScript sobre la CPU, evita la representación de imágenes de trama y minimiza las solicitudes de recursos. Obtén más información aquí.

Reducir el consumo de batería

La duración de las baterías de los teléfonos de bajo costo generalmente es inferior. Los usuarios muestran sensibilidad ante los niveles de consumo de las baterías, y cuando este es excesivo, es posible que eviten tu sitio o que las tasas de desinstalación sean elevadas. Establece valores de referencia para el consumo de batería en sesiones de tus páginas o aplicaciones en comparación con otras, o usa herramientas como Battery Historian y evita procesos prolongados que agotan las baterías.

Conservar el uso de datos

Sin importar la compilación que crees, conserva el uso de datos en tres pasos simples: comprende los requisitos de carga, reduce el volumen de datos necesario para una interacción y optimiza la navegación a fin de que los usuarios obtengan rápidamente lo que buscan. Conservar los datos en representación de tus usuarios (y con aplicaciones nativas, ofrecer uso de red configurable) ayuda a retener usuarios sensibles al consumo de datos, en particular aquellos que usen planes prepagos o tengan contratos con volúmenes de datos limitados, ya que incluso los planes “ilimitados” pueden volverse costosos al activarse la itinerancia de datos o aplicarse tarifas inesperadas.

¿Tienes otra perspectiva o una historia de éxito relacionada con un lanzamiento adecuado a condiciones de baja conectividad o dispositivos de bajo costo? Compártela en nuestra publicación de G+. 

Publicado originalmente por Roy Glasberg Global Lead, Launchpad Accelerator Nos dirigimos a la ciudad de San Francisco para inaugurar un nuevo espacio para Desarrolladores y startups. Con más de 1300 metros cuadrados en el 301 de Howard Street, tenemos más que suficiente espacio para entrenar, educar y colaborar con los ecosistemas locales e internacionales de startups y desarrolladores. Este espacio funcionará como huésped para una gran variedad de eventos: encuentros de ...Read More

Publicado originalmente por Roy Glasberg Global Lead, Launchpad Accelerator

Nos dirigimos a la ciudad de San Francisco para inaugurar un nuevo espacio para Desarrolladores y startups. Con más de 1300 metros cuadrados en el 301 de Howard Street, tenemos más que suficiente espacio para entrenar, educar y colaborar con los ecosistemas locales e internacionales de startups y desarrolladores. Este espacio funcionará como huésped para una gran variedad de eventos: encuentros de Google Developer Groups , Design Sprints y charlas técnicas. 

También alojará a la tercera generación de Launchpad Accelerator, nuestra aceleradora equity-free para startups en mercados emergentes. Durante cada clase más de 20 equipos de Google proveen mentoría a emprendimientos en etapas avanzadas que buscan escalar y convertirse líderes en sus mercados. El programa de 3 meses inicia con un taller con todos los gastos cubiertos a las oficinas centrales de Google.

Los desarrolladores trabajan en una industria de cambio constante y por eso están siempre buscando capacitación, además hemos visto un gran número de desarrolladores que inician sus propias compañías. Esta es una oportunidad para cerrar la brecha entre Silicon Valley y los mercados emergentes. Al día de hoy, Launchpad Accelerator tiene 50 graduados en India, Indonesia, Brasil y México. Los emprendimientos en estos mercados estan atacando problemas locales pero generalmente no cuentan con los recursos y redes con los que contamos, este espacio dedicado nos permitirá interactuar de manera regular con desarrolladores para ayudarlos a construir, crecer o monetizar sus proyectos.

No podemos esperar para empezar a trabajar con desarrolladores para construir negocios exitosos que tengan un impacto positivo tanto en la economía local como en la global.

Publicado por Shanea King-Roberson, Administradora principal del programa Twitter: @shaneakr Instagram: @theshanea



¿Tienes una idea para una aplicación y no sabes por dónde comenzar? En el mundo, hay más de 1000 millones de dispositivos Android. Esto te permite hacer llegar tus ideas a las personas adecuadas en el momento indicado. En asociación con Udacity, Google está logrando que todos puedan acceder al desarrollo de Android y comprenderlo. Sin importar tu formación, puedes aprender a crear aplicaciones que mejoren las vidas de las personas a tu alrededor.Read More

Publicado por Shanea King-Roberson, Administradora principal del programa Twitter: @shaneakr Instagram: @theshanea



¿Tienes una idea para una aplicación y no sabes por dónde comenzar? En el mundo, hay más de 1000 millones de dispositivos Android. Esto te permite hacer llegar tus ideas a las personas adecuadas en el momento indicado. En asociación con Udacity, Google está logrando que todos puedan acceder al desarrollo de Android y comprenderlo. Sin importar tu formación, puedes aprender a crear aplicaciones que mejoren las vidas de las personas a tu alrededor.

Regístrate en el nuevo curso Android Basics Nanodegree. Con esta serie de cursos y servicios, podrás aprender a crear aplicaciones de Android simples aunque tu experiencia sea reducida o nula. Observa algunas de las aplicaciones creadas por nuestros estudiantes:

La aplicación “ROP Tutorial”, creada por el estudiante Arpy Vanyan, permite despertar conciencia respecto de un desorden conocido como retinopatía de la prematuridad, que puede afectar a los recién nacidos y producir ceguera.
El usuario Charles Tommo creó una aplicación llamada “Dr Malaria”, con la cual se aprende a prevenir la malaria.

A través de cursos diseñados por Google, puedes incorporar capacidades aplicables a la creación de aplicaciones que permitan resolver problemas reales. Puedes aprender a usar Android Studio (la herramienta oficial de Google para el desarrollo de aplicaciones de Android) a tu propio ritmo, y aplicarla en el diseño de interfaces de usuario de aplicaciones y la implementación de interacciones con usuarios mediante el lenguaje de programación Java.


Los cursos te permitirán conocer, paso a paso, la creación de un formulario de pedido de una cafetería o de aplicaciones para realizar un seguimiento de las mascotas de un refugio, para aprender palabras del vocabulario de la tribu estadounidense de los miwok y para ofrecer información sobre terremotos recientes en el mundo. Al finalizar el curso, contarás con una cartera completa de carpetas para compartir con amigos y familiares.


Después de completar el curso Android Basics Nanodegree, también tendrás la oportunidad de continuar con tu aprendizaje a través del curso Career-track Android Nanodegree (para desarrolladores intermedios). Los primeros 50 participantes que finalicen el curso Android Basics Nanodegree tendrán la oportunidad de ganar una beca para Career-track Android Nanodegree. Visita udacity.com/legal/scholarship para obtener información adicional y conocer los requisitos de elegibilidad. Ahora podrás acceder a un medio de aprendizaje que te permitirá convertirte en un empresario de la tecnología o, lo que es más importante, crear aplicaciones de Android muy buenas para ti mismo, la comunidad e incluso el mundo.


Todos los cursos individuales que componen a esta serie Nanodegree se encuentran disponibles sin costo enudacity.com/google. A su vez, Udacity ofrece servicios pagos. Entre otros, acceso a instructores, orientación en tu proyecto, asistencia para que te mantengas enfocado, orientación vocacional y un certificado tras la finalización.


Conocerás conceptos introductorios de informática relacionados con el lenguaje de programación Java a medida que incorpores las siguientes capacidades:

• creación de interfaces de usuario; 
• implementación de interacciones de usuarios; 
• almacenamiento de información en una base de datos; 
• incorporación de datos de Internet a tu aplicación; 
• identificación y corrección de comportamientos inesperados en la aplicación; 
• localización de tu aplicación para admitir otros idiomas.

Para registrarte en programa Android Basics Nanodegree, haz clic aquí.

¡Nos vemos en clase!

Publicado por Bhavik Singh, Gerente de producto
El mes pasado, en Google I/O 2016, anunciamos las nuevas API de reconocimiento de Google que permiten a tus aplicaciones responder según el contexto del usuario usando capturas de pantalla y límites, con un impacto mínimo en los recursos del sistema.Read More

Publicado por Bhavik Singh, Gerente de producto
El mes pasado, en Google I/O 2016, anunciamos las nuevas API de reconocimiento de Google que permiten a tus aplicaciones responder según el contexto del usuario usando capturas de pantalla y límites, con un impacto mínimo en los recursos del sistema.

Hoy, tenemos el orgullo de anunciar que la API de reconocimiento de Google se encuentra disponible para todos los desarrolladores a través de Servicios Google Play.

Con 7 clases diferentes de contexto (como la ubicación, el clima, la actividad del usuario y las balizas cercanas), tu aplicación puede reconocer mejor las situaciones actuales de tus usuarios y usar esta información para brindar experiencias optimizadas y personalizadas.

La API de reconocimiento ofrece dos maneras de aprovechar señales de contexto dentro de tu aplicación:

• La API de captura de pantalla permite que tu aplicación solicite fácilmente información sobre el contexto actual del usuario. Por ejemplo, “dime la ubicación actual del usuario y las condiciones climáticas del momento”.
• La API de límites permite que tu aplicación responda a cambios en el contexto del usuario (y cuando este coincide con determinadas condiciones). Por ejemplo, “dime cuando el usuario esté caminando y sus auriculares estén conectados”. Casi como en el caso de la API de perímetro, una vez que se registra un límite, puede enviar callbacks a tu aplicación aun cuando no se encuentra en ejecución.

Como superficies sencillas y simplificadas, las API de reconocimiento ofrecen una combinación de señales de contexto procesadas de manera óptima con métodos antes imposibles. Esto proporciona indicios contextuales detallados y, al mismo tiempo, administra recursos del sistema para ahorrar batería y minimizar el ancho de banda.

Hemos trabajado en estrecha colaboración con algunos de nuestros socios, quienes ya han encontrado fabulosas maneras de integrar el reconocimiento de contextos a sus aplicaciones:






En Trulia, un sitio inmobiliario residencial de Internet, se usa nuestra API de límites para sugerir la presencia de casas disponibles. Cuando el clima es ideal y el usuario se encuentra cerca de una casa que le interesa, Trulia le envía una notificación que le recuerda ir a verla. Esta especie de notificación a medida puede permitir que los usuarios visiten casas disponibles en el momento que les resulte ideal.


En SuperPlayer Music, por otra parte, se usan la API de captura de pantalla y la API de límites para sugerir la música ideal según tu estado de ánimo. Si estás terminando de correr e iniciando el estiramiento, partiendo en tu auto hacia destino lejano o simplemente llegando al gimnasio, el asistente de esta plataforma puede reconocer tu contexto y sugerir la playlist adecuada para ti.

Con nuestro conjunto inicial de señales y nuestros fabulosos socios, este emprendimiento de las API de reconocimiento recién comienza. Únete a nosotros en la búsqueda de experiencias a medida para tus aplicaciones, comenzando por leer ladocumentación para desarrolladores de API de reconocimiento de Google, y obtén más información mirando nuestra sesión de Google I/O.

Publicado por Sergio Giro, Ingeniero de software

Read More

Publicado por Sergio Giro, Ingeniero de software

Si tu aplicación de Android deriva claves a través del algoritmo SHA1PRNG del proveedor Crypto, deberás comenzar a usar una función de derivación de claves y probablemente volver a cifrar tus datos.

La arquitectura de criptografía de Java permite a los desarrolladores crear una instancia de una clase como un cifrado, o un generador pseudoaleatorio, al usar llamadas como las siguientes:

SomeClass.getInstance("SomeAlgorithm", "SomeProvider");

O simplemente:

SomeClass.getInstance("SomeAlgorithm");

Por ejemplo,

Cipher.getInstance(“AES/CBC/PKCS5PADDING”); 

SecureRandom.getInstance(“SHA1PRNG”);

En el caso de Android, no recomendamos especificar el proveedor. En general, cualquier llamada a las API de la extensión de criptografía de Java (JCE) en la que se especifique un proveedor solo debe realizarse si este se incluye en la aplicación, o si esta última puede manejar una posible ProviderNotFoundException.

Desafortunadamente, muchas aplicaciones dependen del proveedor “Crypto”, ahora eliminado, para un antipatrón de derivación de claves.

Este proveedor solo proporcionaba una implementación del algoritmo SHA1PRNG para instancias de SecureRandom. El problema es que este algoritmo no ofrece solidez en términos de criptografía. Para los lectores interesados en los pormenores, en la sección 8.1 de On statistical distance based testing of pseudo random sequences and experiments with PHP and Debian OpenSSL (acerca de las pruebas basadas en distancias estadísticas de secuencias pseudoaleatorias y experimentos con PHP y Debian OpenSSL), escrita por Yongge Want y Tony Nicol, se afirma que la secuencia “aleatoria”, considerada como un formato binario, se ve restringida a la devolución de ceros, y que esta restricción se acentúa según la inicialización.

Como resultado, en Android N dejaremos sin efecto el algoritmo SHA1PRNG y el proveedor Crypto. Anteriormente, habíamos solucionado los inconvenientes del uso de SecureRandom para la derivación de claves unos años atrás, en Using Cryptography to Store Credentials Safely (uso de la criptografía para el almacenamiento seguro de credenciales). Sin embargo, debido al uso continuo que se da a esta clase, la repasaremos aquí.

Una aplicación común, aunque incorrecta, de este proveedor se destinaba a derivar claves para cifrado con una contraseña como elemento de inicialización. La implementación de SHA1PRNG suponía un error que lo hacía funcionar de manera determinista si se llamaba a setSeed() antes de obtener una salida. Este error se empleaba para derivar una clave proporcionando una contraseña como elemento de inicialización y luego usando los bytes de salida “aleatorios” de la clave (“aleatorios” en esta oración significa “predecibles e inseguros en términos criptográficos”). Esta clave se podía usar posteriormente para cifrar y descifrar datos.

En la sección siguiente, se explica la manera correcta de derivar claves y de descifrar datos cifrados con una clave insegura. También se ofrece un ejemplo completo, en el que se incluye una clase auxiliar para usar la funcionalidad de SHA1PRNG en desuso, con el propósito exclusivo de descifrar datos que de lo contrario no estarían disponibles.

Las claves pueden derivarse de la siguiente manera:

• Si lees una clave AES de un disco, almacena la clave real y evita las complicaciones. Puedes obtener una interfaz SecretKey para el uso de claves AES a partir de los bytes de la siguiente manera:

SecretKey key = new SecretKeySpec(keyBytes, "AES");

• Si usas una contraseña para derivar una clave, sigue el excelente tutorial de Nikolay Elenkov considerando la advertencia de que una buena regla de oro supone que el tamaño del valor salt debe ser igual al de la salida de la clave. El aspecto resultante será el siguiente:

   /* User types in their password: */  
String password = "password";  


   /* Store these things on disk used to derive key later: */  
int iterationCount = 1000;  
   int saltLength = 32; // bytes; should be the same size

   int keyLength = 256; // 256-bits for AES-256, 128-bits for AES-128, etc  
as the output (256 / 8 = 32)  
   byte[] salt; // Should be of saltLength  


   byte[] salt = new byte[saltLength];  
/* When first creating the key, obtain a salt with this: */  
   SecureRandom random = new SecureRandom();  
   random.nextBytes(salt);  


              iterationCount, keyLength);  
/* Use this to derive the key from the password: */  
   KeySpec keySpec = new PBEKeySpec(password.toCharArray(), salt,  
   SecretKeyFactory keyFactory = SecretKeyFactory  

   SecretKey key = new SecretKeySpec(keyBytes, "AES");  
.getInstance("PBKDF2WithHmacSHA1");  

   byte[] keyBytes = keyFactory.generateSecret(keySpec).getEncoded();  

Eso es todo. No necesitarás nada más.

Para facilitar la transición de datos, abarcamos el caso de desarrolladores que cifran datos con una clave insegura, derivada de una contraseña en cada ocasión. Puedes usar la clase auxiliar InsecureSHA1PRNGKeyDerivator en la aplicación de ejemplo para derivar la clave.

 private static SecretKey deriveKeyInsecurely(String password, int
keySizeInBytes) {  

    byte[] passwordBytes = password.getBytes(StandardCharsets.US_ASCII);  
return new SecretKeySpec(  
            InsecureSHA1PRNGKeyDerivator.deriveInsecureKey(  

 }  
passwordBytes, keySizeInBytes),  

            "AES");  

Luego, puedes volver a cifrar tus datos con una clave derivada de manera segura, conforme a la explicación anterior, y seguir adelante sin problemas.

Nota 1: Como medida temporal para que las aplicaciones continúen funcionando, decidimos crear de todos modos la instancia para las aplicaciones orientadas a la versión 23 del SDK, para Marshmallow, o a versiones anteriores. No confíes en la presencia del proveedor Crypto en el Android SDK; nuestro plan es eliminarlo por completo en el futuro.

Nota 2: Debido a que en muchas secciones del sistema se considera que existe un algoritmo SHA1PRNG, cuando se solicita una instancia de este y no se especifica el proveedor devolvemos una instancia de la clase OpenSSLRandom, la cual representa una fuente sólida de números aleatorios derivados de OpenSSL.

Publicado por Sergio Giro, Ingeniero de software

Publicado por Laurence Moroney, Developer Advocate

Ha pasado un tiempo desde nuestro último lanzamiento relacionado con Servicios Google Play. Esto se debe a que hemos estado ocupados con la integración de Firebase. Aunque Firebase contendrá los SDK que has llegado a conocer y apreciar para la creación de aplicaciones móviles que funcionan en diferentes plataformas, también continuaremos enviando actualizaciones de Servicios Google Play con los nuevos SDK de manera frecuente. Firebase se creó con Servicios Google Play 9.0. Veamos, entonces, de manera un poco más detallada algunas de las API nuevas y prácticas disponibles en esta versión.Read More

Publicado por Laurence Moroney, Developer Advocate

Ha pasado un tiempo desde nuestro último lanzamiento relacionado con Servicios Google Play. Esto se debe a que hemos estado ocupados con la integración de Firebase. Aunque Firebase contendrá los SDK que has llegado a conocer y apreciar para la creación de aplicaciones móviles que funcionan en diferentes plataformas, también continuaremos enviando actualizaciones de Servicios Google Play con los nuevos SDK de manera frecuente. Firebase se creó con Servicios Google Play 9.0. Veamos, entonces, de manera un poco más detallada algunas de las API nuevas y prácticas disponibles en esta versión.

Anuncios

En caso de que crees aplicaciones que se moneticen con anuncios, hemos agregado muchas actualizaciones desde la versión 8.4. Existe un nuevo método de inicialización que los editores pueden usar para poner en marcha el SDK en el inicio de la aplicación. También hay un nuevo formato de anuncios nativos: Native Ads Express. Con Native Ads Express, los editores pueden definir para sus Ad Unit plantillas de CSS que definan las fuentes, los colores, el posicionamiento y otra información de estilo. AdMob combina esto con recursos de anunciantes, como encabezados y llamadas a la acción, para completar el anuncio, que se muestra en un elemento NativeExpressAdView. Al eliminarse el trabajo de personalización de la presentación del dispositivo, la necesidad de código móvil es menor. A su vez, es posible actualizar plantillas sin volver a implementar la aplicación.

Nearby

Continuaremos actualizando la exploración de balizas BLE en Nearby Messages. Cualquier aplicación con ACCESS_FINE_LOCATION podrá realizar exploraciones en busca de balizas a través de Nearby sin permisos adicionales. Recomendamos a los desarrolladores verificar si la aplicación tiene el permiso de ubicación antes de llamar a GoogleApiClient.connect(). Comienza aquí.

Para Nearby Messages punto a punto, ahora existe una opción de mostrar el diálogo de registro tras la conexión a GoogleApiClient. Esto reduce considerablemente el código estándar para obtener el permiso de Nearby.

Player Stats API

También continuaremos actualizando el Play Games Client SDK con mejoras en la Player Stat API y la publicación de la API de grabación de video. La Player Stats API ahora viene con análisis predictivo para ayudarte a identificar los grupos de jugadores que pueden gastar dinero o migrar. También agregaremos predicciones nuevas para calcular los posibles gastos de un jugador cada 28 días y la probabilidad de que tenga un nivel de consumo elevado. Esto te permite adaptar las experiencias en función de jugadores como estos, para intentar que sus gastos o su captación aumenten. Obtén más información sobre la Player Stats API.

API de grabación de video

Podrás agregar fácilmente grabaciones de video a tu aplicación y permitir que los usuarios compartan los suyos con amigos en YouTube mediante una serie de simples pasos. En los próximos meses, también agregaremos funcionalidades de transmisión en tiempo real para que tus seguidores difundan sus experiencias de juego en YouTube mientras se desarrollan.

Así concluye este lanzamiento de Servicios Google Play 9.0. Continuaremos enviando nuevas API en todo momento; visita este blog para encontrar futuros anuncios.

Read More

Publicado por Ian Lake, Representante de desarrolladores

Desde el lugar del desarrollador, existe una amplia variedad de funciones agregadas a Android N que pueden aprovecharse, pero cuando se trata del diseño y de la creación de una IU propia, lo que más debería importar sería disponer de compatibilidad con ventanas múltiples.

El modo principal a través del cual los usuarios interactuarán con ventanas múltiples es el modo de pantalla dividida, disponible en dispositivos portátiles y tablets de mayor tamaño. En este modo, dos aplicaciones dividen el espacio de pantalla disponible y el usuario puede arrastrar la línea divisoria entre las dos pantallas separadas para cambiar el tamaño de las aplicaciones. Como podrás imaginar, este modo presenta algunos desafíos de diseño únicos que se encuentran más allá de lo que era necesario anteriormente.

Una IU aún más receptiva

Lo aprendido con versiones anteriores de Android, la Web móvil y los entornos de escritorio aún se aplica a Android N. Diseñar una IU receptiva continúa siendo un primer paso importante en el camino hacia una fabulosa experiencia con ventanas múltiples.

Una IU receptiva puede adaptarse al tamaño provisto y también seleccionar la mejor representación del contenido y los patrones de navegación correspondientes para brindar una experiencia de usuario excelente en cualquier dispositivo. Consulta la publicación del blog Cómo crear una IU receptiva para obtener información detallada sobre la manera de diseñar y crear una IU eficaz y receptiva.

Cómo adaptar tu diseño

Debido a que crearás diseños para las pantallas más grandes y pequeñas, y para todas las variantes intermedias, es importante hacer que la transición del cambio de tamaño sea pareja y perfecta, como se menciona en las pautas de diseño para pantallas divididas. Si ya dispones de un diseño similar para dispositivos móviles y tablets, verás que la mayor parte del trabajo ya está hecha.

Sin embargo, si tus diseños de dispositivos móviles y tablets son muy diferentes y no existe una manera de lograr una transición pareja entre los dos, deberás evitar la transición entre ellos al cambiar el tamaño. En lugar de ello, concéntrate en hacer que tu IU para tablets se reduzca usando los mismos patrones de IU receptiva. Esto garantiza que los usuarios no tengan que familiarizarse de nuevo con la IU al cambiar el tamaño en tu aplicación.

Ten en cuenta que los atributos de diseño minimalHeight y minimalWidth te permiten fijar un tamaño mínimo que desees informar a tu actividad, pero esto no implica que el usuario no pueda reducir el tamaño de tu actividad, sino más bien que tu actividad se recortará hasta tener el tamaño solicitado por el usuario. Esto puede desplazar elementos de tu IU de la pantalla. Intenta ofrecer compatibilidad con el tamaño mínimo de 220 x 220 dp.

Configuraciones de diseño que deben considerarse

Aunque una gran parte de los tamaños y las relaciones de aspecto posibles para ventanas múltiples son similares a los que ofrecen los dispositivos existentes (en términos de tamaño de pantalla, la tercera parte de una tablet en modo horizontal equivale a un dispositivo móvil), existen algunas configuraciones que son mucho más comunes al considerar el modo de ventanas múltiples.

La primera es la del diseño 16:9 en el modo vertical en dispositivos móviles. En este caso, el espacio vertical es extremadamente limitado. Si hay un número de elementos fijos dispuestos uno encima de otro (una barra de herramientas, contenido desplazable y una barra de navegación inferior), probablemente descubras que no hay espacio para el contenido desplazable. ¡El elemento más importante!

El segundo caso que debe considerarse es el del diseño “34,15 %” de las tablets. Las relaciones de aspecto (muy ancho en la orientación vertical o muy alto en la orientación horizontal) son superiores a las que se encuentran en los dispositivos existentes. Considera usar tus diseños para dispositivos móviles como punto de partida para esta configuración.

Patrones que deben evitarse

Cuando se trata de ventanas múltiples, hay algunos patrones que debes evitar por completo.

El primero tiene que ver con las interacciones de IU que se basan en el deslizamiento desde el borde de la pantalla. Esto ha generado inconvenientes en cuanto a la barra de navegación de la pantalla que se destaca en muchos dispositivos (como los Nexus), pero resulta más problemático en el modo de pantalla dividida. Debido a que (intencionalmente) no existe una manera de determinar si tu actividad se encuentra en la parte superior, inferior, izquierda o derecha, procura que el deslizamiento desde los bordes no sea la única manera de acceder a la funcionalidad de tu aplicación. Esto no significa que debas evitarlo totalmente, sino que te asegures de que haya una alternativa. Un buen ejemplo de esto es el panel lateral de navegación: con un deslizamiento desde el borde se abre, pero también es posible acceder a él presionando el icono de la hamburguesa de la barra de herramientas.

El segundo consiste en deshabilitar totalmente las ventanas múltiples. Aunque ciertamente existen casos en los cuales esto tiene sentido (cuando, como en un juego, la experiencia es totalmente inmersiva), también hay situaciones en las que tu actividad y cualquier actividad iniciada desde ella deban admitir ventanas múltiples de manera forzosa. Como se señala en la publicación del blog sobre cómo prepararse para ventanas múltiples, cuando admites que aplicaciones externas inicien tu actividad, esta última hereda las propiedades de ventanas múltiples de la actividad que realiza la llamada.

El diseño para ventanas múltiples debe adecuarse a cualquier dispositivo

Crear una IU receptiva que responda al espacio disponible es fundamental para lograr una excelente experiencia de ventanas múltiples, pero es una práctica que puede beneficiar a todos tus usuarios dentro de la amplia variedad de dispositivos Android.

Aprovecha esta oportunidad para #BuildBetterApps

Sigue la actividad en la Colección de patrones de desarrollo de Android para informarte más.