publicado a la(s) 11/05/2011 01:46 por Damasia Maneiro
Google acaba de celebrar su conferencia anual, la Google I/O 2011, que un año más ha protagonizado Android. Tal como se rumoreaba, Google ha presentado el nombre oficial del próximo SO para la plataforma Android, Ice Cream Sandwich (o Android 2.4), y aunque no se ha dicho exactamente sus características ni fecha de lanzamiento (se supone que para final de año), se sabe que es un sistema operativo que intentará unir todas las plataformas: tablets, smartphones… 
El resto de novedades: - Actualización de Honeycomb 3.1, incluye jugosas novedades, en especial una base de herramientas de desarrollo para hacer compatible cualquier accesorio con Android, por ejemplo el pad USB de Xbox 360. - Google Music: Es el nuevo servicio de música streaming de Google, además de ser compatible con Android también es un servicio vía web, así que se podrá utilizar en cualquier dispositivo. La inscripción a la beta vía web está restringida a Estados Unidos, pero puedes instalar el servicio en Android (seas yankee o no), con este .apk. Permitirá almacenar hasta 20.000 canciones en la nube gratuitamente. - Compra de Películas y Libros directamente en el Android Market: De momento solo para Estados Unidos, el resto del mundo tendrá que esperar. - Androit @ Home: ¿Te imaginas controlar la calefacción, las luces de tu casa o el home cinema desde tu terminal Android? Pues con esto será posible. Domótica Android. De momento está en fase experimental. |
publicado a la(s) 25/11/2010 04:28 por German Viscuso
[
actualizado el 25/11/2010 04:30
]
Google ha contactado con desarrolladores Android registrados para anunciar cambios en el Android Market orientados a mejorar la visualización previa de aplicaciones. 
Los desarrolladores cuentan ahora con una nueva funcionalidad para la publicación de actualizaciones de aplicaciones que permite enviar una versión preliminar desde la consola del Market sin que esta sea inmediatamente visible (a menos que se haga un ‘Publish’). También se ha extendido el rango de imagenes promocionales asociadas a la aplicación: además de la típica captura de pantalla que normalmente se requiere ahora debes enviar un gráfico promocional de alta resolución (1024 x 500 px), un icono también en alta resolución (512 x 512 px), capturas de pantalla en varios tamaños (habrá 8 opciones, al menos una es requerida) y opcionalmente un enlace a un video YouTube de tu aplicación. Por ultimo se ha agregado soporte para asociar un bloque de texto descriptivo específico para las actualizaciones de las aplicaciones que luego los usuarios verán como “Cambios Recientes”. Además de notificar sobre estos cambios Google también ha enviado un e-mail general para desarrolladores notificando que suspenderá cualquier actualización en la consola del Android Market entre jueves y viernes (jueves 10 PM a viernes 4 AM, PST) para realizar un mantenimiento planificado (sin que estos cambios afecten la experiencia del lado del usuario final). Estos cambios junto con la baja temporal de la consola podrían ser el preludio a todas las nuevas características del Android Market anunciadas en Google IO2010. Con la introducción de estas mejoras los usuarios contarán con mejor información a la hora de decidirse por una aplicación. Esperemos que así el Android Market pueda ir alcanzando de a poco al App Store que ofrece una excelente experiencia de usuario a la hora de descubrir e indagar sobre aplicaciones. |
publicado a la(s) 30/08/2010 22:19 por German Viscuso
AndroidNerdDinner es un proyecto cuyo objectivo es proveer un cliente Android para nerdinner.com, un sitio que permite a frikis e informáticos organizar reuniones en cualquier parte del mundo.
Si visitamos nerdinner.com veremos que la funcionalidad básica consiste en la visualización, búsqueda y creación de reuniones. A pesar de ser un proyecto relativamente sencillo constituye un buen ejemplo en Android ya que no permitirá meternos en varios temas interesantes (creación de una GUI, manejo de mapas en Android, uso de un servicio REST y sincronización, uso de una base de objetos como cache local).
Se trata de un proyecto que se realizará a nivel grupal en AndroidStartup. Hemos comenzado a organizarnos en el wiki: |
publicado a la(s) 24/08/2010 15:35 por German Viscuso
[
actualizado el 24/08/2010 15:58
]
- El Licensing service es definitivamente un paso adelante en lo que a protección de apps se refiere
- La LVL permite incorporar formas de autenticación personalizadas para hacer la verificación tan segura como se requiera. En esta primera versión se incluyeron dos ejemplos muy sencillos que no hacen incapié en la seguridad sino en la facilidad de uso para que los desarrolladores puedan comprender como funciona
- Algunos desarrolladores están utilizando estos ejemplos de verificación básicos sin modificación lo que hace más vulnerable a la app. Y, aun mas importante, los casos vulnerables mostrados son todos sobre aplicaciones que no han utilizado ofuscamiento como se describe en la documentación de la LVL. Pronto Google proveerá más material sobre como realizar el ofuscamiento
- Por el momento solo unas pocas aplicaciones han incorporado la LVL pero su adopción crecerá ya que se trata de un paso adelante
- No es posible proveer un sistema antipiratería 100% efectivo pero la LVL hace mucho más dificíl el pirateo de apps
- La mejor estrategia para desarrolladores es hacer lo más dificil posible el camino que lleva a apps pirateadas a la par que se hace muy sencillo el camino por la via legal (aplicaciones accesibles, baratas, etc). La pirateria es un mal negocio cuando el usuario tiene que optar por comprar una app a un precio razonable por la via legal comparado a tener que visitar un oscuro sitio pirata de dudosa reputación para obtener la app gratis
- El Android Market es seguro y amigable con los desarrolladores, la LVL es un paso adelante para hacerlo más seguro
|
publicado a la(s) 23/08/2010 18:27 por German Viscuso
Si, aparentemente es muy fácil crackear los APKs que utilizan la recientemente introducida LVL ( ver nuestro articulo) que permite verificar que se tiene derecho a utilizar la app. Espero que esto no cause que varias compañias decidan no generar versiones Android de sus apps. Le dejo un video demostrativo:
|
publicado a la(s) 17/08/2010 11:45 por Damasia Maneiro
[
actualizado el 24/08/2010 15:44
]
El nuevo servicio de licenciamiento del AndroidMarket permite que una aplicación determine si existe una licencia para un usuario y terminal específico a traves de una consulta al servidor de licenciamiento del AndroidMarket. Segun la respuesta del servidor se podrá acceder o no a la aplicación de manera completa o parcial. La aplicación por si misma es la responsable de solicitar el estado de licenciamiento al servidor y permitir los accesos correspondientes. Aplicación, Cliente del AndroidMarket y Servidor El servicio de licenciamiento se basa en la capacidad del servidor del Android Market en determinar si un usuario tiene licencia para usar una determinada aplicación. El servidor considera que un usuario tiene licencia si se ha registrado previamente para solicitar la aplicación o si la app es libre (tiene licencia para todos los usuarios). Para identificar el usuario y determinar el estado de licenciamiento, el servidor requiere información sobre la aplicación y el usuario. Para ello la aplicación y el cliente de AndroidMarket trabajan conjuntamente para ensamblar esta información y enviarsela al servidor. La comunicación entre la aplicación y el cliente es via IPC remoto: - La aplicación provee su nombre de paquete que mas tarde es utilizada por el servidor para enviar una respuesta.
- El cliente del AndroidMarket recolecta toda la información necesaria para enviar la solicitud al servidor y este genere una respuesta.
- El servidor evalua la solicitud usando toda la información disponible, verifica la identidad del usuario contra los registros de la aplicación en el AndroidMarket y retorna una respuesta de licenciamiento al cliente y este a su vez a la aplicación.
Seguridad con criptografia de clave publica
Para asegurar la integridad de cada consulta, el servidor firma cada respuesta usando un par de claves RSA que es compartida exclusivamente entre el servidor y el publicador de la aplicación.El servicio de licenciamiento genera un único par de claves para cada cuenta de publicador y expone esta clave publica en la pagina del perfil de la cuenta. El publicador copia la clave publica y la agrega en el codigo fuente de su aplicación, luego compila y publica el .apk como antes. El servidor retiene la clave privada internamente y la utiliza para firmar futuras respuestas de licenciamiento a las aplicaciones publicadas por esa cuenta. Cuando la aplicación recibe la respuesta firmada, utiliza la clave publica embebida para verificar los datos. El uso de criptografía de clave publica hace posible la deteccion de respuestas que han sido manipuladas o falsas. Requerimientos y limitaciones Antes que nada debemos tener claro los requisitos básicos para poder aplicar el servicio de liceciamiento en nuestra aplicación: - Tener una cuenta de publicador en el AndroidMarket.
- La aplicación puede usar el servicio solo si el cliente del AndroidMarket esta instalado en el terminal y esta corriendo Android 1.5 (API nivel 3) o más. Si se hacen pruebas en el emulador se debe utilizar una imagen Google API nivel 8 revision 2 o superior (ya que esta cuenta con los servicios necesarios del Android Market que requiere el sistema de licenciamiento para funcionar).
- Para poder realizar la verificacion de la licencia el servidor debe tener conectividad a la red, en caso contrario se puede utilizar los servicios de almacenamiento en cache.
- El agregado del servicio a la aplicación no afecta su funcionamiento si esta corriendo sobre un terminal que no posee el AndroidMarket.
- El licenciamiento se aplica solo a aplicaciones pagas en el AndroidMarket o libres que se consideran con licencia para todos los usuarios.
Preparando el ambiente de desarrollo para usar el LVL Para usar el licenciamiento en tu aplicación debes tener una cuenta en el AndroidMarket. Una vez registrado entras al perfil de tu cuenta y configuras el licenciamiento, puedes utilizar tu cuenta para: - Obtener la clave pública y luego agregarla en el código fuente de tu app.
- Depurar y probar la implementacion antes de publicar la app.
- Publicar la aplicación con el licenciamiento.
Para ejecutar el servicio de licenciamiento debes tener un dispositivo Android con la aplicación AndroidMarket o un emulador Android corriendo Google API nivel 8 o superior y: - Descargar la biblioteca de licenciamiento (LVL) que esta disponible como componente del SDK (correr el AVD Manager y buscar actualizaciones).
- Tomar el directorio library del LVL y crearlo como biblioteca de proyecto en Eclipse (creando un nuevo proyecto desde código fuente preexistente)
- Incluir la biblioteca LVL en tu aplicación (se agrega en las propiedades del proyecto, sección Android)
Uso de licenciamiento en tu aplicación Las interfaces claves del LVL son: Policy: su implementación determina si debe permitir el acceso a la aplicacion, esta validación se realiza en base a la respuesta recibida del servidor y la clave publica embebida. LicenseChekerCallback: su implementación controla el acceso a la aplicación de acuerdo al resultado obtenido por la clase Policy. Para hecharte una mano y no tener que implementar Policy, LVL te ofrece dos implementaciones que puedes utilizar segun tus necesidades: ServerManagedPolicy: es una politica flexible ya que primero consulta la respuesta de licenciamiento almacenada en el cache (SharedPreferences) para acceder a la aplicacion, una alternativa util en el caso de que el terminal se encuentre sin conectividad. StrictPolicy: es una politica restrictiva ya que no almacena en el cache las respuestas sino que permite el acceso a la aplicacion solo si el servidor retorna una respuesta de licenciamiento. Si tu forma de validar una licencia requiere de una mayor complejidad (por ej. conectar a un servidor propio) lo que se hace normalmente es implementar todos estos adicionales en una subclase de Policy propia. Como integrar el LVL en tu aplicación Se trata de 5 pasos (donde el paso 3 y el 5 son opcionales):
- Agregar el permiso de licenciamiento en tu AndroidManifest.xml
- Implementar una Policy — puedes elegir entre dos políticas ya implementadas en LVL o implementar una propia.
- Implementar un Obfuscator, si tu política guardará en cache datos de respuesta de licenciamiento.
- Verificar la licencia desde el Activity principal de tu aplicación
- Implementar un DeviceLimiter (opcional y no recomendado para la gran mayoría de apps)
Explicaremos brevemente los pasos 1, 2 y 4 que son los mas importantes:
1) Agregar el permiso de licenciamiento en tu AndroidManifest.xml Para solicitar el permiso de licenciamiento en tu aplicación declarar en el <manifest>: <uses-permission android:name="com.android.vending.CHECK_LICENSE">
2) Implementar una Policy La implementación de Policy determina si el usuario puede acceder a tu aplicación. La interfaz de Policy declara dos metodos allowAccess() y processServerResponse()los cuales son llamados por una instancia de LicenseChecker cuando procesa una respuesta del servidor. processServerResponse() te permite preprocesar los datos recibidos por el servidor para luego determinar los permisos de acceso. Una implementación típica es extraer los campos de la respuesta de licenciamiento y almacenarlos localmente utilizando SharedPreferences, para asegurar que estos datos sean accesibles en todo momento. allowAccess() determina si el usuario tiene accesso a la app en base a la respuesta del servidor o desde el cache. Para más detalles ver (en inglés)
4) Verificar la licencia desde el Activity principal de tu aplicación Para agregar la verificación de licencia y manejar la respuesta debes:
- Agregar los imports (+)
- Implementar LicenseCheckerCallback como un inner class privado (+)
- Crear un Handler para postearlo en el UI thread desde el LicenseCheckerCallback (+)
- Instanciar LicenseChecker y LicenseCheckerCallback (+)
- Llamar a checkAccess() para iniciar la verificación de licencia (+)
- Pegar tu clave pública para el licenciamiento (+)
- Llamar al método onDestroy() de tu LicenseChecker para cerrar las conecciones IPC (+)
Para más detalles ver (en inglés)
La verificación de licencia (License Check) consiste en dos acciones importantes: - Llamar al método que inicia la verificación de licencia - método checkAccess() del objeto LicenseChecker construido en tu app.
- Implementar la interfaz LicenseCheckerCallback, la cual declara dos métodos allow() y dontAllow(), estos son invocados en base al resultado de la verificación de licencia (en la implementación del Policy). Estos métodos solo proveen el comportamiento necesario para permitir o negar accessos.
En el diagrama se ilustra como se realiza la verificación de licencia y se procesan las respuesta recibidas del servidor de licenciamiento: - En la Actividad principal de la aplicación instanciar los objetos LicenseCheckerCallback y LicenseChecker. En el constructor del LicenseChecker pasar como parámetros, el Context, la implementación del Policy y la clave pública de la cuenta.
- Al ejecutarse el código llama al método checkAccess() en el objeto LicenseChecker, cuya implementacion llama al Policy para determinar si hay una respuesta de licenciamiento valida cacheada localmente en SharedPreferences
- si es asi llama al metodo allow()
- sino el LicenseChecker inicia una solicitud de verificación de licencia que es enviada al servidor de licenciamiento.
- Cuando el LicenseChecker recibe la respuesta del servidor crea un LicenseValidator que verifica los datos de licenciamiento firmados y extrae los campos de la respuesta y se los pasa al Policy para su evaluación:
- Si la licencia es válida, la Policy cachea la respuesta en el SharedPreferences y notifica al validador (LicenseValidator) el cual llama al metodo allow() en el objeto LicenceCheckerCallback.
- Si la licencia no es válida, el Policy notifica al validador el cual llama al método dontAllow() en el LicenseCheckerCallback
- En caso de error del servidor, por ej. cuando la red no esta disponible para enviar la solicitud, el LicenseChecker pasa una respuesta RETRY al metodo processServerResponse() de la Policy.
- En caso de error de la aplicación, por ej. cuando esta intenta realizar una verificación de licencia con un nombre de paquete inválido, el LicenseChecker pasa una respuesta de error al método applicationError() del LicenseCheckerCallback.
|
publicado a la(s) 28/05/2010 19:17 por German Viscuso
[
actualizado el 28/05/2010 19:54
]
Hace un año la gente de Google publicó en el Android Market una aplicación muy interesante " My Tracks" que permite hacer un seguimiento geográfico de actividades como caminatas, paseos en bicicleta, carreras, etc. utilizando tu terminal Android.
Pues la buena noticia es que ahora han liberado el código fuente!
Esto no solo significa que podemos husmear el código y utilizarlo en nuestra propia app sino que también podemos colaborar aportando mejoras a My Tracks y/o reportando fallos. También se están buscando traductores así que si te animas puedes ayudar con la traducción!
Enhorabuena Google! |
publicado a la(s) 24/05/2010 04:00 por Damasia Maneiro
[
actualizado el 24/05/2010 06:14
]
Hay algunos cambios interesantes que pueden ampliar el panorama del desarrollador. Para descargar el nuevo SDK consulta los pasos aquí.
Instalación de aplicaciones en almacenamiento externo
Ahora tenemos la alternativa de poder instalar nuestra aplicación en un almacenamiento externo (ej. tarjeta SD), en vez de la memoria interna como se venía haciendo por defecto.
Esto lo hacemos a través de un nuevo atributo llamado android:installLocation en el manifest. Este atributo soporta tres valores: "internalOnly", "preferExternal" y "auto".
Si especificamos una instalación externa, el sistema instala el .apk en una partición encriptada privada en el medio externo. Una vez instalado podemos cambiar la ubicación y moverlo a la memoria interna del dispositivo y viceversa a través de la opción Manage Applications en la configuración del usuario.
Esta característica no es conveniente para todas las aplicaciones particularmente porque los medios externos pueden ser removibles, desmontados /remontados lo que puede interrumpir al usuario y a la configuración del sistema (ej: una app que sirve para recuperar un móvil robado almacenada en una tarjeta SD).
Resguardo de los datos
Ahora se provee un servicio de resguardo generalizado que las aplicaciones pueden usar para salvar y recuperar los datos del usuario. De esta manera los usuarios pueden mantener sus datos cuando cambian de dispositivo o reinstalan la aplicación. El Backup Manager se encarga de transportar los datos de la aplicación desde y hasta el área de almacenamiento del resguardo en la nube. El Backup Manager puede almacenar cualquier tipo de dato desde datos arbitrarios hasta archivos y administrar operaciones de resguardo y restauración de una manera atómica. Para mas información ver Data Backup.
Gráficos
Nuevas APIs OpenGL ES 2.0 en android.opengl.GLES20
Nuevas Clases ETC1, ETC1Util y ETC1Util.ETC1Texture y métodos utilitarios para usar ETC1 en la compresión de textura.
Nueva clase ImageFormat
Nueva API para formato de imagen YUV que permite la compresión de YUV a JPEG y manipulación de datos.
Framework de Medios
Nuevas APIs para administrar el foco del audio, ruteo del audio a SCO y auto scan de archivos a la base de datos de medios. También permiten a las aplicaciones detectar la completitud de carga de sonido.
Reconocimiento de voz
Nuevas APIs de reconocimiento de voz para interactuar con la aplicación a través de interfaces de respuesta e intents para especificar detalles de idioma y tiempo.
Camara y grabadora
Ahora la nueva API duplica su velocidad a 20FPS. También con orientación horizontal, controles de zoom, acceso a los datos de exposición y utilidades de thumbnail. Y nuevas características de video permite lucir las capacidades de hardware del dispositivo.
Administrador de Politicas del dispositivo
Ahora el desarrollador como “administrador ” puede escribir aplicaciones que controlen la seguridad del dispositivo (ej: longitud mínima de contraseña). Los usuarios pueden elegir los administradores para sus dispositivos.
Framework de Interfaz de usuario (UI)
Nuevos controles “car mode” y “night mode” que permiten ajustar la UI para estas situaciones. También provee una API para detectar gestos a través de una definición mejorada de eventos multitacto.
Permisos
Nuevos permisos para asegurar que el sistema solo interactue con el administrador del dispositivo, para matar todos los procesos que corren de fondo, para interactuar con servicios de Wallpaper y para cambiar la hora del sistema.
[via: developer.android.com]
|
publicado a la(s) 23/05/2010 06:50 por German Viscuso
[
actualizado el 23/05/2010 07:10
]
Google ahora ofrece una API de desarrollo para Latitude (todavía en el Labs) que puede ser utilizada en cualquier aplicación y abre un abanico de interesantes posibilidades. La idea es que el usuario del terminal tenga un completo control sobre como las aplicaciones de terceros acceden la información de ubicación geográfica provista por Latitude. Algunos de los usos posibles son:
- Sistemas de calefacción que se encienden o apagan automáticamente de acuerdo a nuestra proximidad al hogar.
- Recepción de alertas de atascamientos de tráfico de acuerdo a nuestra posición actual y a nuestras rutas usuales
- Alerta de uso fraudulento de tarjetas de crédito cuando una compra se realiza en un punto lejano a nuestra ubicación actual.
- Geolocalización de fotografías y servicios relacionados de acuerdo a la ubicación del usuario.
- "Push" de información turística, propagandas, promociones, de acuerdo a la ubicación
Esta API sigue un estilo de llamadas REST y los datos se manejan en formato JSON. Para daros una idea así se obtiene la ubicación actual de un usuario con la mejor precisión (previa autenticación claro, todas las operaciones lo requieren):
GET https://www.googleapis.com/latitude/v1/currentLocation?granularity=best
El sitio de la API se encuentra disponible en code.google.com/apis/latitude y tambien hay un grupo de discusiones (en inglés) Latitude
API Google Group. También aquí pueden ver algunas aplicaciones que ya están utilizando el servicio. [via phandroid.com] |
publicado a la(s) 23/05/2010 06:27 por German Viscuso
[
actualizado el 23/05/2010 18:54
]
Estábamos esperando con ansias las noticias de Android desde el Google I/O. Nos invitaron a observar la presentación desde las oficinas de Google en Madrid donde nos han atendido muy bien y las novedades no decepcionaron (gracias Google por los helados, bocadillos, regalos, etc. =) La estrategia de Google se apoya fuertemente en Android (por ej. Google TV esta basado en él) y en las nuevas características de la versión 2.2 apodada "Froyo" (por "frozen yogurth": yogur congelado). Lejos de estar congelado, Android muestra unas mejoras bastante interesantes en las áreas de velocidad, APIs y servicios, el navegador y el Market. Repasemos las más importantes: -Compilador JIT (just in time) en la máquina virtual Dalvik: Dalvik se moderniza poniéndose al nivel de las máquinas virtuales modernas ofreciendo compilación dinámica de bytecode (con caching) lo que acelera significativamente la ejecución de los programas (entre 2 a 5 veces más rápido en este caso particular). Hemos visto una comparación en un Nexus One y la diferencia de velocidad es claramente visible. -Mensajería "Cloud to Device" (de la nube al terminal): de sumo interés para desarrolladores, se trata de un sistema de mensajería más avanzado que "push notifications" como se ha visto en el iPhone. Permite el procesamiento de alertas, envíos al terminal y sincronización bidireccional al servicio de las aplicaciones. En esta infraestructura un servidor de aplicaciones puede enviar un mensaje autenticado a los servidores de Google que será redireccionado al dispositivo (Google se encarga de los detalles de comunicación como temporización, reintentos, etc). Así un desarrollador podria, por ejemplo, enviar un punto geográfico de Google Maps desde la web a un dispositivo Android y que este automáticamente se encargue de abrir la aplicación Maps mostrando el punto. -Resguardo de Aplicaciones: también de interés para desarrolladores ya que se trata de una API dedicada que permite guardar y restaurar a manera de backup todas nuestras aplicaciones cuando nos movemos a un nuevo dispositivo. -Aplicaciones en tarjeta SD: permite especificar de forma nativa si la aplicación se aloja en el terminal o en la tarjeta SD (por el momento no es compatible con APPs2SD) -Creación de Hotspot Wi-Fi: permite al terminal crear y exponer una red Wi-Fi para que podamos conectar nuestros ordenadores. Viene incluido en las opciones de configuración, no es necesario instalar ningún paquete adicional. -Mejoras en el Navegador: el browser ahora posee un motor Javascript que es de 2 a 3 veces más rápido que el de Android 2.1 denominado V8. Pudimos observar las diferencias en un terminal y cuando una animación o proceso depende de Javascript se ha notado bastante. -Mejoras en Android Market: se agrega (finalmente) la posibilidad de subscribirse a actualizaciones automáticas y posibilidad de actualizar todo lo que no esté actualizado (y tenga los mismos permisos, de otra forma tendremos que hacerlo una por una). Y de mayor interés para nosotros es que en Froyo se pueden enviar reportes de fallos de las aplicaciones y todo será accesible para el desarrollador desde el panel de control del market. -Soporte para Flash: incluye Flash player 10.1 Quizá, si quisieramos agregar una cereza al yogur =), le pediríamos a Google la incorporación de una API abierta para el manejo de calendarios (que increiblemente no está disponible). Esta actualización de Android ya está siendo enviada a terminales Nexus One e incluso pueden instalarla manualmente si no quieren esperar. Sin duda un paquete interesante. A estar atentos al próximo post donde daremos más detalles de interés sobre el nuevo SDK 2.2 y cambios en la API (orientado a desarrolladores). [via: developer.android.com] |
|
