Android Emulator为应用开发者提供了一个调试的模拟环境，对于应用开发前期有着非常重要的作用。在网路上一直流行这么一句话：Android开发者因为购买Android开发机而破产。在日益碎片化的Android世界，Emulator或许是囊中羞涩的开发者手中的救命稻草。本篇博客将重点讲述如何使Emulator连接到Internet，特别是需要代理的时候。

在Android开发者网站http://developer.android.com/tools/devices/emulator.html#emulatornetworking和http://developer.android.com/tools/devices/emulator.html#connecting已经讲述了如何进行Emulator的网络配置和设备间的相互连接。开发者在正常情况下，可以通过emulator的命令行配置运行，对于喜欢命令行的开发者，它是非常棒的选择，但是如果开发者更加喜欢图形界面呢？特别是习惯使用Elipse来进行Emulator的启用和程序的运行呢？

不要着急，不妨跟着笔者一起在Eclipse中搭建Emulator的带来吧！

1）开打Eclipse

图1

2）选择Window菜单下的Preferences子菜单

图2

3）点击Android下的Launch项，在Default emulator options中写入你的HTTP代理地址。

图3

格式如下：

-http-proxy http://<username>:<password>@<machineName>:<port>

点击OK按钮，在试一下你的应用程序，搞定了吗？哈哈，恭喜恭喜！

参考：

跟燕青一起学Android应用开发（一）：安装Android开发环境

跟燕青一起学Android应用开发（二）：配置Android SDK Manager

跟燕青一起学Android应用开发（三）：安装Android x86 Emulator System Image

跟燕青一起学Android应用开发（四）：安装Intel HAXM

Las aplicaciones de Android* pueden incorporar código nativo con el uso del conjunto de herramientas del Kit de Desarrollo Nativo (Native Development Kit, NDK). Permite a los desarrolladores volver a usar código heredado, codificar a hardware de bajo nivel o diferenciar sus aplicaciones mediante el aprovechamiento de prestaciones que en otro caso no serían óptimas o posibles.

Este artículo es una introducción básica a la creación de aplicaciones basadas en el NDK para la arquitectura Intel, desde el principio hasta el fin, y también, en el caso de usos simples, de cómo portar aplicaciones basadas en el NDK ya existentes a dispositivos basados en la arquitectura Intel. Para mostrar el proceso, seguiremos el desarrollo de una aplicación paso a paso.

1. Introducción al Kit de Desarrollo Nativo

Sólo se debe considerar compilar aplicaciones nativas cuando el rendimiento sea cuestión de inquietud. El inconveniente de desarrollar aplicaciones nativas es que requiere mucho esfuerzo que la aplicación sea compatible con múltiples arquitecturas y diferentes generaciones de la misma arquitectura.

Damos por supuesto que se ha configurado correctamente el entorno para desarrollo de aplicaciones Java y que se tiene familiaridad con la creación de aplicaciones Java simples. Antes de continuar, es necesario instalar el NDK desde http://developer.android.com.

2. Compilación de una aplicación “Hello, world!” con el NDK

El objetivo de este capítulo es compilar la primera aplicación de ejemplo desde el NDK para un destino x86 tanto con el compilador GNU* como con el Compilador Intel® C++. Se enseñará a retocar el sistema de compilación para cambiar los indicadores de optimización de la aplicación, el módulo, un archivo específico, etc. Sólo los host Linux admiten Compilador Intel® C++, así que restringiremos nuestra atención a Linux.

2.1 Preparación y validación del entornoK/h3>

Para comenzar a experimentar con ejemplos de la distribución del NDK, es necesario familiarizarse con la utilidad ndk-build y con la sintaxis de dos archivos make: Application.mk y Android.mk.

La utilidad ndk-build extrae los detalles del sistema de compilación; Application.mk y Android.mk contienen definiciones de variables para configurar el sistema de compilación. Por ejemplo, estos archivos make especifican la lista de archivos fuente a partir de los cuales compilar la aplicación, los componentes externos de los cuales depende la aplicación, etc.

Hay que asegurarse de que las utilidades ndk-build y android del NDK y el SDK correspondientementes estén en el PATH propio:

PATH=<NDK>:<SDK>/tools:$PATH

La manera más fácil de validar el entorno es volver a compilar el ejemplo hello-jni del NDK. Copie hello-jni a algún lugar y ejecute:

ndk-build–B en el nuevo directorio.

Compruebe que tenga al menos un destino que admita ABI x86[1]. Para ello, ejecute:

android list targets

Si falta, use el comando:

android sdk

para instalarlo.

2.2 Compilación con el compilador GNU*

En la sección anterior, validamos la configuración y compilamos libhello-jni.so en libs/armeabi. La nueva biblioteca sólo se puede ejecutar en ARM* porque este es el destino predeterminado para las aplicaciones nativas. Como nuestro interés principal es desarrollar para x86, tenemos que configurar esta opción como corresponde.

Cree el archivo hello-jni/jni/Application.mk y agregue la siguiente definición en el archivo:

APP_ABI := x86

Esto indica que se debe usar un compilador cruzado y otras herramientas binarias con destino x86 para crear libhello-jni.so. Ahora ya está todo listo para compilar libhello-jni.so para x86. Esta vez habilitaremos la salida de ndk-build detallada, con la opción V=1 desactivada, para ver los comandos y sus parámetros cuando son invocados por make. Ejecute ndk-build –B V=1. La opción –B hace que se recompile por completo la biblioteca libhello-jni.so. Una vez terminada la creación de una biblioteca nativa, hay que finalizar la creación del APK para prueba.

El nombre del destino x86 en la versión r8b del NDK es android-15. Siempre puede usar el comando android list targets para revisar la lista de destinos disponibles.

En este punto, HelloJni aparecerá en la lista de aplicaciones instaladas en el dispositivo o el emulador, como se muestra en la Figura 1.

Figura 1. HelloJni aparece en la lista de aplicaciones instaladas en el dispositivo o el emulador.

Hay varias variables importantes de Application.mk que son relevantes para la optimización del rendimiento.

La primera es APP_OPTIM. Se le debe establecer el valor release para obtener el binario optimizado. En forma predeterminada, la aplicación está compilada para depurar. Para comprobar qué opciones de optimización están habilitadas de manera predeterminada, actualice APP_OPTIM y ejecute ndk-build –B V=1.

Si no lo satisfacen las opciones de optimización predeterminadas, hay variables especiales para agregar opciones durante la compilación. Son APP_CFLAGS y APP_CPPFLAGS. Las opciones especificadas en la variable APP_CFLAGS se agregan durante la compilación tanto de archivos de C como de C++, mientras que la variable APP_CPPFLAGS sólo se aplica a archivos de C++.

Para aumentar el nivel de optimización a –O3, agregue APP_CFLAGS:=-O3 a Application.mk.

2.3 Cómo compilar con el Compilador Intel® C++

El compilador de Intel no forma parte del NDK y se lo debe integrar a este antes de que se pueda usar con la utilidad ndk-build. En esencia, hay que crear una nueva cadena de herramientas.

• Cree el directorio para la nueva cadena de herramientas:
  mkdir –p /toolchains/icc-12.1/prebuilt/.
• El nombre icc-12.1 se escogió arbitrariamente. Se usa como valor del parámetro
  NDK_TOOLCHAIN de ndk-build.
• Copie el directorio de nivel superior <ICC_ROOT> que contiene el compilador Intel instalado al directorio <NDK>/toolchains/icc-12.1/prebuilt/intel. Para ahorrar espacio, puede crear un vínculo simbólico de <ICC_ROOT> a <NDK>/toolchains/icc/prebuilt/intel.
• Copie config.mk y setup.mk del directorio GCC:
  cp <NDK>/toolchains/x86-4.6/{setup.mk,config.mk} <NDK>/toolchains/icc-12.1
• Cambie la variable TOOLCHAIN_NAME del nuevo archivo setup.mk a cualquier valor conveniente, por ejemplo, icc.
• Modifique la variable TOOLCHAIN_PREFIX de setup.mk para que apunte a la nueva cadena de herramientas:
  TOOLCHAIN_PREFIX := $(TOOLCHAIN_ROOT)/prebuilt/intel/bin/
• Observe la “/” al final del valor de TOOLCHAIN_PREFIX.
• Especifique la ruta al compilador x86 GCC en setup.mk
  export ANDROID_GNU_X86_TOOLCHAIN=$(TOOLCHAIN_ROOT)/../x86-4.6/prebuilt/linux-x86/
• Especifique la ruta al root del sistema de destino. El root del sistema es necesario para localizar las bibliotecas del sistema y los archivos de encabezado:
  export ANDROID_SYSROOT=$(call host-path,$(SYSROOT))^[1]
• Especifique la versión del GCC que usa el compilador de Intel: TOOLCHAIN_VERSION:= 4.6
• Especifique las rutas a los componentes del compilador de Intel en <NDK>/toolchains/icc /setup.mk
  TARGET_CC:=$(TOOLCHAIN_PREFIX)icc
  TARGET_CXX:=$(TOOLCHAIN_PREFIX)icpc
• Cree el directorio para la nueva cadena de herramientas: mkdir –p <NDK>/toolchains/icc-12.1/prebuilt/.
• El nombre icc-12.1 se escogió arbitrariamente. Se usa como valor del parámetro NDK_TOOLCHAIN de ndk-build.
• Copie el directorio de nivel superior <ICC_ROOT> que contiene el compilador Intel instalado al directorio <NDK>/toolchains/icc-12.1/prebuilt/intel. Para ahorrar espacio, puede crear un vínculo simbólico de <ICC_ROOT> a <NDK>/toolchains/icc/prebuilt/intel.
• Copie config.mk y setup.mk del directorio GCC:
  cp /toolchains/x86-4.6/{setup.mk,config.mk} <NDK>/toolchains/icc-12.1
• Cambie la variable TOOLCHAIN_NAME del nuevo archivo setup.mk a cualquier valor conveniente, por ejemplo, icc.
• Modifique la variable TOOLCHAIN_PREFIX de setup.mk para que apunte a la nueva cadena de herramientas:
  TOOLCHAIN_PREFIX := $(TOOLCHAIN_ROOT)/prebuilt/intel/bin/
• Observe la “/” al final del valor de TOOLCHAIN_PREFIX.
• Especifique la ruta al compilador x86 GCC en setup.mk
  export ANDROID_GNU_X86_TOOLCHAIN=$(TOOLCHAIN_ROOT)/../x86-4.6/prebuilt/linux-x86/
• Especifique la ruta al root del sistema de destino. El root del sistema es necesario para localizar las bibliotecas del sistema y los archivos de encabezado:
  export ANDROID_SYSROOT=$(call host-path,$(SYSROOT))^[1]
• Especifique la versión del GCC que usa el compilador de Intel:
  TOOLCHAIN_VERSION:= 4.6
• Especifique las rutas a los componentes del compilador de Intel en <NDK>/toolchains/icc /setup.mk
  TARGET_CC:=$(TOOLCHAIN_PREFIX)icc
  TARGET_CXX:=$(TOOLCHAIN_PREFIX)icpc
  TARGET_LD:=$(TOOLCHAIN_PREFIX)xild
  TARGET_AR:=$(TOOLCHAIN_PREFIX)xiar
  TARGET_STRIP:=$(ANDROID_GNU_X86_TOOLCHAIN)/i686-android-linux/bin/strip
  TARGET_LIBGCC:=$(shell env ANDROID_GNU_X86_TOOLCHAIN=$(ANDROID_GNU_X86_TOOLCHAIN) $(TARGET_CC) -print-libgcc-file-name)

Ejecute ndk-build -B V=1 NDK_TOOLCHAIN=icc-12.1. Observe que la biblioteca compartida es compilada por el compilador de Intel. Sin embargo, esta vez la aplicación no funcionará, porque depende de bibliotecas compartidas suplementarias de la distribución del compilador de Intel. La solución más sencilla es activar la vinculación estática de bibliotecas de Intel. Agregue a <WORK_DIR>/hello-jni/jni/Android.mk la siguiente línea:

LOCAL_LDFLAGS := -static-intel

Ahora vuelva a compilar e instalar la aplicación. Debería funcionar según lo esperado en el emulador o el dispositivo.

Las opciones no admitidas -funwind-tables y -funswitch-loops generan varias advertencias. Estas advertencias se pueden ignorar. Hablaremos de la compatibilidad de las opciones en una sección posterior.

2.4. Empaquetamiento de bibliotecas compartidas del Compilador Intel® C++

Si la aplicación es lo suficientemente grande, entonces no se justifica la vinculación estática. En este caso, es necesario empaquetar las bibliotecas junto con la aplicación. La compilación de la aplicación con el compilador de Intel depende de las siguientes bibliotecas^[2]:

• libintlc.so, que contiene rutinas de memoria y de cadenas optimizadas;
• libimf.so y libsvml.so, que contienen funciones matemáticas optimizadas.

Para empaquetar las bibliotecas del compilador de Intel, agregue a <WORK_DIR>/hello-jni/jni/Android.mk las siguientes líneas:

include $(CLEAR_VARS)
LOCAL_MODULE    := libintlc
LOCAL_SRC_FILES := libintlc.so
include $(PREBUILT_SHARED_LIBRARY)

También necesita una configuración similar para libimf.so y libsvml.so. Luego copie libintlc.so, libimf.so y libsvml.so libraries a <WORK_DIR>/hello-jni/jni. Por último, vuelva a compilar e instalar el paquete.

3. Opciones del Compilador Intel® C++

El compilador de Intel es compatible con la mayoría de las opciones del compilador GNU, pero no con todas. Cuando el compilador de Intel encuentra una opción desconocida o no admitida, emite una advertencia, como en este caso con -funswitch-loops. Siempre revise las advertencias.

3.1. Opciones de compatibilidad

Existen varias incompatibilidades relacionadas con las advertencias. Hay mucho debate acerca de qué construcciones son peligrosas y cuáles no. En general, el compilador de Intel produce más advertencias que el compilador GNU. También observamos que el compilador GNU cambió la configuración de advertencias entre las versiones 4.4.3 y 4.6. El compilador de Intel intenta admitir el formato de opciones de GNU para las advertencias, pero la compatibilidad puede dejar de ser completa a medida que el compilador GNU evoluciona.

El compilador GNU usa diversos nombres mnemónicos con –W<diag name> y –Werror=<diag name>. La primera opción habilita una advertencia adicional y la segunda hace que este compilador la trate como un error. En ese caso, el compilador no genera un archivo de salida y sólo produce datos de diagnóstico. Hay una opción complementaria, –Wno-<diag name>, que suprime la advertencia correspondiente. La opción -fdiagnostics-show-option del compilador GNU ayuda a deshabilitar opciones: por cada advertencia allí emitida se agrega una sugerencia que explica cómo controlar la advertencia.

El compilador de Intel no reconoce algunas de estas opciones; se las puede ignorar o, mejor aún, corregir. Con la opción –Werror, algunas veces todas las advertencias se convierten en errores. En este caso, es posible que la compilación con el compilador Intel falle. Hay dos maneras de evitar este problema: corregir la advertencia en el código fuente o deshabilitarla con –diag-disable <id>, donde <id> es un número único que se asigna a la advertencia. Este número de identificación único <id> es parte del texto de la advertencia. Si se cree que la construcción de lenguaje informada es peligrosa, el método recomendado es corregir el código fuente.

Creamos la imagen entera de Android OS con el compilador de Intel y encontramos varias opciones no admitidas y que no se relacionan con advertencias. A la mayoría se las puede ignorar, como se explica en la Tabla 1. Para varias opciones usamos las opciones equivalentes del compilador de Intel.

Tabla 1: Comparación de opciones de compilador

Se pueden encontrar más detalles sobre la compatibilidad de los compiladores de Intel y GNU en las notas de producto de la página web http://software.intel.com/en-us/articles/intel-c-compiler-for-linux-compatibility-with-the-gnu-compilers/.

3.2. Opciones de rendimiento

Cuando se trabaja en el rendimiento, siempre hay que hacer concesiones. Los procesadores x86 difieren en la microarquitectura y, para obtener un rendimiento óptimo, es necesario optimizar en forma específica para el procesador. Antes de empezar a hacer ajustes al código, se debe decidir si la aplicación va a ejecutarse en procesadores Intel o AMD, si está dirigida a smartphones o tabletas, y así sucesivamente.

La mayor parte de la optimización en el compilador de Intel está ajustada para procesadores Intel. Damos por supuesto que el procesador de destino es el Intel® Atom™, porque este es el procesador de Intel para dispositivos móviles. En este caso, a fin de obtener el mejor rendimiento, es necesario agregar opciones –xSSSE3_ATOM durante la compilación. Si espera que el código se vaya a ejecutar en dispositivos basados en AMD, use en cambio –march=atom. En este caso, la aplicación se ejecutará en cualquier procesador que admita instrucciones de Intel Atom, pero es posible que se desactiven algunas optimizaciones agresivas.

Para habilitar –xSSSE3_ATOM para todos los archivos de la aplicación “Hello, world!”, agregue a hello-jni/jni/Application.mk la siguiente línea:

APP_CFLAGS := -xSSSE3_ATOM

Después de haber elegido el procesador objetivo, queda a su criterio modificar el nivel de optimización. En forma predeterminada, el sistema de compilación deshabilita por completo las optimizaciones con –O0 en modo de depuración y establece el nivel de optimización predeterminado –O2 en el modo de compilación. Puede intentar hacer optimizaciones agresivas con –O3, pero esto podría aumentar el tamaño del código. Por otra parte, si el tamaño del código es un parámetro de importancia, intente con –Os.

Se puede cambiar el nivel de optimización para toda la aplicación; para ello, se debe agregar –O0 -- –O3 a APP_CFLAGS:

APP_CFLAGS := -xSSSE3_ATOM –O3

Las restantes opciones de optimización se verán en secciones aparte: “Vectorización” y “Optimización interprocedimental”.

4. Vectorización

El compilador de Intel admite la generación avanzada de código, incluida la autovectorización. Para el Compilador Intel C/C++, la vectorización es de expansión de bucles (loop unrolling) con generación de instrucciones SIMD que operan en varios elementos a la vez. El desarrollador puede expandir bucles en forma manual e insertar llamadas a funciones apropiadas correspondientes a las instrucciones SIMD. Este enfoque no es escalable hacia delante e implica un alto costo en el desarrollo. Habrá que volver a hacer el trabajo cuando se lance el nuevo microprocesador que admita instrucciones avanzadas. Por ejemplo, los primeros microprocesadores Intel Atom no se beneficiaban de que la vectorización de bucles procesara el punto flotante de precisión doble mientras la instrucción SIMD procesaba con precisión simple de manera eficaz.

La vectorización simplifica las tareas de programación, ya que libera al programador de tener que aprender conjuntos de instrucciones para un microprocesador en particular, porque el compilador de Intel siempre es compatible con las generaciones más recientes de microprocesadores Intel.

Las opciones -vec activan la vectorización en el nivel de optimización predeterminado para microprocesadores que admiten la arquitectura IA32, tanto de Intel como otros. Para mejorar la calidad de la vectorización, es necesario especificar el microprocesador de destino en el cual se ejecutará el código. Si se busca lograr un rendimiento óptimo en smartphones Android basados en la arquitectura Intel, se recomienda usar la opción –xSSSE3_ATOM. La vectorización se habilita en el Compilador Intel® C++ a niveles de optimización de -O2 y superiores.

Muchos bucles se vectorizan automáticamente y el compilador de tiempo genera código óptimo por sí solo, pero a veces necesita que el programador lo guíe. La mayor dificultad en relación con la eficiencia de la vectorización es hacer que el compilador haga un cálculo lo más preciso posible de las dependencias de datos.

Para aprovechar al máximo la vectorización en el compilador de Intel, son muy útiles las siguientes técnicas:

• Generar un informe de vectorización y entenderlo
• Mejorar el rendimiento mediante la desambiguación de punteros
• Mejorar el rendimiento mediante el uso de optimización interprocedimental
• Pragmas del compilador

4.1. Informe de vectorización

Comenzaremos con la implementación del copiado de memoria. El bucle tiene la estructura que se usa habitualmente en las fuentes Android:

// It is assumed that the memory pointed to by dst
// does not intersect with the memory pointed to by src
void copy_int(int *dst, int *src, int num) 
{
    int left = num;
    if(left<=0) return;
    do { 
        left--; 
        *dst++ = *src++; 
    } while (left > 0); 
}

Para los experimentos con vectorización, no crearemos un objeto aparte, sino que volveremos a usar el proyecto hello-jni. Agregue la función al nuevo archivo jni/copy_cpp.cpp. Agregue este archivo a la lista de archivos fuente en jni/Android.mk:

LOCAL_SRC_FILES := hello-jni.c copy_int.cpp

Para habilitar el informe de vectorización detallado, agregue la opción –vec-report3 a la variable APP_CFLAGS en jni/Application.mk:

APP_CFLAGS := -O3 -xSSSE3_ATOM -vec-report3

Si vuelve a compilar libhello-jni.so, observará que se generaron varios comentarios:

jni/copy_int.cpp(6): (col. 5) remark: loop was not vectorized: existence of vector dependence.

jni/copy_int.cpp(9): (col. 10) remark: vector dependence: assumed ANTI dependence between src line 9 and dst line 9.

jni/copy_int.cpp(9): (col. 10) remark: vector dependence: assumed FLOW dependence between dst line 9 and src line 9.

...

Lamentablemente, la autovectorización ha fallado porque había demasiado poca información disponible para el compilador. Si la vectorización fuese exitosa, entonces la asignación

*dst++ = *src++;

sería reemplazada con

*dst = *src;

*(dst+1) = *(src+1);

*(dst+2) = *(src+2);

*(dst+3) = *(src+3);

dst += 4; src += 4;

y las instrucciones de SIMD realizarían las primeras cuatro asignaciones en paralelo. Pero la ejecución paralela de asignaciones no es válida si a la memoria a la cual se accede desde los términos de la izquierda también se accede desde los términos de la derecha de la asignación. Consideremos, por ejemplo, el caso en que dst+1 es igual a src+2; en este caso, el valor final en la dirección dst+2 sería incorrecto.

Los comentarios indican qué tipos de dependencias supone el compilador de manera conservadora para prevenir la vectorización:

• La dependencia de flujo (FLOW) es una dependencia entre un almacenamiento anterior y una carga posterior en la misma ubicación de la memoria.
• La dependencia ANTI es, por el contrario, una dependencia entre una carga anterior y un almacenamiento posterior en la misma ubicación de la memoria.
• La dependencia de salida (OUTPUT) es el tercer tipo de dependencia entre dos almacenamientos en la misma ubicación de la memoria.

Del comentario sabemos que el autor requería que la memoria a la que apuntaban dst y src no se superpusiera. Para comunicar información al compilador, alcanza con agregar calificadores restrict a los argumentos dst y src:

void copy_int(int * __restrict__ dst, int * __restrict__ src, int num)

El calificador restrict se agregó al C estándar publicado en 1999. Para habilitar la compatibilidad con C99, es necesario agregar –std=c99 a las opciones. Una alternativa es usar la opción –restrict para habilitarla para C++ y otros dialectos de C. En el código de arriba insertamos la palabra clave __restrict__ que siempre se reconoce como sinónimo de la palabra clave restrict.

Si vuelve a compilar la biblioteca, notará que los bucles estarán vectorizados:

jni/copy_int.cpp(6): (col. 5) remark: LOOP WAS VECTORIZED.

En nuestro ejemplo, la vectorización falló debido a que el compilador hizo un análisis conservador. Hay otros casos en los cuales el bucle no se vectoriza:

• El conjunto de instrucciones no permite vectorizar con eficiencia; los siguientes comentarios indican este tipo de problemas:
  • “Non-unit stride used” (se usó un paso no unitario)
  • “Mixed Data Types” (tipos de datos diferentes)
  • “Operator unsuited for vectorization” (operador no adecuado para la vectorización)
  • “Contains unvectorizable statement at line XX” (contiene una instrucción no vectorizable en la línea XX)
  • “Condition may protect exception” (la condición puede proteger la excepción)
• La heurística del compilador previene la vectorización; en realidad es posible, pero puede ser causa de lentitud; el diagnóstico contendrá:
  • "Vectorization possible but seems inefficient" (la vectorización es posible, pero parece ineficiente)
  • “Low trip count” (conteo bajo de ciclos)
  • “Not Inner Loop” (bucle no interno)
• Fallas del vectorizador:
  • “Condition too Complex” (condición demasiado compleja)
  • “Subscript too complex” (subscript demasiado complejo)
  • “Unsupported Loop Structure” (estructura de bucle no admitida)

–vec-reportN controla la cantidad de información que produce el vectorizador. Encontrará más detalles en la documentación del compilador.

4.2. Pragmas

Como vimos, el calificador de puntero restrict se puede usar para evitar hacer suposiciones conservadoras sobre la dependencia de datos. Pero a veces podría ser complicado insertar palabras clave restrict. Si se accede a muchas matrices en el bucle, podría también ser muy laborioso anotar todos los punteros. Para simplificar la vectorización en estos casos, hay un pragma específico de Intel, “simd”. Se usa para vectorizar bucles internos cuando se supone que no hay dependencias entre las iteraciones.

El pragma simd sólo se aplica a bucles “for” que operan en tipos de entero nativo y de punto flotante^[4]:

• El bucle “for” debe ser contable y se debe conocer la cantidad de iteraciones antes de que se inicie el bucle.
• El bucle debe ser interior.
• Ninguna referencia a la memoria en el bucle debe producir error (es importante para referencias indirectas enmascaradas).

Para vectorizar nuestro bucle con un pragma, necesitamos reescribirlo en la forma “for”:

void copy_int(int *dst, int *src, int num)
{
    #pragma simd
    for (int i = 0; i < num; i++) {
        *dst++ = *src++;
    }
}

Vuelva a compilar el ejemplo y observe que el bucle se vectorizó

La reestructuración de bucle simple para “pragma simd” y las inserciones de “#pragma simd” en las fuentes de Android OS nos permitieron mejorar en un 40 % el rendimiento indicado por el banco de pruebas Softweg, sin modificación del banco de pruebas.

4.3. Optimizaciones interprocedimentales

En las secciones anteriores, describimos estrategias para cuando uno comprende bien el código antes de comenzar a ocuparse del rendimiento. Si uno no está familiarizado con el código, entonces para ayudar al compilador a analizar el código, puede extender el alcance del análisis. En el ejemplo del copiado, el compilador debe hacer suposiciones conservadoras porque no sabe nada acerca de los parámetros de la rutina copy_int. Si los sitios de llamadas están disponibles para el análisis, entonces el compilador puede intentar probar que los parámetros son seguros para la vectorización.

Para ampliar el alcance del análisis, es necesario habilitar las optimizaciones interprocedimentales. Hay muy pocas de estas optimizaciones que ya están habilitadas de manera predeterminada durante la compilación de archivo único. Las optimizaciones interprocedimentales se describirán en una sección aparte.

4.4. Limitaciones de la autovectorización

No se puede usar la vectorización para acelerar el código del kernel de Linux, porque las instrucciones SIMD están deshabilitadas en el modo kernel con la opción –mno-sse. Es algo que hicieron intencionalmente los desarrolladores del kernel.

4.5. Optimización interprocedimental

El compilador puede llevar a cabo optimizaciones adicionales si es capaz de optimizar a través de límites de funciones. Por ejemplo, si el compilador sabe que algún argumento que llama a una función es constante, entonces puede crear una versión especial de la función ajustada especialmente a este argumento constante. Esta versión especial se puede optimizar posteriormente cuando se tengan conocimientos del valor del parámetro.

Para habilitar la optimización dentro de un único archivo, especifique la opción –ip. Cuando se especifica esta opción, el compilador genera un archivo de objeto final que el vinculador del sistema puede procesar. La desventaja de generar un archivo de objeto es la pérdida casi total de información; el compilador ni siquiera intenta extraer información de los archivos de objeto.

El archivo único puede ser insuficiente para el análisis debido a la pérdida de información. En este caso, es necesario agregar la opción –ipo. Cuando se incluye esta opción, el compilador compila archivos a una representación intermedia que luego es procesada por herramientas especiales de Intel: xiar y xild.

La herramienta xiar se debe usar para crear bibliotecas estáticas en lugar del archivador ar de GNU, y xild se debe usar en lugar del vinculador ld de GNU. Sólo es necesario hacerlo cuando se llama al vinculador y el archivador en forma directa. Una mejor estrategia es usar el controlador del compilador icc o icpc para la vinculación fina^[5]. El aspecto negativo del alcance extendido es que se pierde la ventaja de la compilación por separado: cada modificación de la fuente requiere de revinculación, y la revinculación conduce a la recompilación completa.

Hay una amplia lista de técnicas de optimización avanzadas que se benefician del análisis global. Algunas se detallan en la documentación de referencia. Debe tenerse en cuenta que algunas optimizaciones son específicas de Intel y se habilitan con las opciones –x*^[6].

Desafortunadamente, en Android las cosas son algo más complicadas respecto de las bibliotecas compartidas. En forma predeterminada, todos los símbolos globales son interrumpibles (preemptable). Este concepto es fácil de explicar con un ejemplo. Consideremos dos bibliotecas vinculadas al mismo ejecutable.

libone.so:

<i> 
int id(void) {
  return 1;
 }
  
libtwo.so:
int id(void) {
  return 2;
 }
int foo(void) {
  return id();
 }
 <i>

Supongamos que para crear las bibliotecas simplemente se ejecutó icc –fpic –shared –o .so .c. Sólo se dan las opciones estrictamente necesarias –fpic^[7] y –shared^[8].

Si el vinculador dinámico del sistema carga la biblioteca libone.so antes de la biblioteca libtwo.so, entonces la llamada a la función id() desde la función foo() se resuelve en la biblioteca libone.so.

Cuando el compilador optimiza la función foo(), no puede usar lo que sabe de id() desde la biblioteca libtwo.so. Por ejemplo, no puede incluir en línea la función id(). Si el compilador incluyera en línea la función id(), habría problemas con libone.so y libtwo.so.

En consecuencia, cuando se escriben bibliotecas compartidas, se debe tener cuidado de especificar qué funciones se pueden interrumpir. En forma predeterminada, todas las funciones y variables globales son visibles fuera de las bibliotecas compartidas y se las puede interrumpir. La configuración predeterminada no es conveniente cuando se implementan pocos métodos nativos. En este caso, es necesario exportar sólo símbolos que sean llamados directamente por la máquina virtual Java* Dalvik*.

El atributo de visibilidad de símbolos es una manera de especificar si los símbolos son visibles fuera del módulo y si se los puede interrumpir:

• La visibilidad “predeterminada” hace visibles a los símbolos globales^[9] fuera de la biblioteca compartida y los hace interrumpibles.
• La visibilidad “protegida” hace visibles a los símbolos fuera de la biblioteca compartida, pero no se los puede interrumpir.
• La visibilidad “oculta” hace visibles a los símbolos globales^[9] sólo dentro de la biblioteca compartida e imposibilita que sean interrumpidos.

De regreso en la aplicación hello-jni, necesitamos especificar que la visibilidad predeterminada es la oculta y que las funciones exportadas para JVM tienen visibilidad protegida.

Para establecer la visibilidad predeterminada como oculta, se agrega -fvisibility=hidden a la variable APP_CFLAGS en jni/Application.mk:

APP_CFLAGS := -O3 -xSSSE3_ATOM -vec-report3 -fvisibility=hidden -ipo

Para invalidar la visibilidad de Java_com_example_hellojni_HelloJni_stringFromJNI, se agrega el atributo a la definición de la función:

Jstring __attribute__((visibility("protected")))

Java_com_example_hellojni_HelloJni_stringFromJNI(JNIEnv* env, jobject thiz)

Volver a compilar y a instalar.

[1] Es posible que el NDK no necesite esta variable para la integración con Intel® C/C++ Compiler versión 13.0.

[2] Intel C++ Compiler versión 13.0 cuenta con la biblioteca adicional libirng.so que contiene una función optimizada para la generación pseudoaleatoria de números.

[3] Las instrucciones SSE escalares no realizan aritmética con precisión extendida. Si su aplicación depende de la precisión extendida para cálculos intermedios, use la opción –mp.

[4] Hay otras limitaciones menores; consulte las referencias. El compilador da una advertencia si no se respeta la sintaxis o si falla la vectorización con el pragma simd.

[5] Durante la configuración del NDK, hicimos que TARGET_AR apuntara a xiar y TARGET_LD, a xild

[6] Por ejemplo, para un destino Intel Atom, especifique –xSSSE3_ATOM.

[7] La opción –fpic especifica que el código se debe compilar de una manera tal que permita la carga en la dirección arbitraria. PIC son las siglas de position independent code (código independiente de la posición).

[8] La opción –shared especifica que el módulo vinculado es una biblioteca compartida.

[9] Un símbolo global es un símbolo que es visible desde otras unidades de compilación. A las funciones y variables globales se puede acceder desde cualquiera de los archivos de objeto que compongan la biblioteca compartida dada. Los atributos de visibilidad especifican relaciones entre función y variables en diferentes bibliotecas compartidas.

[1] Interfaz binaria de aplicación. Android sigue la System V ABI para arquitectura i386: http://www.sco.com/developers/devspecs/abi386-4.pdf

[2] No usamos el comando “ant release” porque requiere de la configuración apropiada de la firma del paquete.

As there are currently no public engineering devices from Intel, we will work with two images for emulated targets (Note: Please refer to http://source.android.com/source/initializing.html and http://source.android.com/source/downloading.html for the details. The pages help to resolve common problems with tools and environment. You may need to have a Google account.): the target QEMU-based emulator and the target for VirtualBox.

1  Building Android* Images with the GNU* Compiler for Android

The instructions for building an emulator image for ARM* is directly applicable to the Intel x86 target. We briefly describe the steps here.

1.1  Workspace Preparation

mkdir <WORKSPACE_DIRECTORY>
cd <WORKSPACE_DIRECTORY>
repo init -u https://android.googlesource.com/platform/manifest -b android-4.1.1_r3

Note: You may try other branch, for example, master.

repo sync

1.2  Configuring the Build Environment

The Google page does not explicitly mention the full_x86 target (Note: Please refer to http://source.android.com/source/building.html for the details.) but it is shown if you run the lunch command without arguments:
source build/envsetup.sh
lunch full_x86-eng

1.3  Building the Image

Finally choose the number of parallel jobs and run make: 

make –j <NUM_JOBS>

To check that the build was successful, launch the emulator command. Locate information about the system: Applications->Settings->About Phone, as shown in Figure 8.1.

To build the image for Virtual Box, specify the vbox_x86-eng parameter for the lunch command and 

source build/envsetup.sh

lunch vbox_x86-eng

make -j <NUM_JOBS> android_disk_vdi

2  Building Kernels

The instructions for building the kernel for the ARM* emulator are not directly applicable to the x86 targets. You need to correctly specify a compiler. Note that the default GCC compilers version 4.4.3 and 4.6 targeting Android cannot be used as-is for compiling the kernel, because the Android Application Binary Interface (ABI) differs from the Linux ABI. The important difference is that, by default, compilers for Android systems generate position-independent code. If you compile the kernel with GNU* or the Intel® C++ Compiler for Android, you need to add –mno-android or –fno-PIC options during compilation.

We briefly describe the steps to compile the kernel for the emulator. We assume that you have performed the emulator build in the <AOSP WORKSPACE> directory. Target compilers are taken from the workspace.

Prepare workspace:

git clone http://android.googlesource.com/kernel/goldfish.git goldfish-kernel

git branch goldfish remotes/origin/android-goldfish-2.6.29

git checkout goldfish

Configure kernel for emulator: 

make ARCH=x86 goldfish_defconfig

or for Virtual Box:

make ARCH=x86 vbox_defconfig.

ARCH=x86 was added to specify explicitly that we are going to build a kernel for a 32-bit system.

Now we are ready to build the kernel. In the next sections we will build the kernel using two compilers.

2.1  Building the Kernel using the GNU* Compiler for Android

To build the kernel, you need to specify the path to compiler and other tools, linker, assembler, and so on.

The easiest way configure all the paths is to define the CROSS_COMPILE environment variable. As noted before, we also need to add the –mno-android option to disable generation of position-independent code. We redefine the CC variable, so that –mno-andriod is used whenever the compiler is invoked.

export CROSS_COMPILE=<AOSP WORKSPACE>/prebuilts/gcc/linux-x86/x86/i686-linux-android-4.4.3/bin/i686-linux-android-

make ARCH=x86 CC="${CROSS_COMPILE}gcc -mno-android" bzImage 

Run the emulator with the new kernel

emulator –kernel arch/x86/boot/bzImage

and note that the Android emulator runs the new kernel (see Figure 8.2).

Como actualmente no hay dispositivos para ingeniería públicos de Intel, trabajaremos con dos imágenes para destinos emulados (para conocer los detalles, consulte las páginas http://source.android.com/source/initializing.html y http://source.android.com/source/downloading.html, en las cuales se ayuda a resolver problemas comunes con las herramientas y el entorno; es posible que necesite una cuenta de Google): el emulador de destino basado en QEMU y el destino para VirtualBox.

1 Creación de imágenes de Android* con el compilador GNU* para Android

Las instrucciones para compilar una imagen de emulador para ARM* se pueden aplicar directamente al destino Intel x86. Aquí incluimos una breve descripción de los pasos a seguir.

1.1 Preparación del espacio de trabajo

mkdir <WORKSPACE_DIRECTORY>
cd <WORKSPACE_DIRECTORY>
repo init -u https://android.googlesource.com/platform/manifest -b android-4.1.1_r3

Nota: se puede probar con otra rama, por ejemplo, master.

repo sync

1.2 Configuración del entorno de compilación

La página de Google no menciona de forma explícita el destino full_x86 (consulte http://source.android.com/source/building.html para conocer los detalles), pero este se muestra si ejecuta el comando lunch sin argumentos:
source build/envsetup.sh
lunch full_x86-eng

1.3 Compilación de la imagen

Por último, elija la cantidad de trabajos en paralelo y ejecute make:

make –j

Para comprobar que la compilación haya sido exitosa, inicie el comando emulator. Localice la información del sistema: Applications->Settings->About Phone, como se muestra en la Figura 8.1.

Figura 8.1 Localización de la información del sistema con About Phone

A fin de compilar la imagen para Virtual Box, especifique el parámetro vbox_x86-eng para el comando lunch y

source build/envsetup.sh

lunch vbox_x86-eng

make -j android_disk_vdi

2 Compilación de kernels

Las instrucciones para compilar el kernel para el emulador de ARM* no se aplican directamente a los destinos x86. Es necesario especificar el compilador. Se debe tener en cuenta que los compiladores predeterminados GCC versiones 4.4.3 y 4.6 con destino Android no se pueden usar tal como vienen para compilar el kernel, porque la interfaz binaria de aplicación (ABI) de Android difiere de la ABI de Linux. La diferencia clave es que, de manera predeterminada, los compiladores para sistemas Android generan código independiente de la posición. Si se compila el kernel con GNU* o el Compilador Intel® C++ para Android, es necesario agregar las opciones –mno-android o –fno-PIC durante la compilación.

Describiremos brevemente los pasos de compilación del kernel para el emulador. Suponemos que ya hemos hecho la compilación del emulador en el directorio <AOSP WORKSPACE>. Los compiladores del destino se toman del espacio de trabajo.

Preparación del espacio de trabajo:

git clone http://android.googlesource.com/kernel/goldfish.git goldfish-kernel

git branch goldfish remotes/origin/android-goldfish-2.6.29

git checkout goldfish

Configuración del kernel para el emulador:

make ARCH=x86 goldfish_defconfig

O para Virtual Box:

make ARCH=x86 vbox_defconfig.

ARCH=x86 se agregó para especificar de manera explícita que vamos a compilar un kernel para un sistema de 32 bits.

Ahora estamos en condiciones de compilar el kernel. En las secciones siguientes, compilaremos el kernel con dos compiladores.

2.1 Compilación del kernel con el compilador GNU* para Android

Para compilar el kernel, es necesario especificar la ruta del compilador y otras herramientas, el vinculador, el ensamblador, etc.

La manera más fácil de configurar todas las rutas es definir la variable de entorno CROSS_COMPILE. Como se indicó antes, también es necesario agregar la opción –mno-android para deshabilitar la generación de código independiente de la posición. Redefinimos la variable CC de modo que se use –mno-andriod cada vez que se invoque el compilador.

export CROSS_COMPILE=<AOSP WORKSPACE>/prebuilts/gcc/linux-x86/x86/i686-linux-android-4.4.3/bin/i686-linux-android-

make ARCH=x86 CC="${CROSS_COMPILE}gcc -mno-android" bzImage

Ejecute el emulador con el nuevo kernel

emulator –kernel arch/x86/boot/bzImage

y observe que el emulador de Android ejecuta el nuevo kernel (ver Figura 8.2).

Figura 8.2 El emulador de Android ejecuta el nuevo kernel.

Si se elige trabajar con la imagen de Virtual Box, se necesita realizar una recompilación de la imagen de todo el sistema y especificar el nuevo kernel como parámetro de make:

cd <AOSP WORKSPACE >

rm out/target/product/vbox_x86/kernel

make -j <NUM_JOBS> LOCAL_KERNEL=<path to goldfish-kernel directory>/arch/x86/boot/bzImage android_disk_vdi

2.2 Compilación del kernel con el Compilador Intel® C++ para Android

Las instrucciones para el compilador de Intel son ligeramente más complicadas. Vamos a suponer que el kernel para el emulador ya está configurado.

export CROSS_COMPILE=<AOSP WORKSPACE>/prebuilts/gcc/linux-x86/x86/i686-linux-android-4.4.3/bin/i686-linux-android-

export ANDROID_GNU_X86_TOOLCHAIN=$(dirname $CROSS_COMPILE)/../

make ARCH=x86 CC="<path to compiler>/icc -fno-PIC -falign-stack=assume-4-byte -diag-disable 47,1419,311,147,175 -mno-sse -mno-sse2" bzImage

El compilador de Intel necesita archivos de encabezado de GCC, y la variable de entorno ANDROID_GNU_X86_TOOLCHAIN especifica la instalación de GCC en root para el compilador de Intel. También agregamos varias opciones:

• -fno-PIC es necesaria para deshabilitar la generación de código independiente de la posición.
• -diag-disable 47,1419,311,147,175 es necesaria para evitar errores de compilación debidos a la opción –Werror en los archivos make del kernel; por lo general, el compilador de Intel genera más advertencias que el GCC;
• -mno-sse -mno-sse2 es necesaria porque algunos archivos de los subdirectorios arch/x86/boot se compilan sin estos indicadores. Estas opciones se especifican para la mayoría de los archivos fuente; informamos esto a los desarrolladores de kernel.

Si se ejecuta el emulador con el nuevo kernel en modo detallado

emulator –kernel arch/x86/boot/bzImage –show-kernel

la salida permitirá ver que el kernel se compiló con icc en modo de compatibilidad con gcc 4.4.3.

Para habilitar las optimizaciones específicas de Intel para Intel® Atom™, se debe modificar el archivo arch/x86/Makefile_32.cpu:

• eliminar la línea que configura cflags-$(CONFIG_X86_GENERIC);
• agregar la línea cflags-$(CONFIG_MCORE2) += $(call cc-option,-xSSSE3_ATOM).

No podemos agregar simplemente -xSSSE3_ATOM a las opciones restantes, porque las invalidarían opciones del compilador GNU* tales como –march=i686.

3 Compilación de imágenes con el Compilador Intel® C++ para Android

El sistema de compilación de Android está diseñado de manera que permita la configuración fina de componentes. Por ejemplo, es posible especificar opciones de compilador especiales para mejorar el rendimiento componente por componente. Se puede definir una variable LOCAL_CC para invalidar el compilador C en el archivo Android.mk del componente. La única restricción es que el compilador debe admitir opciones de compilador globales. Si no admite todas las opciones, entonces se deben hacer retoques especiales en el sistema de compilación de Android.

Este sistema de compilación también deja la posibilidad de conmutar compiladores globalmente; el principal lugar para hacer ajustes dirigidos a un compilador específico es el archivo build/core/combo/TARGET_linux-x86.mk. Aquí se ubican las rutas al compilador, el ensamblador, otras herramientas y las herramientas binarias. En este archivo también se especifican las opciones predeterminadas del compilador.

3.1 Integración del compilador de Intel

Haremos que el compilador de Intel sea el predeterminado. Comenzamos con modificaciones en el archivo build/core/combo/TARGET_linux-x86.mk.

Primero especificamos el root da la instalación del compilador en la variable TARGET_TOOLCHAIN_ROOT.

TARGET_TOOLCHAIN_ROOT := prebuilts/icc

Vamos a suponer que el compilador de Intel se copió al directorio prebuilts/icc. Luego inicializamos la variable de entorno ANDROID_GNU_X86_TOOLCHAIN con el directorio de nivel superior de las herramientas de GNU:

export ANDROID_GNU_X86_TOOLCHAIN:=$(abspath prebuilts/gcc/$(HOST_PREBUILT_TAG)/x86/i686-android-linux-4.4.3)

También hay que cambiar las rutas de las herramientas y los compiladores:

TARGET_TOOLS_PREFIX :=$(TARGET_TOOLCHAIN_ROOT)/bin/

TARGET_CC:=$(TARGET_TOOLS_PREFIX)icc$(HOST_EXECUTABLE_SUFFIX)

TARGET_CXX:=$(TARGET_TOOLS_PREFIX)icpc$(HOST_EXECUTABLE_SUFFIX)

TARGET_AR:=$(TARGET_TOOLS_PREFIX)xiar$(HOST_EXECUTABLE_SUFFIX)

TARGET_LD:=$(TARGET_TOOLS_PREFIX)xild$(HOST_EXECUTABLE_SUFFIX)

TARGET_OBJCOPY:=$(ANDROID_GNU_X86_TOOLCHAIN)/bin/i686-android-linux-objcopy$(HOST_EXECUTABLE_SUFFIX)

TARGET_STRIP:=$(ANDROID_GNU_X86_TOOLCHAIN)/bin/i686-android-linux-strip$(HOST_EXECUTABLE_SUFFIX)

Revisamos la variable TARGET_GLOBAL_CFLAGS, reemplazamos las opciones del compilador GNU con las correspondientes del compilador de Intel y agregamos opciones específicas de la arquitectura.

Al modificar la variable TARGET_GLOBAL_CFLAGS, no hay que olvidarse de corregir las opciones para el compilador clang. Con el fin de eliminar la opción específica de Intel –xSSSE3_ATOM para clang, se inserta la línea $(call clang-flags-subst,-xSSSE3_ATOM) en el archivo build/core/llvm_config.mk.

El siguiente paso es configurar componentes precompilados correspondientes a las bibliotecas del compilador de Intel. Para abreviar, consideraremos sólo la versión compartida de la biblioteca libimf. Creamos el archivo prebuilts/icc/Android.mk y le agregamos las siguientes líneas:

LOCAL_PATH := /

include $(CLEAR_VARS)

LOCAL_SYSTEM_SHARED_LIBRARIES:=

LOCAL_MODULE := libimf

LOCAL_MODULE_SUFFIX:=.so

LOCAL_STRIP_MODULE:=true

LOCAL_MODULE_TAGS := optional

LOCAL_MODULE_CLASS := SHARED_LIBRARIES

LOCAL_SRC_FILES := $(shell env ANDROID_GNU_X86_TOOLCHAIN=$(ANDROID_GNU_X86_TOOLCHAIN) $(TARGET_CC) -print-file-name=libimf.so)

include $(BUILD_PREBUILT)

En el caso de las bibliotecas estáticas, la actualización de LOCAL_MODULE_SUFFIX, LOCAL_SRC_FILES y LOCAL_MODULE_CLASS debería ser trivial. Sugerimos tener diferentes valores de LOCAL_MODULE para las versiones compartidas y estáticas de la misma biblioteca, porque los nombres repetidos de los módulos precompilados confundían a los sistemas de compilación de Android anteriores.

El valor de LOCAL_PATH parece inusual. En la mayoría de los archivos Android.mk, LOCAL_PATH se inicializa al valor de la llamada a la macro my-dir: $(call my-dir). LOCAL_PATH se inicializa a ‘/’ porque las rutas de las bibliotecas, especificadas en la variable LOCAL_SRC_FILES, son absolutas. Con el fin de evitar el copiado manual de las bibliotecas, invocamos el compilador con la opción especial -print-file-name para consultar la ubicación de las bibliotecas.

Como muchas bibliotecas compartidas y muchos archivos ejecutables vinculados de manera no estática dependerán de bibliotecas compartidas de Intel, las bibliotecas dependientes deberían encontrarlos. Por ejemplo, la imagen del instalador de la imagen de Virtual Box debe contener bibliotecas de Intel y es necesario agregarlas al archivo bootable/diskinstaller/config.mk:

installer_base_files += libimf libintlc libsvml

El entorno TARGET_DEFAULT_SYSTEM_SHARED_LIBRARIES de build/core/combo/TARGET_linux-x86.mk define la lista de bibliotecas compartidas que se vinculan de manera predeterminada. Se deben agregar a esta variable todas las bibliotecas compartidas de Intel.

Antes de empezar a compilar la imagen, hay que agregar la opción –ffreestanding a la variable LOCAL_CFLAGS para todos los módulos del directorio bionic. Esta opción hace que las bibliotecas bionic y el vinculador dinámico sean independientes de las bibliotecas del compilador.

Ahora se puede comenzar a compilar la imagen:

make –j 4 SHOW_COMMANDS=1

Es probable que la compilación no sea exitosa. Y por varias razones. La primera es que algunos componentes necesitarán bibliotecas del compilador de Intel durante la vinculación. Agregar bibliotecas del compilador de Intel a TARGET_DEFAULT_SYSTEM_SHARED_LIBRARIES resuelve la mayoría de los casos, pero no todos. Se necesitará agregar bibliotecas del compilador de Intel a las variables LOCAL_SYSTEM_SHARED_LIBRARIES o LOCAL_STATIC_LIBRARIES si el componente es un archivo ejecutable vinculado estáticamente o si el componente invalida la configuración predeterminada.

La segunda razón es que el compilador de Intel genera más advertencias que el GCC y se produce un error de compilación en algún componente debido a to-Werror. Hay que deshabilitar las advertencias en la variable TARGET_GLOBAL_CFLAGS desde el archivo build/core/combo/TARGET_linux-x86.mk mediante el uso de la opción -diag-disable.

La tercera razón es la incompatibilidad de código fuente entre los compiladores GNU e Intel*. Hay algunas construcciones no estándares de código fuente de Android que el compilador de Intel rechaza. Estas se corrigieron y fueron informadas a Google. También encontramos incompatibilidad binaria entre el compilador GNU y el de Intel; se implementó una solución alternativa en el código.

3.2 Configuración flexible del sistema de compilación

La integración descrita en la sección anterior es directa y no adecuada para experimentar, porque cambiar el compilador para el componente requiere de varios pasos. Después de varios experimentos iniciales, implementamos una reconfiguración precomponente más simple del compilador.

Ahora se implementa un sistema similar en fuentes Android para el compilador clang de LLVM. Para compilar el componente con clang, sólo es necesario asignar el valor “true” a la variable LOCAL_CLANG. La habilitación de clang afecta a tres archivos del directorio build,

• core/llvm_config.mk– diversos parámetros y funciones variables para clang;
• core/clear_vars.mk– valor predeterminado de la variable LOCAL_CLANG;
• core/binary.mk– aquí se implementa toda la lógica relacionada con los indicadores del compilador, los indicadores del vinculador, etc.

Los cambios al compilador clang se explican por sí mismos. Recomendamos echarles un vistazo.

Scalable Vector Graphics* (SVG) is a family of specifications of an XML-based file format for two-dimensional vector graphics, both static and dynamic (that is, interactive or animated), text or embedded raster graphics. The SVG specification is a royalty-free vendor-neutral open standard that has been under development by the World Wide Web Consortium* (W3C) since 1999.

SVG images and their behaviors are defined in XML text files. This means that they can be searched, indexed, scripted and, if required, compressed. As XML files, SVG images can be created and edited with any text editor.

SVG files are compact and provide high-quality graphics on the Web, in print, and on resource-limited handheld devices. In addition, SVG supports scripting and animation, so is ideal for interactive, data-driven, personalized graphics.

Using SVG has many benefits. First, you don’t need to have pictures in different resolutions, no need to scale. Second, SVG is an XML file, so its size is much smaller than the raster size format for the same image. This also helps to change the picture on the fly.

SVG allows three types of graphic objects: vector graphics, raster graphics, and text. Graphical objects, including PNG and JPEG raster images, can be grouped, styled, transformed, and composited into previously rendered objects.

Native Android* applications do not support SVG XML files. But SVG XML files could be parsed in browsers starting with Android 3.0 (see Figure 1). This chapter integrates the SVG-Android open source library into codebase and provides an example application on Intel® architecture Android Ice Cream Sandwich (ICS).

1.    SVG Functionality

The SVG 1.1 specification defines 14 functional areas of feature sets, which are:

• Paths
• Basic shapes
• Text
• Painting
• Color
• Gradients and patterns
• Clipping, masking, and compositing
• Filter effects
• Interactivity
• Linking
• Scripting
•  Animation
• Font
• Metadata

2.    SVG Shapes

SVG's predefined shape elements are:

• Rectangle <rect>

<svg>

<rect x="50" y="20" width="150" height="150" style="fill: red;

stroke: yellow; stroke-width: 5; opacity: 0.5" />

</svg>

•  Circle <circle>

<svg >

<circle cx="100" cy="50" r="40" stroke="black" stroke-width="2"

fill="red" />

</svg>

•  Ellipse <ellipse>
•  Line <line>
•  Polyline <polyline>
•  Polygon <polygon>
• Path<path>

<svg xmlns="http://www.w3.org/2000/svg" version="1.1">

<path d="M150 0 L75 200 L225 200 Z" />

</svg>

Figure 1: SVG Implementation on Android Device

Source: Intel Corporation, 2012

 3.  SVG Library Integration

Create a file named svgandroid.xml to describe svgandroid.jar. Place svgandroid.jar in /system/framework folder and svgandroid.xml in the /etc/permissions folder. Applications will discover svgandroid.jar library through svgandroid.xml.

Put the following code into the svgandroid.xml:

<?xml version="1.0" encoding="utf-8">

<permissions>

<libraryname="svgandroid" file="/system/framework/svgandroid.jar"/>

</permissions>

Use the <use-library> declaration in the AndroidManifest.xml file. This method loads the svgandroid packages. They will not be loaded automatically.

<uses-library android:name="svgandroid" android:required="true" />

Set android:required="true". The Android system would not permit an application on a device without this library.

If this application is installed on Android devices without this library, the following error message occurs:

Failure [INSTALL_FAILED_MISSING_SHARED_LIBRARY]

This element also affects the availability of the application on Market. The Android device could not list this application on Market without the library.

4.    Render a File Using Revised SVG

This section shows how to render a file using revised SVG.

4.1.  What is SAX?

SAX (Simple API for XML) is an event-based sequential access parser API generated by the XML-DEV mailing list for XML documents. SAX’s mechanism for reading data from an XML document is very different than the one provided by the Document Object Model (DOM). Where the DOM operates on the document as a whole, SAX parsers operate on each piece of the XML document sequentially.

4.2.  Benefits

SAX parsers have certain benefits over DOM-style parsers. A SAX parser typically uses much less memory than a DOM parser. DOM parsers must have the entire tree in memory before any processing can begin, so the amount of memory used by a DOM parser depends entirely on the size of the input data. The memory footprint of a SAX parser, by contrast, is based only on the maximum depth of the XML file (the maximum depth of the XML tree) and the maximum data stored in XML attributes on a single XML element. Both of these are always smaller than the size of the parsed tree itself.

Because of the event-driven nature of SAX, processing documents can often be faster than DOM-style parsers. Memory allocation takes time, so the larger memory footprint of the DOM is also a performance issue.

Due to the nature of DOM, streamed reading from disk is impossible. Processing XML documents larger than main memory is also impossible with DOM parsers, but can be done with SAX parsers. However, DOM parsers can make use of disk space as memory to sidestep this limitation.

4.3.  Drawbacks

The event-driven model of SAX is useful for XML parsing, but it does have certain drawbacks.

Certain kinds of XML validation require access to the document in full. For example, a DTD IDREF attribute requires that there be an element in the document that uses the given string as a DTD ID attribute. To validate this in a SAX parser, one would need to keep track of every previously encountered ID and IDREF attributes to see if any matches are made. Furthermore, if an IDREF does not match an ID, the user only discovers this after the document has been parsed. If this linkage was important to building functioning output, then time has been wasted in processing the entire document only to throw it away.

Additionally, some kinds of XML processing simply require having access to the entire document. XSLT and XPath, for example, need to be able to access any node at any time in the parsed XML tree. While a SAX parser could be used to construct such a tree, the DOM already does so by design.

4.4.  How to Implement the SAX Parser in Android

When implementing SAX parser, the class needs to inherit “DefaultHandler". And there are a few methods that need to be overridden when inheriting the “DefaultHandler"—default base class for SAX2 event handlers in Android. These methods include startElement, endElement, startDocument, and endDocument. You can easily see what each function does by its name. For example, startDocument means when the SAX starts to parse the document, it will trigger the event and call the startDocument method. Once the SAX parses any tag of XML file, it will call startElement, so you can get the tag name, attribute, and some other information relevant to the tag. The other methods, endDocument, startElement, and endElement, are self-explanatory.

4.5.  Why Revise the Original SVG Library?

Since the original library can’t render the SVG file with attributes in the group tag (<g>), we must add a register to store the style attribute with a <g> tag. If there is already a style attribute in the inner render element, the style attribute will replace the one in the <g> tag.

We recommend using SAX to parse the SVG file. When we parsing the <g> tag, we retrieve the entire attribute into the instance –g_prop, which is an internal class of the properties.

public void startElement(String namespaceURI, String localName, String qName, Attributes atts) throws SAXException

{

……

} else if (localName.equals("g")) {

……

pushTransform(atts);

g_prop = new Properties(atts);

}

……

}

public void startElement(String namespaceURI, String localName, String qName, Attributes atts) throws SAXException

 

{

……

} else if (localName.equals("g")) {

……

pushTransform(atts);

g_prop = new Properties(atts);

}

……

}

 

When we parse the <rectangle>, <path> or any other rendering tags, we need to check if there is any style associated with the tag. If there is, we need to get the attributes. The methods doFill, doStroke help to initiate the style of fill and stroke of the canvas. After these methods are invoked, we can draw the parsed element onto the canvas.

Properties props = new Properties(atts);

if (doFill(props, gradientMap))

{

doLimits(p);

canvas.drawPath(p, paint);

}

else

{

if(g_prop != null)

{

if(doFill(g_prop, gradientMap))

{

doLimits(p);

canvas.drawPath(p, paint);

}

}

}

if (doStroke(props))

canvas.drawPath(p, paint);

else

{

if(g_prop != null)

{

if(doStroke(g_prop))

canvas.drawPath(p, paint);

}

}

popTransform();

}

Properties props = new Properties(atts);

if (doFill(props, gradientMap))

{

doLimits(p);

canvas.drawPath(p, paint);

}

else

{

if(g_prop != null)

{

if(doFill(g_prop, gradientMap))

{

doLimits(p);

canvas.drawPath(p, paint);

}

}

}

 

if (doStroke(props))

canvas.drawPath(p, paint);

else

{

if(g_prop != null)

{

if(doStroke(g_prop))

canvas.drawPath(p, paint);

}

}

popTransform();

}

3.6.               SVG XML File with Attributes in the Rendering Tag

The following is an SVG XML file with attributes in the rendering tag (see Figure 2). 

<path display="none" fill="#FFFFFF"

d="M268.461,471.01c2.526,0,4.575,2.048,4.575,4.571c0,2.529-2.049,4.576-4.575,4.576

c-2.525,0-4.574-2.047-4.574-4.576C263.887,473.058,265.936,471.01,268.461,471.01z"/>

Figure 2: SVG Implementation on Android Device

Source:. Intel Corporation, 2012

4.  SVG XML File with Attributes in Group Tag

The following is an SVG XML file with attributes in the group tag.

<g style="fill: #ffffff; stroke:#000000; stroke-width:0.172">

<path d="M-122.304 84.285C-122.304 84.285 -122.203 86.179 -123.027 86.16C-123.851 86.141 -140.305 38.066 -160.833 40.309C-160.833 40.309 -143.05 32.956 -122.304 84.285z"/>

</g>

Figure 3: SVG Implementation on Android Device

Source: Intel Corporation, 2012

Scalable Vector Graphics* (que significa Gráficos Vectoriales Redimensionables y se conoce por sus siglas SVG) es una familia de especificaciones de un formato de archivo basado en XML para gráficos vectoriales bidimensionales, tanto estáticos como dinámicos (es decir, interactivos o animados), texto o gráficos de trama incrustados. La especificación SVG es un estándar abierto exento del pago de regalías e independiente del proveedor que ha estado desarrollando el World Wide Web Consortium* (W3C) desde 1999.

Las imágenes SVG y su comportamiento se definen en archivos de texto XML. Esto significa que se las puede buscar, indexar, incluir en scripts y, si es necesario, comprimirlas. Al ser archivos XML, se las puede crear y modificar con cualquier editor de texto.

Los archivos SVG son compactos y proporcionan gráficos de alta calidad en la Web, en impresiones y en dispositivos de mano con recursos limitados. Además, SVG es compatible con el scripting y la animación, así que es ideal para gráficos interactivos, controlados por datos y personalizados.

Usar SVG ofrece muchos beneficios. En primer lugar, no es necesario tener imágenes en diferentes resoluciones ni hacer redimensionamientos. En segundo lugar, SVG es un archivo XML, así que su tamaño es mucho menor que el correspondiente en formato de trama para la misma imagen. Esto también es útil para cambiar la imagen al vuelo.

SVG admite tres tipos de objetos gráficos: gráficos vectoriales, gráficos de trama, y texto. Los objetos gráficos, incluidas las imágenes de trama PNG y JPEG, se pueden agrupar, transformar, se les puede aplicar un estilo y se los puede componer en objetos ya representados.

Las aplicaciones nativas de Android* no admiten archivos XML SVG. Pero los archivos XML SVG se podrían analizar en exploradores a partir de Android 3.0 (ver Figura 1). En este capítulo se integra la biblioteca open source SVG-Android a la base de código y se brinda una aplicación de ejemplo en Android Ice Cream Sandwich (ICS) sobre arquitectura Intel®.

1. Funcionalidad de SVG

La especificación SVG 1.1 define 14 áreas funcionales de conjuntos de características, a saber:

• Rutas
• Formas básicas
• Texto
• Pintura
• Color
• Gradientes y tramas
• Recorte, enmascaramiento y composición
• Efectos de filtro
• Interactividad
• Vinculación
• Scripting
• Animación
• Fuente
• Metadatos

2. Formas de SVG

Los elementos de forma predeterminados de SVG son:

• Rectángulo <rect>

<svg>
<rect x="50" y="20" width="150" height="150" style="fill: red;
stroke: yellow; stroke-width: 5; opacity: 0.5" />
</svg>

• Círculo <circle>

<svg >
<circle cx="100" cy="50" r="40" stroke="black" stroke-width="2"
fill="red" />
</svg>

• Elipse <ellipse>
• Línea <line>
• Polilínea <polyline>
• Polígono <polygon>
• Ruta <path>

<svg xmlns="http://www.w3.org/2000/svg" version="1.1">

<path d="M150 0 L75 200 L225 200 Z" />
</svg>

Figure 1. Implementación de SVG en dispositivo Android
Fuente: Intel Corporation, 2012

3. Integración de la biblioteca SVG

Cree un archivo de nombre svgandroid.xml para describir svgandroid.jar. Coloque svgandroid.jar en la carpeta /system/framework y svgandroid.xml en la carpeta /etc/permissions. Las aplicaciones descubrirán la biblioteca svgandroid.jar mediante svgandroid.xml.

Agregue el siguiente código a svgandroid.xml:

<?xml version="1.0" encoding="utf-8">
<permissions>
<libraryname="svgandroid" file="/system/framework/svgandroid.jar"/>
</permissions>

Use la declaración <use-library> en el archivo AndroidManifest.xml. Este método carga los paquetes de svgandroid. No se cargan automáticamente.

<uses-library android:name="svgandroid" android:required="true" />

Establezca android:required="true". El sistema Android no permitiría aplicaciones en un dispositivo sin esta biblioteca.

Si se instala esta aplicación en dispositivos Android sin esta biblioteca, aparece el siguiente mensaje de error:

Failure [INSTALL_FAILED_MISSING_SHARED_LIBRARY]

Este elemento afecta también la disponibilidad de esta aplicación en Market. El dispositivo Android no podría incluir esta aplicación en Market sin la biblioteca.

4. Cómo representar un archivo con SVG modificada

En esta sección se muestra cómo representar un archivo mediante el uso de SVG modificada.

4.1. ¿Qué es SAX?

SAX (Simple API for XML) es una API analizadora de acceso secuencial basada en eventos que genera la lista de correo de XML-DEV para los documentos XML. El mecanismo de SAX para leer datos de documentos XML es muy diferente del que proporciona el Document Object Model (DOM). Mientras que el DOM opera en el documento como unidad, los analizadores SAX operan en cada parte del documento XML de manera secuencial.

4.2. Beneficios

Los analizadores SAX ofrecen ciertos beneficios respecto de los analizadores estilo DOM. Normalmente, usan mucha menos memoria. Los analizadores DOM deben tener el árbol completo en la memoria antes de poder comenzar a procesar, así que la memoria que usan depende por completo del tamaño de los datos de entrada. La superficie de memoria de los analizadores SAX, en cambio, sólo se basa en la profundidad máxima del archivo XML (la profundidad máxima del árbol XML) y la cantidad máxima de datos almacenados en los atributos XML de un solo elemento XML. Estos valores son siempre menores que el tamaño del árbol analizado.

Como SAX se basa en eventos, con frecuencia el procesamiento de documentos es más rápido que en los analizadores estilo DOM. La asignación de memoria lleva tiempo, así que la mayor superficie de memoria del DOM constituye también un problema de rendimiento.

Debido a la naturaleza del DOM, es imposible leer por secuencias desde el disco. También es imposible con estos analizadores procesar documentos XML más grandes que la memoria principal, pero es algo que se puede hacer con los analizadores SAX. Sin embargo, los analizadores DOM pueden usar espacio de disco como memoria para esquivar esta limitación.

4.3. Desventajas

El modelo basado en eventos de SAX es útil para analizar documentos XML, pero tiene algunos inconvenientes.

Para ciertos tipos de validación de XML se requiere acceso a todo el documento. Por ejemplo, un atributo DTD IDREF requiere que haya un elemento en el documento que use la cadena dada como atributo DTD ID. Para hacer esta validación en un analizador SAX, sería necesario hacer un seguimiento de todos los atributos ID e IDREF encontrados para ver si hay alguna coincidencia. Además, si un IDREF no se empareja con un ID, el usuario recién lo descubre después de que se ha analizado el documento. Si esta vinculación fuera importante para crear salidas funcionales, entonces se habría desperdiciado tiempo en procesar todo el documento para que al final no sirva.

Además, algunos tipos de procesamientos de XML exigen tener acceso a todo el documento. XSLT y XPath, por ejemplo, necesitan poder acceder en cualquier momento a cualquier nodo del árbol XML analizado. Si bien se podría usar un analizador SAX para construir ese árbol, el DOM ya está diseñado para hacerlo.

4.4. Cómo implementar el analizador SAX en Android

Cuando se implementa un analizador SAX, es necesario que la clase herede “DefaultHandler". Y hay varios métodos que se deben invalidar para heredar “DefaultHandler" (la clase de base predeterminada para controladores de eventos SAX2 en Android). Estos métodos son startElement, endElement, startDocument y endDocument. El nombre de cada función describe lo que hace. Por ejemplo, startDocument significa que cuando el SAX comienza a analizar el documento, desencadena un evento y llama al método startDocument. Una vez que el SAX analiza una etiqueta cualquiera de archivo XML, llama a startElement para que se pueda obtener el nombre de la etiqueta, el atributo y más información pertinente de la etiqueta. Los otros métodos, endDocument, startElement y endElement, se explican por sí mismos.

4.5. ¿Cuál es la razón para modificar la biblioteca SVG original?

Como la biblioteca original no puede representar el archivo con atributos en la etiqueta de grupo (<g>), debemos agregar un registro para guardar el atributo de estilo con una etiqueta <g>. Si ya hay un atributo de estilo en el elemento de representación interno, el atributo de estilo reemplazará al de la etiqueta <g>.

Recomendamos usar SAX para analizar el archivo SVG. Cuando analizamos la etiqueta <g>, recuperamos todo el atributo para la instancia –g_prop, que es una clase interna de las propiedades.

public void startElement(String namespaceURI, String localName, String qName, Attributes atts) throws SAXException
{
... ...
} else if (localName.equals("g")) {
... ...
pushTransform(atts);
g_prop = new Properties(atts);
}
... ...
}
public void startElement(String namespaceURI, String localName, String qName, Attributes atts) throws SAXException
  
{
... ...
} else if (localName.equals("g")) {
... ...
pushTransform(atts);
g_prop = new Properties(atts);
}
... ...
}

Cuando analizamos <rectangle>, <path> o cualquier otra etiqueta de representación, necesitamos revisar si hay algún estilo asociado a la etiqueta. Si lo hay, debemos obtener los atributos. Los métodos doFill, doStroke ayudan a iniciar el estilo de llenado y trazo del lienzo. Una vez invocados los métodos, podemos dibujar el elemento analizado en el lienzo.

Properties props = new Properties(atts);
if (doFill(props, gradientMap))
{
doLimits(p);
canvas.drawPath(p, paint);
}
else
{
if(g_prop != null)
{
if(doFill(g_prop, gradientMap))
{
doLimits(p);
canvas.drawPath(p, paint);
}
}
}
if (doStroke(props))
canvas.drawPath(p, paint);
else
{
if(g_prop != null)
{
if(doStroke(g_prop))
canvas.drawPath(p, paint);
}
}
popTransform();
}
Properties props = new Properties(atts);
if (doFill(props, gradientMap))
{
doLimits(p);
canvas.drawPath(p, paint);
}
else
{
if(g_prop != null)
{
if(doFill(g_prop, gradientMap))
{
doLimits(p);
canvas.drawPath(p, paint);
}
}
}
  
if (doStroke(props))
canvas.drawPath(p, paint);
else
{
if(g_prop != null)
{
if(doStroke(g_prop))
canvas.drawPath(p, paint);
}
}
popTransform();
}

3.6. Archivo XML SVG con atributos en la etiqueta de representación

El siguiente es un archivo XML SVG con atributos en la etiqueta de representación (ver Figura 2).

<path display="none" fill="#FFFFFF" d="M268.461,471.01c2.526,0,4.575,2.048,4.575,4.571c0,2.529-2.049,4.576-4.575,4.576 c-2.525,0-4.574-2.047-4.574-4.576C263.887,473.058,265.936,471.01,268.461,471.01z"/>

Figure 2. Implementación de SVG en dispositivo Android
Fuente: Intel Corporation, 2012

4. Archivo XML SVG con atributos en la etiqueta de grupo

El siguiente es un archivo XML SVG con atributos en la etiqueta de grupo.

<g style="fill: #ffffff; stroke:#000000; stroke-width:0.172">

<path d="M-122.304 84.285C-122.304 84.285 -122.203 86.179 -123.027 86.16C-123.851 86.141 -140.305 38.066 -160.833 40.309C-160.833 40.309 -143.05 32.956 -122.304 84.285z"/>

</g>

Figure 3. Implementación de SVG en dispositivo Android
Fuente: Intel Corporation, 2012

1  Supported Operating Systems

The following operating systems are supported:
•    Windows XP* (32-bit), Vista* (32- or 64-bit), or Windows 7* (32- or 64-bit)
•    Mac OSX* (32- or 64-bit)
•    Linux* (Ubuntu, Fedora); GNU C Library (glibc) 2.7 or later is required.
•    On Ubuntu Linux, version 8.04 or later is required.
•    On Fedora, target versions are F-12 and higher.
•    64-bit distributions must be capable of running 32-bit applications.

  2  Hardware Requirements

The Android SDK requires disk storage for all of the components that you choose to install. Additional disk space is required to run the emulator, for example, to create SD cards for the Android Virtual Devices (AVDs).

  3  Installing the JDK

At minimum, Java* JDK 5 or JDK 6 is required by the SDK. JDK 7 is also supported. JRE (Java Runtime Environment) alone is not sufficient. If your system does not have JDK 5, 6, or 7 installed, you can download JDK SE 7 from http://www.oracle.com/technetwork/java/javase/downloads/index.html and install it on your system.

  4  Installing Eclipse*

Using the SDK with Eclipse* to develop Android applications is highly recommended. You can go to http://www.eclipse.org/downloads/ to download or update Eclipse. We suggest using the following Eclipse setups to develop Android Applications for Intel Architecture:
•    Eclipse 3.5 (Galileo) or greater
•    Eclipse Classic (versions 3.5.1 and higher)
•    Android Development Tools Plugin (recommended)

  5  Installing Apache Ant (Optional)

Developing Android applications using an integrated development environment such as Eclipse is highly recommended. But as an alternative, Apache Ant can be used to work with the SDK to build Android applications. You can visit http://ant.apache.org/ to download the binary distributions and install Ant. To work with the SDK, Ant 1.8 or later is required.

  6  Downloading the SDK Starter Package and Adding the SDK Components

You can download the SDK Starter Package at http://developer.android.com/sdk/index.html. The SDK Starter Package does not include the platform-specific components you need to develop Android applications. It only provides the core SDK tools for you to download the rest of the platform components.
After installing the SDK Starter Package, run the Android SDK and AVD Manager.
•    On Windows, select Start > All Programs > Android SDK Tools > SDK Manager
•    On Linux, run your-android-sdk-directory/tools/android
In the Android SDK and AVD Manager dialog box, in the left panel, select Available packages, and in the right panel, click and expand the Android Repository node and select the packages to install, as shown in Figure 5.1.
Please note: you may see an error message displayed if you attempt to download from behind a firewall. If this occurs, please try again from outside the firewall.
If you still see an error message, close the SDK Manager, then right-click it in the Start menu and select Run as administrator. These two steps will resolve most error messages you may see when attempting to download.

7  Setting Up Eclipse to Work with the SDK

If you use the Eclipse IDE to develop software, we highly recommend you install and set up the Android Development Tool (ADT) Plugin.

7.1 Installing the ADT Plugin for Eclipse

To install the ADT Plugin for Eclipse, follow these steps:
1.    Start Eclipse, select Help > Install New Software in the Install dialog box, and click the Add button.
2.    In the Add Repository dialog box, enter “ADT Plugin” in the Name field and enter “https://dl-ssl.google.com/android/eclipse/” in the Location fields, as shown in Figure 5.2, and then click OK.

Figure 5.2 Repository Dialog Box

3.   It will go back to the Install dialog box, connect to the Google repository server, and display the available ADT packages, as shown in Figure 5.3.

Figure 5.3 ADT Package List

4. Select next, accept the license agreement, and select Finish.

5.  Restart Eclipse at this point.

7.2 Configuring the ADT Plugin

To configure the ADT Plugin, follow these steps:

1.     Start Eclipse and select Windows > Preferences

2.     In the Preferences dialog box, select Android from the left panel. On the right panel, use the Browse button to navigate to your Android SDK installation directory and click Apply. A list of SDK Targets you have installed will show up. At this point, click OK.

Figure 5.4 Preferences Dialog Box

After going through the steps described above, you will have the necessary tools available to start Android for Intel Architecture development. You now have everything you need to write your first app, but it would probably be best to also install the Intel^® Architecture (x86) Emulator at this time, so that you can test your app as soon as it is ready. This next section will take you through the Intel Architecture (x86) Emulator install. We will discuss building an emulator image with AOSP sources, and emulating the resulting system images for x86. Some new features introduced in Gingerbread* and Ice Cream Sandwich* will also be discussed.

Overview of Android Virtual Device Emulation

Android runs on a variety of form factor devices with different screen sizes, hardware capabilities, and features. A typical device has a multitude of software (Android API) and hardware capabilities like sensors, GPS, camera, SD card and multitouch screen with specific dimensions.

The emulator is quite flexible and configurable with different software and hardware configuration options. Developers can customize the emulator using the emulator configuration called Android Virtual Device (AVD). AVD can be thought of as a set of configuration files that specify different Android software and device hardware capabilities. The Android Emulator uses these AVD configurations to configure and start the appropriate Android virtual image on the emulator.

As documented on the Android Web site (http://developer.android.com/guide/developing/devices/index.html), a typical AVD configuration has

•  A hardware profile that specifies all the device capabilities (examples: camera, sensors).
•  A System image, which will be used by the emulator for this AVD (API level to target, such as Gingerbread or Honeycomb).
•  A Data image that acts as the dedicated storage space for user’s data, settings, and SD card.
•  Other options including emulator skin, the screen dimensions, and SD card size.

Developers are encouraged to target different API levels, screen sizes, and hardware capabilities (such as camera, sensors, and multitouch). The AVD configuration can be used to customize the emulator as needed. Developers can create as many AVDs as desired, each one targeting a different Intel architecture–based Android device: for example, a developer can create an Intel architecture–based Gingerbread AVD with a built-in skin like WVGA800, or a custom one manually specifying the screen resolution to be used.   

The Android SDK has supported Intel architecture–based Android Emulation since version r12. The SDK integrates this support into all developer tools including the eclipse ADT plugin. Figure 5.6 is a sample screenshot of the Android Emulator for x86 running Gingerbread. The model number is highlighted, and shows “Full Android on x86 Emulator.”

Initialize the build env, as shown in Figure 5.7:

Use the lunch command to configure the build for building the x86 SDK, as shown in Figure 5.8. This will build the emulator images for x86, along with other SDK modules.

Finally, issue the make command make sdk to kick off the build, as shown in Figure 5.9.

Additionally, you can specify the number of parallel jobs for make using the –j parameter, to speed up the build process. (It is recommended that you use a value that is at least equal to or greater than the total number of CPUs in the system.)

The build will create three images, including the QEMU Android kernel image:t system.img (Android), userdata.img, and ramdisk.img.

When the build completes, the images will be in the build folder $ANDROID_BUILD_TOP/out/target/product/generic_x86/ - as shown in Figure 5.10.

The Android kernel image for QEMU (kernel-qemu) comes with Android Sources. It is located under the prebuilt folder ($ANDROID_BUILD_TOP/prebuilt/android-x86/kernel), as shown in Figure 5.11.

You now have all the image files required for running an x86 Android Gingerbread image on the Android x86 Emulator. The image files will need to be set up with the SDK, which will be covered in next section.

12. Setting Up the SDK to USe x86 Emulator Images

The Android SDK tools (android, the AVD manager) expect the x86 emulator images to be present in the default SDK folders for platform images /platforms/android-10/images.

The screenshots in the following figures assume the $ANDROID_SDK_TOP environment variable is set to the location of the Android SDK installation folder.

As in Figure 5.12, by default, Android-10 comes with emulator images for ARM. In order to set up the x86 emulator images in the SDK, you need to create an x86 folder and copy the images you build into the folder. You can also move the ARM images to their own folder as shown in Figure 5.13.

Figure 5.14 shows instructions for the x86 folder.

The final images folder of the Android-10 platform is shown in Figure 5.15.

Before using the Gingerbread Intel architecture images with the x86 Emulator, you must create an AVD configuration that specifies the required software and hardware customizations. More detailed information about AVDs can be found below, and in the Intel Developer Zone article “Android* Virtual Device Emulation for Intel® Architecture.”

At this point, your emulator and x86 image are ready to use. Please note that the emulator performance will see drastic improvements if you use Intel Hardware Acceleration Execution Manager (Intel HAXM) in conjunction with this system image—without it, performance may vary. (Intel HAXM requires an Intel processor with Intel VT-x support. For more information about Intel HAXM, visit http://int-software.intel.com/en-us/android.)

It is now time to use the Gingerbread x86 emulator to emulate an x86 image.

Open the Android tool or bring up the AVD creation tool directly from Eclipse.

Figure 5.16 and Figure 5.17 show the creation of an AVD for Gingerbread with an Intel® Atom™ (x86) CPU.

Figure 5.17 Success dialog box

Test the x86 Gingerbread AVD by selecting the AVD and clicking on Start, as shown in Figure 5.18.

Figure 5.19 shows the home screen of the Gingerbread for Intel Atom (x86) on emulator-x86.

Figure 5.20 shows the About Phone view of the settings. 

It is recommended that you use the x86 emulator with Intel® VT hardware acceleration. On Linux, this can be done using the Linux KVM. Ubuntu has further documentation on how to configure and use it: https://help.ubuntu.com/community/KVM. 

With KVM, shown in Figure 5.21, (-enable-kvm) users will likely notice performance boosts during Android boot along with quicker emulator responsiveness.

 13. Sample Gingerbread Feature: Battery Usage Stats

About Phone there is a Battery Use section. Battery stats will vary based on the emulation device and build. In the case where the developer can telnet into the emulated device, some simple commands can be used to mock battery drain. Take a look at one such example: http://android-er.blogspot.com/2010/09/how-to-set-battery-status-of-android.html.

14. Sample Gingerbread Feature: Task Manager

In Settings > Applications > Running Services, there is a Running tab, which shows what’s currently running, as shown in Figure 5.22.

For example, the developer can close Settings process by clicking on the item and selecting Stop.

15. Sample Gingerbread Feature: Cut and Paste Text

Opening the Messaging application and choosing New Message allows the user to type a message as if sending an SMS. By clicking in the text field and typing on the host keyboard, characters appear seamlessly on the Android screen. After typing “Hello 2.3.5!” the screen looks like Figure 5.23.

By dragging the mouse into the text field where “Hello 2.3.5!” is found and holding down the mouse button (or touchpad button) for about 2 seconds, a tool tip menu appears to Edit Text. Choosing, Select all and then repeating the mouse operation, the user sees the option to cut the text. After cutting text, repeating the mouse operation once again allows the user to paste back the text.

16. Ice Cream Sandwich Emulation

The x86 Android 4.0.4 emulator system image enables you to run an emulation of Android Ice Cream Sandwich on your development machine. In combination with the Android SDK, you can test out your Android applications on a virtual Android device based on Intel architecture (x86).

In order to install the emulator system image, you can use the Android SDK Manager (recommended method), or you can download the binary zip file and unzip and copy the included directory into the add-ons directory of your Android SDK installation. (Note that this method does not allow for automatic updates of the add-on).

17. Installation Guide

The following section will provide a guide for ICS image installation.

17.1 Prerequisites

The Android x86 Emulator Image requires the Android SDK to be installed. For instructions on installing and configuring the Android SDK, refer to the Android developer website (http://developer.android.com/sdk/).

Optional: The x86 Emulator Image for Android can be accelerated using Intel® Hardware Accelerated Execution Manager (Intel HAXM). For more information, please refer to the chapter on Intel HAXM.

17.2 Downloading through the Android SDK Manager

1.     Start the Android SDK Manager.

2.     Under Android 4.0.4 (some screenshots may refer to older versions), select Intel x86 Atom System Image, as shown in Figure 5.24.

1.     Once selected, click the Install Package button.

2.     Review the Intel Corporation license agreement. If you accept the terms, select Accept and click Install.

3.     The SDK Manager will download and extract the system image to the appropriate location within the Android SDK directory.

17.3 Using the System Image

1.     Start the Android AVD Manager and create a new AVD, setting Target to Android 4.0.X, and CPU/ABI to Intel Atom (x86), as shown in Figure 5.25.

Note: if the Intel Atom (x86) CPU/ABI option is not available, please make sure that the system image is installed correctly.

1.     Click the Create AVD button.

2.     The AVD has been successfully created and is now ready to use, as shown in Figure 5.26.

17.4 Downloading Manually

1.     Go to http://www.intel.com/software/android.

2.     Download the Intel x86 Atom System Image (found under the Tools and Downloads tab).

3.     Navigate to the directory containing the Android SDK, as shown in Figure 5.27.

1.     The system-images directory contains Android system images, separated by architecture, as shown in Figure 5.28.

1.     Expand android-15 (this directory contains API Level 15 system images), shown in Figure 5.29.

1.     Extract the x86 directory contained in the downloaded system image archive directly into the android-15 directory.

2.     The directory structure should now look like Figure 5.30.

1.     The system image is now installed and ready to be used.

17.5 CPU Acceleration

The performance of Intel Atom x86 Image for Android Ice Cream Sandwich can be improved using hardware-based virtualization using Intel VT-x technology.

If your computer has an Intel processor with VT-x support, it is recommended that Intel Hardware Acceleration Execution Manager (Intel HAXM) be used in conjunction with this system image. For more information about Intel HAXM, visit http://int-software.intel.com/en-us/android.

Note: Intel HAXM is for Windows and OS X operating systems only. For Linux hosts, Kernel-based Virtual Machine (KVM) can be used to accelerate emulation performance. For information on installing and configuring KVM on Ubuntu, refer to the following guide: https://help.ubuntu.com/community/KVM/Installation.

17.6 GPU Acceleration

The Intel Atom x86 Image for Android Ice Cream Sandwich can make use of hardware GPU features to increase the performance of games, graphics-intensive programs, and user interface elements.

Note: The functionality and performance of GPU acceleration is highly dependent on your computer’s graphics card and graphics drivers.

To use hardware GPU acceleration, perform the following steps:

1.     Open the Android AVD Manager.

2.     Select the AVD, and click Edit.

3.     The AVD editor window will appear. In the Hardware section, click New, as shown in Figure 5.31.

1.     In the Property dropdown box, select GPU Emulation, as shown in Figure 5.32.

1.     Click OK.

2.     After the GPU Emulation property has been added, change the Value to yes, as shown in Figure 5.33.

1.     Click Edit AVD to save the AVD.

2.     After the AVD has been modified, a dialog box will appear confirming the AVD settings, shown in Figure 5.34.

In the confirmation dialog box, the hw.gpu.enabled=yes line indicates that GPU acceleration is enabled for that particular AVD.

Note: The GPU acceleration must be enabled on a per-AVD basis.

1. Sistemas operativos compatibles

Se admiten los siguientes sistemas operativos:

• Windows XP* (32 bits), Vista* (32 o 64 bits) o Windows 7* (32 o 64 bits)
• Mac OSX* (32 o 64 bits)
• Linux* (Ubuntu, Fedora); GNU C Library (glibc) 2.7 o superior.
• En Linux Ubuntu, se requiere versión 8.04 o superior.
• En Fedora, las versiones de destino son la F-12 y superiores.
• Las distribuciones de 64 bits deben ser capaces de ejecutar aplicaciones de 32 bits.

2. Requisitos de hardware

El SDK de Android* requiere espacio en disco para todos los componentes que elija instalar. Se necesita espacio adicional en disco para ejecutar el emulador, por ejemplo, con el fin de crear tarjetas SD para los dispositivos virtuales de Android* (AVD).

3. Instalación del JDK

El SDK requiere, como mínimo, Java* JDK 5 o JDK 6. También admite JDK 7. No es suficiente con el JRE (Java Runtime Environment) solamente. Si su sistema no tiene instalado JDK 5, 6 o 7, puede descargar JDK SE 7 de http://www.oracle.com/technetwork/java/javase/downloads/index.html e instalarlo en su equipo.

4. Instalación de Eclipse*

Se recomienda firmemente instalar el SDK con Eclipse* para desarrollar aplicaciones Android. Vaya a http://www.eclipse.org/downloads/ para descargar o actualizar Eclipse. Sugerimos usar las siguientes configuraciones de Eclipse si se desea desarrollar aplicaciones Android para la arquitectura Intel:

• Eclipse 3.5 (Galileo) o superior
• Eclipse Classic (versiones 3.5.1 y superiores)
• Android Development Tools Plugin (recomendado)

5. Instalación de Apache Ant (opcional)

Se recomienda firmemente usar un entorno de desarrollo integrado, como Eclipse, para desarrollar aplicaciones Android. Pero, como alternativa, se puede usar Apache Ant para trabajar con el SDK a fin de crear aplicaciones Android. Visite http://ant.apache.org/ para descargar las distribuciones binarias e instalar Ant. Si se quiere trabajar con el SDK, se necesita Ant 1.8 o superior.

6. Descarga del SDK Starter Package y cómo agregar los componentes del SDK

El SDK Starter Package se puede descargar de la página http://developer.android.com/sdk/index.html. Este paquete no incluye los componentes específicos de la plataforma necesarios para desarrollar aplicaciones Android. Sólo proporciona las herramientas básicas del SDK. Usted debe descargar el resto de los componentes de la plataforma
Después de instalar el SDK Starter Package, ejecute Android SDK and AVD Manager.

• En Windows*, seleccione Inicio > Todos los programas > Android SDK Tools > SDK Manager
• En Linux, ejecute asdk/tools/android, donde asdk representa el nombre de su directorio de Android SDK

En el panel izquierdo del cuadro de diálogo Android* SDK and AVD Manager, seleccione Available packages; en el panel derecho, haga clic y expanda el nodo Android Repository, y seleccione los paquetes que desee instalar, como se muestra en la Figura 5.1.
Para tener en cuenta: es posible que se muestre un mensaje de error si intenta descargar desde detrás de un firewall. Si esto ocurre, vuelva a intentarlo desde fuera del firewall.
Si sigue viendo el mensaje de error, cierre el SDK Manager, haga clic con el botón derecho en el menú Inicio y seleccione Ejecutar como administrador. Estos dos pasos resuelven la mayoría de los mensajes de error que puedan aparecer mientras intenta realizar la descarga.

7. Cómo configurar Eclipse para que funcione con el SDK

Si usa el entorno de desarrollo integrado (IDE) de Eclipse* para desarrollar software, recomendamos firmemente que instale y configure el complemento Android Development Tool (ADT) Plugin.

7.1 Instalación del ADT Plugin para Eclipse

Los siguientes son los pasos de instalación del ADT Plugin para Eclipse:

Figura 5.2Cuadro de diálogo Add Repository

1. Inicie Eclipse, seleccione Help > Install New Software en el cuadro de diálogo Install, y haga clic en el botón Add.
2. En el cuadro de diálogo Add Repository, escriba ADT Plugin en el campo Name e ingrese https://dl-ssl.google.com/android/eclipse/ en el campo Location, como se muestra en la Figura 5.2, y luego haga clic en OK.
3. Regresará al cuadro de diálogo Install, se conectará con el servidor de repositorio de Google y mostrará los paquetes de ADT disponibles, como se muestra en la Figura 5.3.

   
   Figura 5.3Lista de paquetes de ADT

4. Seleccione Next, acepte el acuerdo de licencia y seleccione Finish.
5. Reinicie Eclipse.

7.2 Configuración del ADT Plugin

Para configurar el ADT Plugin, siga estos pasos:

1. Inicie Eclipse y seleccione Windows > Preferences
2. En el panel izquierdo del cuadro de diálogo Preferences, seleccione Android. En el panel derecho, use el botón Browse para navegar al directorio en el que instaló Android* SDK y haga clic en Apply. Aparecerá una lista de destinos del SDK que usted ha instalado. En este momento, haga clic en OK.

Figura 5.4 Cuadro de diálogo Preferences

Después de seguir los pasos descritos más arriba, tendrá a disposición las herramientas necesarias para iniciar el desarrollo de Android para la arquitectura Intel. Ahora tiene todo lo que necesita para escribir su primera aplicación, pero quizá sería mejor instalar también el Emulador de Arquitectura Intel® (x86) en este momento, para poder probar la aplicación ni bien esté lista. En la siguiente sección se mostrará la instalación del Emulador de Arquitectura Intel® (x86). Analizaremos la creación de una imagen de emulador con recursos AOSP y la emulación de las imágenes de sistema resultantes para x86. También se verán algunas nuevas prestaciones incluidas en Gingerbread* y Ice Cream Sandwich*.

Información general sobre la emulación de Android Virtual Device

Android funciona en dispositivos con diversos factores de forma y diferentes tamaños de pantalla, funcionalidades de hardware y prestaciones. Un dispositivo característico tiene muchas funcionalidades de software (API de Android) y hardware, tales como sensores, GPS, cámara, tarjeta SD y pantalla multitáctil de dimensiones específicas.

El emulador es bastante flexible y es posible configurarlo con diferentes opciones de configuración de software y hardware. Los desarrolladores pueden configurar el emulador con la configuración denominada Dispositivo Virtual de Android (AVD). Se podría pensar en el AVD como un conjunto de archivos de configuración que especifican diferentes funcionalidades de software de Android y hardware del dispositivo. El emulador de Android usa estas configuraciones de AVD para configurar e iniciar en el emulador la imagen virtual de Android apropiada.

Como se documenta en el sitio web de Android (http://developer.android.com/guide/developing/devices/index.html), una configuración de AVD típica tiene:

• Un perfil de hardware que especifica todas las funcionalidades del dispositivo (ejemplos: cámara, sensores).
• Una imagen del Sistema, que el emulador usará para este AVD (nivel de API de destino, tales como Gingerbread o Honeycomb).
• Una imagen de Datos que actúa como espacio de almacenamiento dedicado para los datos del usuario, las configuraciones y la tarjeta SD.
• Otras opciones, incluidas la piel del emulador, las dimensiones de la pantalla y el tamaño de la tarjeta SD.

Se alienta a los desarrolladores a apuntar a diferentes niveles de API, tamaños de pantalla y funcionalidades de hardware (como cámara, sensores y pantalla multitáctil). Es posible usar la configuración de AVD para personalizar el emulador según sea necesario. Los desarrolladores pueden crear tantos AVD como lo deseen, con cada uno apuntando a un dispositivo Android basado en arquitectura Intel diferente: por ejemplo, un desarrollador puede crear un AVD de Gingerbread basado en arquitectura Intel con una piel integrada, como WVGA800, o una personalizada para la cual se especificaría en forma manual la resolución de pantalla que se utilizará.

El SDK de Android ha admitido la emulación de Android basado en arquitectura Intel desde la versión r12. El SDK integra esta compatibilidad en todas las herramientas para desarrolladores, incluido el complemento ADT. La Figura 5.6 es una captura de pantalla de muestra del emulador de Android para x86 ejecutando Gingerbread. El número de modelo está resaltado y muestra “Full Android on x86 Emulator”.

Figura 5.5Emulador de Android

En la siguiente documentación de Android, encontrará información detallada sobre cómo usar el emulador: http://developer.android.com/guide/developing/devices/emulator.html.

9. ¿Qué emulador debería usar?

Al momento de escribir este artículo, hay dos imágenes de emulador disponibles para la arquitectura Intel (x86): una para Android 2.3.7 (Gingerbread) y una para Android 4.0.4 (Ice Cream Sandwich).

Si bien tiene muchas ventajas desarrollar para la versión de sistema operativo Android más reciente, muchos desarrolladores prefieren hacerlo para Android 2.x, ya que la mayoría de los teléfonos que están en uso actualmente todavía no tienen Android 4.x o superior (en los EE. UU., sólo 1 de cada 5 teléfonos Android tiene ICS o superior al momento de escribir este artículo). Este porcentaje cambiará con el tiempo, así que se sugiere firmemente tener presentes las condiciones del mercado al momento de determinar el sistema operativo de destino.

El siguiente artículo puede ser útil para obtener más información del sistema operativo específica de Gingerbread: http://blogs.computerworld.com/17479/android_gingerbread_faq.

Para Ice Cream Sandwich, se recomienda este otro: http://www.computerworld.com/s/article/9230152/Android_4.0_The_ultimate_guide_plus_cheat_sheet_.

10. Razones para usar el emulador

En primer lugar, es gratis. El SDK de Android y sus complementos de terceros no cuestan nada y posibilitan a los desarrolladores emular dispositivos que no poseen y a los que quizá no tengan acceso. Esto es importante porque no todos los teléfonos reciben las versiones del sistema operativo Android mediante actualizaciones por aire (Over The Air, OTA) y podría no ser factible para los desarrolladores comprar todos los dispositivos que se espera que admitan sus paquetes de software.

Desarrollo y prueba. Los desarrolladores pueden crear con el SDK varias configuraciones de dispositivo virtual de Android* (AVD) para fines de desarrollo y prueba. Cada AVD puede tener diferentes dimensiones de pantalla, tamaños de tarjeta SD o incluso versiones del SDK de Android (lo cual es útil para probar la compatibilidad con versiones anteriores de Android).

Jugar con una nueva versión. El emulador permite a los desarrolladores entretenerse con nuevas versiones de Android y aprender más acerca de ellas.

Veamos ahora paso a paso cómo crear y ejecutar una imagen de emulador en una compilación x86. Por una cuestión de simplicidad, en esta sección se hará referencia al emulador de Gingerbread, aunque la mayor parte del contenido se aplica también al emulador de Ice Cream Sandwich.

11 Creación de una imagen de emulador

El primer paso será seguir las instrucciones de configuración que se indican aquí: http://source.android.com/source/initializing.html.

Google* ha puesto a disponibilidad fuentes de Gingerbread en un nuevo lugar. La documentación de http://source.android.com/source/downloading.html se ha actualizado para reflejar estos cambios.

Actualmente, las instrucciones de inicialización de repositorio predeterminadas son sólo para obtener la rama maestra o una rama específica, como cuando se usa el comando android-2.3.7_r1. Las instrucciones de repositorio y rama para crear imágenes de emulador x86 de Gingerbread no se han dado.

Utilice la rama con la etiqueta gingerbread para descargar la rama de origen de Android más reciente, como se muestra en la Figura 5.6. Esta rama tiene los archivos y los módulos necesarios para crear imágenes del emulador x86 del SDK.

Figura 5.6 Rama de Gingerbread

Inicialice la compilación env, como se muestra en la Figura 5.7:

Figura 5.7 Inicialización

Configure con el comando lunch la compilación para crear el SDK x86, como se muestra en la Figura 5.8. Esto creará las imágenes de emulador para x86, junto con otros módulos del SDK.

Figura 5.8 Comando lunch

Por último, utilice el comando make sdk para iniciar la compilación, como se muestra en la Figura 5.9.

Figura 5.9 Comando make sdk

Además, se puede configurar la cantidad específica de trabajos paralelos para make con el parámetro –j, para acelerar el proceso de compilación (se recomienda usar un valor que sea mayor o igual a la cantidad total de CPU del sistema.)

Se crearán tres imágenes: QEMU Android kernel image:t system.img (Android), userdata.img y ramdisk.img.

Como se muestra en la Figura 5.10, cuando la compilación se complete, las imágenes quedarán en la carpeta de compilación $ANDROID_BUILD_TOP/out/target/product/generic_x86/

Figura 5.10 Ubicación de las imágenes

La imagen del kernel de Android para QEMU (kernel-qemu) viene con Android Sources. Está ubicado en la carpeta prebuilt ($ANDROID_BUILD_TOP/prebuilt/android-x86/kernel), como se observa en la Figura 5.11.

Figura 5.11 Imagen del kernel

Ahora ya tiene todos los archivos necesarios para ejecutar una imagen x86 de Android Gingerbread en el emulador x86 de Android. Habrá que configurar los archivos de imagen con el SDK, proceso que se tratará en la próxima sección.

12. Cómo configurar el SDK para usar imágenes del emulador x86

Las herramientas del SDK de Android (android, el administrador de AVD) esperan que las imágenes del emulador x86 se encuentren en las carpetas predeterminadas del SDK para imágenes de plataformas /platforms/android-10/images.

En las capturas de pantalla de las figuras siguientes se da por supuesto que la variable de entorno $ANDROID_SDK_TOP está establecida según la ubicación de la carpeta de instalación del SDK de Android.

Figura 5.12 Ubicación de las imágenes

Como se ve en la Figura 5.12, Android-10 viene en forma predeterminada con imágenes de emulador para ARM. Para configurar las imágenes del emulador x86 en el SDK, es necesario crear una carpeta x86 y copiar a la carpeta las imágenes creadas. También puede mover las imágenes de ARM a su propia carpeta, como se muestra en la Figura 5.13.

Figura 5.13 Carpeta ARM

En la Figura 5.14 se muestran instrucciones para la carpeta x86.

Figura 5.14 Instrucciones para x86

En la Figura 5.15, se muestra la última carpeta de imágenes de la plataforma Android-10.

Figura 5.15 Última carpeta de imágenes

Antes de usar imágenes de arquitectura Intel de Gingerbread con el emulador x86, debe crear una configuración de AVD que especifique las personalizaciones necesarias de software y hardware. Más abajo se puede encontrar información detallada sobre los AVD; también en el artículo “Android* Virtual Device Emulation for Intel® Architecture” (“Emulación de dispositivo virtual de Android para Arquitectura Intel®”) de la Zona de Desarrolladores Intel.

Ya aquí el emulador y la imagen x86 están listos para usarse. Tenga en cuenta que el rendimiento del emulador tendrá mejoras drásticas si usa el Supervisor de Ejecución Acelerada por Hardware Intel (Intel HAXM) junto con esta imagen de sistema. (Intel HAXM requiere un procesador Intel compatible con Intel VT-x. Para obtener más información acerca de Intel HAXM, visite http://int-software.intel.com/en-us/android).

Ahora es momento de usar el emulador x86 de Gingerbread para emular una imagen x86.

Abra la herramienta de Android o use la herramienta de creación de AVD directamente desde Eclipse.

La Figura 5.16 y la Figura 5.17 muestran la creación de un AVD para Gingerbread con una CPU Intel® Atom™ (x86).

Figura 5.16 Creación de un nuevo AVD

Figura 5.17 Cuadro de diálogo de creación exitosa

Pruebe el AVD Gingerbread x86; para ello, seleccione el AVD y haga clic en Start, como se muestra en la Figura 5.18.

Figura 5.18 Opciones de inicio

En la Figura 5.19 se muestra la pantalla principal de Gingerbread para Intel Atom (x86) en el emulador x86.

Figura 5.19 Pantalla principal

En la Figura 5.20 se muestra la vista de las configuraciones desde About Phone (Acerca del teléfono).

Figura 5.20 Vista desde “About phone”

Se recomienda que use el emulador x86 con aceleración de hardware de Intel® VT. Para hacer esto en Linux, se puede usar la KVM de Linux. Ubuntu tiene más documentación sobre cómo configurarla y usarla: https://help.ubuntu.com/community/KVM.

Figura 5.21 KVM

Con la KVM, que se muestra en la Figura 5.21, (-enable-kvm) es probable que los usuarios noten mejoras de rendimiento durante el inicio de Android y que el emulador responde con mayor rapidez.

13. Ejemplo de prestación de Gingerbread: estadísticas de uso de batería

En About Phone hay una sección de uso de batería, Battery Use. Las estadísticas de utilización de la batería varían según el dispositivo de emulación y la versión. En el caso de que el desarrollador pueda ingresar en el dispositivo emulado mediante telnet, hay algunos comandos simples que se pueden usar para imitar el consumo de batería. Mire en esta página un ejemplo: http://android-er.blogspot.com/2010/09/how-to-set-battery-status-of-android.html.

14. Ejemplo de prestación de Gingerbread: administrador de tareas

En Settings > Applications > Running Services, hay una pestaña Running que muestra los procesos y servicios en ejecución, como se muestra en la Figura 5.22.

Figura 5.22 El administrador de tareas

15. Ejemplo de prestación de Gingerbread: copiar y pegar texto

Si se abre la aplicación de mensajería y se elige enviar un nuevo mensaje, el usuario puede escribir un mensaje como si enviara un SMS. Si se hace clic en el campo de texto y se escribe en el teclado del host, los caracteres aparecen con fluidez en la pantalla de Android. Después de escribir “Hello 2.3.5!”, la pantalla se ve como en la Figura 5.23.

Figura 5.23Diversión con mensajes de texto

Si se mueve el mouse al campo de texto donde está el mensaje “Hello 2.3.5!” y se mantiene apretado el botón del mouse (o del panel táctil) durante unos 2 segundos, aparece un menú para editar texto: Edit Text. Al elegir Select all y luego repetir la operación con el mouse, el usuario ve la opción de cortar el texto. Después de cortar el texto, si se vuelve a repetir la operación con el mouse, el usuario puede pegar el texto en su lugar original.

16. Emulación de Ice Cream Sandwich

La imagen de sistema del emulador x86 de Android 4.0.4 permite ejecutar una emulación de Android Ice Cream Sandwich en la máquina de desarrollo. Además del SDK de Android, las aplicaciones para Android se pueden probar en un dispositivo virtual de Android basado en la arquitectura Intel (x86).

Para instalar la imagen de sistema del emulador, una opción es usar el Android SDK Manager (método recomendado), pero también se puede descargar el archivo zip binario y copiar el directorio incluido al directorio de complementos de su instalación del SDK de Android (este último método no admite actualizaciones automáticas del complemento).

17. Guía de instalación

La siguiente sección es una guía para instalar imágenes de ICS.

17.1 Prerrequisitos

La imagen de emulador x86 para Android necesita que esté instalado el SDK de Android. Para obtener instrucciones de instalación y configuración del SDK de Android, consulte el sitio web para desarrolladores de Android (http://developer.android.com/sdk/).

Opcional: la imagen de emulador x86 para Android se puede acelerar con el Supervisor de Ejecución Acelerada por Hardware Intel® (Intel HAXM). Encontrará más información en el capítulo sobre Intel HAXM.

17.2 Cómo hacer descargas por medio del Android SDK Manager

1. Inicie el Android SDK Manager.
2. Bajo Android 4.0.4 (puede que algunas capturas de pantalla hagan referencia a versiones anteriores), seleccione la imagen de sistema Intel x86 Atom System Image, como se muestra en la Figura 5.24.
   
   Figura 5.24 Imagen de sistema Intel x86 Atom
3. Una vez instalada, haga clic en el botón de instalación Install Package.
4. Lea el acuerdo de licencia de Intel Corporation. Si acepta los términos, seleccione Accept y haga clic en Install.
5. El SDK Manager descargará y extraerá la imagen de sistema al lugar apropiado dentro del directorio del SDK de Android.

17.3 Uso de la imagen de sistema

1. Inicie el Android AVD Manager y cree un nuevo AVD (establezca el destino Target como Android 4.0.X, y CPU/ABI como Intel Atom (x86), tal cual se muestra en la Figura 5.25).
   
   Figura 5.25 Configuración del destino
    
   Nota: si no está disponible la opción Intel Atom (x86) para CPU/ABI, asegúrese de que la imagen de sistema se instale correctamente.
2. Haga clic en el botón Create AVD.
3. El AVD ya se ha creado y está listo para usarse, como se muestra en la Figura 5.26.
   
   Figura 5.26Imagen lista

17.4 Descarga manual

1. Vaya a http://www.intel.com/software/android
2. Descargue la imagen de sistema Intel x86 Atom System Image (bajo la pestaña Tools & Downloads).
3. Vaya al directorio que contiene el SDK de Android, como se muestra en la Figura 5.27.
   
   Figura 5.27 Directorio del SDK de Android
4. El directorio system-images contiene imágenes de sistema de Android, separadas por arquitectura, como se muestra en la Figura 5.28.
   
   Figura 5.28 Imágenes separadas
5. Expanda android-15 (este directorio contiene imágenes de sistema de nivel 15 de API), como se ve en la Figura 5.29.
   
   Figura 5.29 Nivel 15 de API
6. Extraiga el directorio x86, contenido en el archivo de imagen de sistema descargado, directamente en el directorio android-15.
7. La estructura del directorio debería verse ahora como en la Figura 5.30.
   
   Figura 5.30 Estructura esperada
8. La imagen del sistema ya está instalada y lista para usar.

17.5 Aceleración de la CPU

El rendimiento de la imagen Intel Atom x86 para Android Ice Cream Sandwich se puede mejorar mediante virtualización basada en hardware con tecnología Intel.

Si su computadora tiene un procesador Intel compatible con VT-x, se recomienda usar el Supervisor de Ejecución Acelerada por Hardware Intel (Intel HAXM) junto con esta imagen de sistema. Para obtener más información acerca de Intel HAXM, visite http://int-software.intel.com/en-us/android.

Nota: Intel HAXM es sólo para los sistemas operativos Windows y OS X. En el caso de hosts Linux, se puede usar la máquina virtual basada en kernel (KVM) para acelerar la emulación. En la siguiente guía encontrará información sobre la instalación y configuración de KVM en Ubuntu: https://help.ubuntu.com/community/KVM/Installation.

17.6 Aceleración de la GPU

La imagen Intel Atom x86 para Android Ice Cream Sandwich puede aprovechar las prestaciones de GPU de hardware para mejorar el rendimiento de juegos, de programas que hagan un uso intensivo de gráficos y de elementos de la interfaz de usuario.

Nota: la funcionalidad y el rendimiento de la aceleración de la GPU depende en gran medida de la tarjeta gráfica y los controladores de gráficos de su equipo.

Para usar la aceleración de GPU de hardware, siga estos pasos:

1. Abra el Android SDK Manager.
2. Seleccione el AVD y haga clic en Edit.
3. Aparecerá la ventana del editor de AVD. En la sección Hardware, haga clic en New, como se muestra en la Figura 5.31.
   
   Figure 5.31 Sección “Hardware”
4. En la lista desplegable Property, seleccione GPU Emulation, como se observa en la Figura 5.32.
   
   Figura 5.32 Emulación de GPU
5. Haga clic en OK.
6. Después de haber agregado la propiedad GPU emulation, cambie el valor (Value) a yes, como en la Figura 5.33.
   
   Figura 5.33 Valor cambiado a “yes”
7. Haga clic en Edit AVD para guardar el AVD.
8. Después de que se haya modificado el AVD, aparecerá un cuadro de diálogo con la confirmación de la configuración del AVD. Este cuadro se muestra en la Figura 5.34.
   
   Figura 5.34 Cuadro de diálogo de confirmación

En el cuadro de diálogo de confirmación, la línea hw.gpu.enabled=yes indica que la aceleración de la GPU está habilitada para ese AVD en particular.

Nota: la aceleración de la GPU se debe habilitar para cada AVD.

1. Sensores en tabletas Android con procesador Intel® Atom™

Las tabletas basadas en procesadores Intel Atom admiten una amplia variedad de sensores de hardware. Estos sensores se usan para detectar el movimiento y los cambios de posición, e informar los parámetros de entorno del ambiente. El diagrama de bloques de la Figura 1 muestra una posible configuración de sensores en una tableta Android basada en procesador Intel Atom típica.

Sobre la base de los datos que informan, podemos clasificar los sensores en las clases y tipos que se muestran más abajo, en la Tabla 4.1.

Tabla 4.1    Tipos de sensores que admite la plataforma Android

Marco de trabajo de sensores en Android

El marco de trabajo de sensores en Android proporciona mecanismos que permiten acceder a los sensores y sus datos, con la excepción del GPS, al que se accede mediante los servicios de localización de Android. Esto lo analizaremos más adelante en este mismo capítulo. El marco de trabajo de sensores forma parte del paquete android.hardware. En la Tabla 4.2 se incluye una lista de las clases e interfaces principales en las que consiste el marco de trabajo de sensores.

Tabla 4.2    Marco de trabajo de sensores en la plataforma Android

2.1 Cómo obtener la configuración del sensor

Es decisión exclusiva del fabricante qué sensores estarán disponibles en el dispositivo. Es posible usar el marco de trabajo de sensores para descubrir cuáles son los sensores disponibles en el tiempo de ejecución; pare eso se debe invocar el método getSensorList() de SensorManager con el parámetro “Sensor.TYPE_ALL”. El Ejemplo de código 1 muestra en un fragmento una lista de sensores disponibles y el vendedor, la potencia y la precisión de la información de cada sensor.

package com.intel.deviceinfo;      
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map; 	 
import android.app.Fragment;
import android.content.Context;
import android.hardware.Sensor;
import android.hardware.SensorManager;
import android.os.Bundle;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;
import android.widget.AdapterView;
import android.widget.AdapterView.OnItemClickListener;
import android.widget.ListView;
import android.widget.SimpleAdapter; 
	 
public class SensorInfoFragment extends Fragment {  
    private View mContentView;  
    private ListView mSensorInfoList;     
    SimpleAdapter mSensorInfoListAdapter;
    private List<Sensor> mSensorList; 
 
    private SensorManager mSensorManager;  
    @Override
    public void onActivityCreated(Bundle savedInstanceState) {
        super.onActivityCreated(savedInstanceState);
    }
    @Override
    public void onPause() 
    { 
        super.onPause();
    }
    @Override
    public void onResume() 
    {
        super.onResume();
    }
    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container,
            Bundle savedInstanceState) {
        mContentView = inflater.inflate(R.layout.content_sensorinfo_main, null);
        mContentView.setDrawingCacheEnabled(false);
        mSensorManager = (SensorManager)getActivity().getSystemService(Context.SENSOR_SERVICE);
        mSensorInfoList = (ListView)mContentView.findViewById(R.id.listSensorInfo);
        mSensorInfoList.setOnItemClickListener( new OnItemClickListener() {
            @Override
            public void onItemClick(AdapterView<?> arg0, View view, int index, long arg3) {
                // with the index, figure out what sensor was pressed
                Sensor sensor = mSensorList.get(index);
                // pass the sensor to the dialog.
                SensorDialog dialog = new SensorDialog(getActivity(), sensor);
                dialog.setContentView(R.layout.sensor_display);
                dialog.setTitle("Sensor Data");
                dialog.show();
            }
        });            
        return mContentView;
    }      
    void updateContent(int category, int position) {
        mSensorInfoListAdapter = new SimpleAdapter(getActivity(), 
          getData() , android.R.layout.simple_list_item_2,
          new String[] {
              "NAME",
              "VALUE"
          },
          new int[] { android.R.id.text1, android.R.id.text2 });
      mSensorInfoList.setAdapter(mSensorInfoListAdapter);
    }
    protected void addItem(List<Map<String, String>> data, String name, String value)   {
        Map<String, String> temp = new HashMap<String, String>();
        temp.put("NAME", name);
        temp.put("VALUE", value);
        data.add(temp);
    }  
    private List<? extends Map<String, ?>> getData() {
        List<Map<String, String>> myData = new ArrayList<Map<String, String>>();
        mSensorList = mSensorManager.getSensorList(Sensor.TYPE_ALL);
        for (Sensor sensor : mSensorList ) {
            addItem(myData, sensor.getName(),  "Vendor: " + sensor.getVendor() + ", min. delay: " + sensor.getMinDelay() +", power while in use: " + sensor.getPower() + "mA, maximum range: " + sensor.getMaximumRange() + ", resolution: " + sensor.getResolution());
        }
        return myData;
    }
}

Ejemplo de código 1: Fragmento que muestra la lista de sensores**. Fuente: Intel Corporation, 2012

2.2 Sistema de coordenadas de sensores

El marco de trabajo de sensores comunica datos de sensores mediante el uso de un sistema de coordenadas estándar de 3 ejes, en el cual X, Y y Z están representadas por values[0], values[1] y values[2], respectivamente, en el objeto SensorEvent.

0 0 1 95 544 intel 4 1 638 14.0

Sensores tales como el de luz, el de temperatura y el de proximidad devuelven un solo valor. Para estos sensores sólo se usa values[0] en el objeto SensorEvent.

Otros sensores comunican datos en el sistema de coordenadas estándar de 3 ejes. La siguiente es una lista de esos sensores:

• Acelerómetro
• Sensor de gravedad
• Giroscopio
• Sensor de campo geomagnético

El sistema de coordenadas de sensores de 3 ejes se define con relación a la pantalla del dispositivo en su orientación natural (predeterminada). En el caso de las tabletas, la orientación natural es por lo general la horizontal, mientras que para los teléfonos es la vertical. Cuando se sostiene un dispositivo en su orientación natural, el eje x es horizontal y apunta a la derecha, el eje y es vertical y apunta hacia arriba y el eje z apunta hacia fuera de la pantalla. La Figura 4.2 muestra el sistema de coordenadas de sensores para una tableta.

Figura 4.2. Sistema de coordenadas de sensores
Fuente: Intel Corporation, 2012

La cuestión más importante que se debe tener en cuenta es que el sistema de coordenadas del sensor nunca cambia cuando el dispositivo se mueve o se modifica su orientación.

2.3 Eventos de sensor de monitorización

El marco de trabajo de sensores informa datos a los objetos SensorEvent. Para monitorizar los datos de un sensor específico, una clase puede implementar la interfaz SensorEventListener y registrarse en el SensorManager del sensor. El marco de trabajo informa a la clase acerca de los cambios de estado del sensor por medio de los siguientes dos métodos de devolución de llamada de SensorEventListener implementados por la clase:

onAccuracyChanged()
y
onSensorChanged()

En el Ejemplo de código 2 se implementa el SensorDialog utilizado en el ejemplo de SensorInfoFragment que vimos en la sección “Cómo obtener la configuración del sensor”.

package com.intel.deviceinfo;
  
import android.app.Dialog;
import android.content.Context;
import android.hardware.Sensor;
import android.hardware.SensorEvent;
import android.hardware.SensorEventListener;
import android.hardware.SensorManager;
import android.os.Bundle;
import android.widget.TextView;
  
public class SensorDialog extends Dialog implements SensorEventListener {
    Sensor mSensor;
    TextView mDataTxt;
    private SensorManager mSensorManager; 
       
  
    public SensorDialog(Context ctx, Sensor sensor) {
        this(ctx);
        mSensor = sensor;
    }
       
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        mDataTxt = (TextView) findViewById(R.id.sensorDataTxt);
        mDataTxt.setText("...");
        setTitle(mSensor.getName());
    }
       
    @Override
    protected void onStart() {
        super.onStart();
        mSensorManager.registerListener(this, mSensor,  SensorManager.SENSOR_DELAY_FASTEST);
    }
             
    @Override
    protected void onStop() {
        super.onStop();
        mSensorManager.unregisterListener(this, mSensor);
    }
  
    @Override
    public void onAccuracyChanged(Sensor sensor, int accuracy) {
    }
  
    @Override
    public void onSensorChanged(SensorEvent event) {
        if (event.sensor.getType() != mSensor.getType()) {
            return;
        }
        StringBuilder dataStrBuilder = new StringBuilder();
        if ((event.sensor.getType() == Sensor.TYPE_LIGHT)||
            (event.sensor.getType() == Sensor.TYPE_TEMPERATURE)) {
            dataStrBuilder.append(String.format("Data: %.3fn", event.values[0]));
        }
        else{         
            dataStrBuilder.append( 
                String.format("Data: %.3f, %.3f, %.3fn", 
                event.values[0], event.values[1], event.values[2] ));
        }
        mDataTxt.setText(dataStrBuilder.toString());
    }
}

Ejemplo de código 2: Diálogo que muestra los valores del sensor**

2.4 Sensores de movimiento

Los sensores de movimiento se usan para monitorizar el movimiento del dispositivo, ya sea agitación, giro, balanceo o inclinación. El acelerómetro y el giroscopio son dos sensores de movimiento de los cuales disponen muchas tabletas y teléfonos.

Los sensores de movimiento comunican datos en el sistema de coordenadas de sensores, en el cual los tres valores del objeto SensorEvent, values[0], values[1] y values[2], representan valores para los ejes x, y y z, respectivamente.

Para entender los sensores de movimiento y aplicar los datos en una aplicación, necesitamos usar algunas fórmulas físicas relacionadas con la fuerza, la masa, la aceleración, las leyes del movimiento de Newton y la relación entre varias de estas entidades a lo largo del tiempo. Aquel que desee conocer más acerca de estas fórmulas y relaciones puede consultar libros de texto de física o materiales de dominio público.

El acelerómetro mide la aceleración que se aplica al dispositivo.

Tabla 4.3    El acelerómetro        Fuente: Intel Corporation, 2012

El concepto del acelerómetro se deriva de la segunda ley del movimiento de Newton:
a = F/m

La aceleración de un objeto es el resultado de la fuerza neta que se aplica al objeto. Entre las fuerzas externas se incluye la que se aplica a todos los objetos de la Tierra: la gravedad. Es directamente proporcional a la fuerza neta F que se aplica al objeto e inversamente proporcional a la masa m del objeto.

En nuestro código, en lugar de usar en forma directa la ecuación de arriba, por lo general nos interesa el resultado que produce la aceleración en la velocidad y la posición del dispositivo durante un período de tiempo. La siguiente ecuación describe la relación entre la velocidad v1 de un objeto, su velocidad original v0, la aceleración a y el tiempo t:
v1 = v0 + at

Para calcular el desplazamiento s del objeto, usamos la ecuación siguiente:
s = v0t + (1/2)at²

En muchos casos, comenzamos con la condición v0 igual a 0 (antes de que el dispositivo comience a moverse), lo que simplifica la ecuación. Así queda:
s = at²/2

Debido a la gravedad, la aceleración gravitacional, que se representa con el símbolo g, se aplica a todo objeto que se encuentre en la Tierra. Esta magnitud es independiente de la masa del objeto. Sólo depende de la altura del objeto respecto del nivel del mar. Su valor varía entre 9,78 y 9,82 (m/s2). Adoptamos el valor estándar convencional de g:
g = 9,80665 (m/s2)

Como el acelerómetro devuelve los valores según un sistema de coordenadas multidimensional, en nuestro código podemos calcular las distancias a lo largo de los ejes x, y y z con las siguientes ecuaciones.

S_x = A_xT²/2

S_y=A_yT²/2

S_z=A_zT²/2

Donde S_x, S_y y S_z son los desplazamientos sobre el eje x, el eje y y el eje z, respectivamente, y A_x, A_y y A_z son las aceleraciones sobre los ejes x, y y z, respectivamente. T es el tiempo del período medido.

En el Ejemplo de código 3 se muestra cómo crear una instancia de acelerómetro.

public class SensorDialog extends Dialog implements SensorEventListener {
    ... 
    private Sensor mSensor;
    private SensorManager mSensorManager; 
       
    public SensorDialog(Context context) {
        super(context);
        mSensorManager = (SensorManager)context.getSystemService(Context.SENSOR_SERVICE);
        mSensor = mSensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER);
    ...
}

Ejemplo de código 3: Creación de una instancia de acelerómetro (**)
Fuente: Intel Corporation, 2012

A veces no usamos los valores de las tres dimensiones. También puede ocurrir que necesitemos tomar en cuenta la orientación del dispositivo. Por ejemplo, cuando desarrollamos una aplicación para un laberinto, sólo usamos la aceleración gravitacional en los ejes x e y para calcular las distancias y las direcciones de movimiento de la bola a partir de la orientación del dispositivo. El siguiente fragmento de código (Ejemplo de código 4) describe la lógica.

@Override
public void onSensorChanged(SensorEvent event) {
    if (event.sensor.getType() != Sensor.TYPE_ACCELEROMETER) {
        return;
    } 
float accelX, accelY;
...
//detect the current rotation currentRotation from its “natural orientation”
//using the WindowManager
    switch (currentRotation) {
        case Surface.ROTATION_0:
            accelX = event.values[0];
            accelY = event.values[1];
            break;
        case Surface.ROTATION_90:
            accelX = -event.values[0];
            accelY = event.values[1];
            break;
        case Surface.ROTATION_180:
            accelX = -event.values[0];
            accelY = -event.values[1];
            break;
        case Surface.ROTATION_270:
            accelX = event.values[0];
            accelY = -event.values[1];
            break;
    }
    //calculate the ball’s moving distances along x, and y using accelX, accelY and the time delta
        ...
    }
}

Ejemplo de código 4: Consideración de la orientación del dispositivo cuando se usan datos del acelerómetro en un juego de laberinto**
Fuente: Intel Corporation, 2012

El giroscopio mide la velocidad de rotación del dispositivo alrededor de los ejes x, y y z, como se muestra en la Tabla 4.4. Los valores de datos del giroscopio pueden ser positivos o negativos. Si se mira el origen desde una posición en el semieje positivo y si la rotación alrededor del eje es en sentido contrario al de las agujas del reloj, el valor es positivo; si la rotación es en el sentido de las agujas del reloj, el valor es negativo. También podemos determinar el sentido de los valores del giroscopio con la “regla de la mano derecha”, que se ilustra en la Figura 4.3.

Tabla 4.4.    El giroscopio        Fuente: Intel Corporation, 2012

En el Ejemplo de código 5 se muestra cómo crear una instancia de giroscopio.

public class SensorDialog extends Dialog implements SensorEventListener {
    ... 
    private Sensor mGyro;
    private SensorManager mSensorManager; 
       
    public SensorDialog(Context context) {
        super(context);
        mSensorManager = (SensorManager)context.getSystemService(Context.SENSOR_SERVICE);
        mGyro = mSensorManager.getDefaultSensor(Sensor.TYPE_GYROSCOPE);
    ...
}

Ejemplo de código 5: Creación de una instancia de giroscopio**
Fuente: Intel Corporation, 2012

2.5 Sensores de posición

Muchas tabletas Android admiten dos sensores de posición: el magnetómetro y el sensor de proximidad. El magnetómetro mide las intensidades del campo magnético terrestre a lo largo de los ejes x, y y z, mientras que el sensor de proximidad detecta la distancia del dispositivo a otro objeto.

2.5.1 Magnetómetro

El uso más importante que da el sistema Android al magnetómetro (que se describe en la Tabla 4.5) es la implementación de la brújula.

Tabla 4.5    El magnetómetro        Fuente: Intel Corporation, 2012

En el Ejemplo de código 6 se muestra cómo crear una instancia de magnetómetro.

public class SensorDialog extends Dialog implements SensorEventListener {
    ... 
    private Sensor mMagnetometer;
    private SensorManager mSensorManager; 
       
    public SensorDialog(Context context) {
        super(context);
        mSensorManager = (SensorManager)context.getSystemService(Context.SENSOR_SERVICE);
        mMagnetometer = mSensorManager.getDefaultSensor(Sensor.TYPE_MAGNETIC_FIELD);
    ...
}

Ejemplo de código 6: Creación de una instancia de magnetómetro**
Fuente: Intel Corporation, 2012

2.5.2 Proximidad

El sensor de proximidad proporciona la distancia entre el dispositivo y otro objeto. El dispositivo lo puede usar para detectar si está siendo sostenido cerca del usuario (ver Tabla 4.6) y así determinar si el usuario está haciendo o recibiendo llamadas telefónicas.

Tabla 4.6    El sensor de proximidad        Fuente: Intel Corporation, 2012

En el Ejemplo de código 7 se muestra cómo crear una instancia de sensor de proximidad.

public class SensorDialog extends Dialog implements SensorEventListener {
    ... 
    private Sensor mProximity;
    private SensorManager mSensorManager; 
       
    public SensorDialog(Context context) {
        super(context);
        mSensorManager = (SensorManager)context.getSystemService(Context.SENSOR_SERVICE);
        mProximity = mSensorManager.getDefaultSensor(Sensor.TYPE_PROXIMITY);
    ...
}

Ejemplo de código 7: Creación de una instancia de sensor de proximidad**
Fuente: Intel Corporation, 2012

2.6 Sensores de entorno

Los sensores de entorno detectan e informan los parámetros de entorno del ambiente en el que se encuentra el dispositivo. La disponibilidad de cada sensor en particular depende sólo del fabricante del dispositivo. El sensor de luz ambiente (ALS) está disponible en muchas tabletas Android.

2.6.1 Sensor de luz ambiente (ALS)

El sistema usa el sensor de luz ambiente, que se describe en la Tabla 4.7, para detectar la iluminación del entorno y ajustar automáticamente el brillo de la pantalla según lo detectado.

Tabla 4.7    El sensor de luz ambiente        Fuente: Intel Corporation, 2012

En el Ejemplo de código 8 se muestra cómo crear una instancia del sensor de luz ambiente.

    ... 
    private Sensor mALS;
    private SensorManager mSensorManager; 
  
    ... 
        mSensorManager = (SensorManager)context.getSystemService(Context.SENSOR_SERVICE);
        mALS = mSensorManager.getDefaultSensor(Sensor.TYPE_LIGHT);
    ...

Ejemplo de código 8: Creación de una instancia de sensor de luz ambiente**
Fuente: Intel Corporation, 2012

2.7 Pautas de optimización y rendimiento de sensores

Para usar sensores en sus aplicaciones, es aconsejable que siga las siguientes pautas:

• Antes de usar un sensor específico, siempre compruebe que esté disponible
  La plataforma Android no exige la inclusión o exclusión de sensores específicos en el dispositivo. Los sensores que se incluyen es algo que decide el fabricante del dispositivo en forma exclusiva. Antes de usar un sensor en su aplicación, siempre compruebe primero que esté disponible.
• Siempre cancele el registro de los procesos de escucha del sensor
  Si la actividad que implementa el proceso de escucha del sensor se vuelve invisible, o si el diálogo se detiene, cancele el registro del proceso de escucha del sensor. Se puede hacer con el método onPause() de la actividad o el método onStop() del diálogo. Si no cumple con esta pauta, el sensor continuará adquiriendo datos y, como consecuencia, agotará la batería.
• No bloquee el método onSensorChanged()
  El sistema llama con frecuencia al método onSensorChanged() para informar datos de sensor. Debe haber la menor cantidad de lógica posible dentro de este método. Los cálculos complicados con datos del sensor se deben mover hacia fuera de este método.
• Siempre pruebe en dispositivos reales las aplicaciones que usen sensores
  Todos los sensores que se describen en esta sección son de tipo hardware. Es posible que el emulador de Android no sea suficiente para simular las funciones y el rendimiento de los sensores.

3 GPS y ubicación

El Sistema de Posicionamiento Global (Global Positioning System, GPS) es un sistema satelital que proporciona información precisa de ubicación geográfica en todo el mundo. Está disponible en una gran variedad de tabletas Android. En muchos aspectos, se comporta como un sensor de posición. Puede proporcionar datos precisos de ubicación para las aplicaciones que se ejecutan en el dispositivo. En la plataforma Android, el marco de trabajo de sensores no maneja el GPS de manera directa. Lo que ocurre, en cambio, es que el servicio de localización Android accede a los datos del GPS y los transfiere a las aplicaciones a través de las devoluciones de llamada de los procesos de escucha de ubicación.

3.1 Servicios de localización de Android

Usar el GPS no es la única manera de obtener la información de ubicación en los dispositivos Android. El sistema también puede utilizar Wi-Fi*, redes celulares y otras redes inalámbricas para hacerse con la ubicación actual del dispositivo. El GPS y las redes inalámbricas (incluidas las Wi-Fi y las celulares) actúan como “proveedores de ubicación” para los servicios de localización de Android. En la Tabla 4.8 se incluye una lista de las clases e interfaces principales que se usan para acceder a los servicios de localización de Android:

Tabla 4.8    El servicio de localización de la plataforma Android        Fuente: Intel Corporation, 2012

3.2 Cómo obtener actualizaciones de ubicación por GPS

De manera similar al mecanismo de usar el marco de trabajo de sensores para acceder a datos de sensores, la aplicación implementa varios métodos de devolución de llamada definidos en la interfaz LocationListener para recibir actualizaciones de ubicación por GPS. LocationManager envía notificaciones de actualización de GPS a la aplicación por medio de estas devoluciones de llamada (la regla “No nos llame, nosotros lo llamaremos”).

Para acceder a los datos de ubicación GPS de la aplicación, es necesario que solicite el permiso de acceso a ubicación precisa en su archivo de manifiesto de Android (Ejemplo de código 9).

<manifest ...>
...
    <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"...  
</manifest>

Ejemplo de código 9: Cómo solicitar el permiso de acceso a ubicación precisa en el archivo de manifiesto**
Fuente: Intel Corporation, 2012

En el Ejemplo de código 10 se muestra cómo obtener actualizaciones del GPS y mostrar las coordenadas de latitud y longitud en una vista de texto de diálogo.

package com.intel.deviceinfo;
  
import android.app.Dialog;
import android.content.Context;
import android.location.Location;
import android.location.LocationListener;
import android.location.LocationManager;
import android.os.Bundle;
import android.widget.TextView;
  
public class GpsDialog extends Dialog implements LocationListener {
    TextView mDataTxt;
    private LocationManager mLocationManager;
       
    public GpsDialog(Context context) {
        super(context);
        mLocationManager = (LocationManager)context.getSystemService(Context.LOCATION_SERVICE);
    }
  
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
             mDataTxt = (TextView) findViewById(R.id.sensorDataTxt);
          mDataTxt.setText("...");
             
        setTitle("Gps Data");
    }
       
    @Override
    protected void onStart() {
        super.onStart();
        mLocationManager.requestLocationUpdates(
            LocationManager.GPS_PROVIDER, 0, 0, this);
    }
             
    @Override
    protected void onStop() {
        super.onStop();
        mLocationManager.removeUpdates(this);
    }
  
    @Override
    public void onStatusChanged(String provider, int status, 
        Bundle extras) {
    }
  
    @Override
    public void onProviderEnabled(String provider) {
    }
  
    @Override
    public void onProviderDisabled(String provider) {
    }
  
    @Override
    public void onLocationChanged(Location location) {
        StringBuilder dataStrBuilder = new StringBuilder();
        dataStrBuilder.append(String.format("Latitude: %.3f,   Logitude%.3fn", location.getLatitude(), location.getLongitude()));
        mDataTxt.setText(dataStrBuilder.toString());
             
    }
}

Ejemplo de código 10: Diálogo que muestra los datos de ubicación del GPS**
Fuente: Intel Corporation, 2012

3.3 Pautas de optimización y rendimiento del GPS y la localización

El GPS proporciona la información de ubicación más exacta del dispositivo. Sin embargo, al ser una prestación de hardware, consume energía adicional. Por otra parte, al GPS le lleva tiempo obtener sus primeros datos de ubicación. Las siguientes son algunas pautas que se deben seguir al desarrollar aplicaciones que utilicen el GPS y datos de ubicación:

• Considere todos los proveedores posibles
  Además de GPS_PROVIDER, está NETWORK_PROVIDER. Si sus aplicaciones sólo necesitan los datos de ubicación aproximada, puede considerar el uso de NETWORK_PROVIDER.
• Use las ubicaciones guardadas en el caché
  Al GPS le lleva tiempo obtener sus primeros datos de ubicación. Cuando la aplicación está esperando que el GPS obtenga una actualización de ubicación precisa, puede usar primero las ubicaciones que proporciona el método LocationManager’s getlastKnownLocation() para realizar parte del trabajo.
• Reduzca al mínimo la frecuencia y la duración de las solicitudes de actualización de ubicación
  Debe solicitar la solicitud de ubicación sólo cuando sea necesario y cancelar el registro del administrador de ubicación cuando ya no necesite las actualizaciones.

4. Resumen

La plataforma Android proporciona interfaces de programación de aplicaciones (API) para que los desarrolladores accedan a los sensores integrados de los dispositivos. Estos sensores son capaces de proporcionar datos sin procesar acerca del movimiento, la posición y las condiciones de entorno del ambiente actuales del dispositivo con gran precisión. Al desarrollar aplicaciones que usen sensores, debe seguir los procedimientos recomendados para mejorar el rendimiento y aumentar la eficiencia.

Aviso de optimización

Los compiladores de Intel pueden o no optimizar al mismo grado para microprocesadores que no sean de Intel en el caso de optimizaciones que no sean específicas para los microprocesadores de Intel. Entre estas optimizaciones se encuentran las de los conjuntos de instrucciones SSE2, SSE3 y SSE3, y otras. Intel no garantiza la disponibilidad, la funcionalidad ni la eficacia de ninguna optimización en microprocesadores no fabricados por Intel.

Las optimizaciones de este producto que dependen de microprocesadores se crearon para utilizarlas con microprocesadores de Intel. Ciertas optimizaciones no específicas para la microarquitectura de Intel se reservan para los microprocesadores de Intel. Consulte las guías para el usuario y de referencia correspondientes si desea obtener más información relacionada con los conjuntos de instrucciones específicos cubiertos por este aviso.

Notice revision #20110804

1.  Introduction

This chapter examines mobile GPUs and how to best optimize for GPUs included with Intel® Atom™ processors.

2.    GPU Evolution

It’s important to understand how mobile GPUs are evolving.Originally, mobile devices used software rasterization to generate the final image on the screen. However, the CPU was overtaxed performing rasterization and all the other tasks involved in a modern OS. In Android, the CPU is performing numerous background tasks, handling I/O, and running applications. Combine this with Android’s numerous graphical animations and effects used to convey intuitive UI response, and the need for a GPU is apparent.

The Intel Atom processor is designed to maximize performance and battery life on a mobile device. Just as the Intel Atom processor’s CPU is specially designed for mobile devices, so is its GPU. A lot of the initial GPU design came from OpenGL* ES. The next chapter explores OpenGL ES and how the API allows developers to write graphical applications on Android.  

OpenGL was designed to be run on a desktop. It supports numerous features that are not necessary on a mobile device, such as scientifically accurate operations and high-bit precision. To support full OpenGL on a device would require a lot of extra hardware. That extra hardware takes precious space and power. Enter OpenGL ES. OpenGL ES was designed for mobile devices and removes a lot of the OpenGL features not needed for mobile devices.

 OpenGL ES 1.1 only supports fixed function pipelines. As such, GPU designers targeting OpenGL ES 1.1 can create very simple special-purpose GPUs. As mobile devices evolved, this limitation was holding back modern graphical techniques. OpenGL ES was extended to support a programmable pipeline (that is, shaders) with OpenGL ES 2.0. This evolution allowed much more complex visuals included in modern 3D games. However, it also required GPUs to become much more complex.

OpenGL ES 2.0 is the predominate graphics API. But the story doesn’t end here. OpenGL ES 3.0 is on the horizon and with it comes the possibility of even more complex and visually impressive techniques.

3.    Two Major Mobile GPU Designs

There are currently two major designs being used by mobile GPUs: deferred and immediate. Deferred mode GPUs wait until all commands for an individual frame are submitted before processing the work. An immediate mode GPU starts working on commands as soon as they are ready. Table 1 shows major GPU vendors and their GPU design type.

Table 1: Major GPU Vendors and Their GPU Design Types. (Please Note: Intel HD Graphics is part of Intel® Core™ processors. Current Intel® Atom™ processors use PowerVR-based GPUs.)

Source: Intel Corporation, 2012

3.1.  Advantages of Deferred Mode GPUs

A deferred mode GPU has several major advantages. First, data sent to the GPU can be better organized. This can result in significantly decreased memory bandwidth. Memory usage is a major consumer of power, so limiting memory bandwidth will result in significant power gains.

Since all the data to render the frame is known, the work can be easily divide into smaller chucks. PowerVR is actually referred to as a deferred tile-based render. This is because the GPU collects all the commands/data to generate a frame and then divides the work into small tiles. A tile is just a square collection of pixels. This collection of pixels is designed to fit into very high-speed caches. If you want to learn more about all the advantages of PowerVR’s design, please refer to their documentation: http://www.imgtec.com/powervr/insider/docs/POWERVR%20Series5%20Graphics.SGX%20architecture%20guide%20for%20developers.1.0.8.External.pdf.

Deferred rendering does have several limitations. The internal memory and cache on the GPU can only be so big. If a frame has too much data to be rendered, the work needs to be divided among multiple rendering passes. This redundancy results in a lot of overhead and wasted operations. A lot of the optimization tricks for deferred mode GPUs involve avoiding these “glass jaws.”

3.2.  A Note About Defining “Deferred”

The term deferred is very overloaded in computer graphics. There are many terms like deferred mode GPUs, deferred renders, deferred shading, deferred lighting, and deferred rasterization. To make it even more challenging, the definitions are not consistent and must be taken in context. Don’t confuse a deferred mode GPU with deferred rendering techniques. In general, deferred rendering techniques refer to accumulating scene data into a g-buffer and applying lighting/shading in screen space. 

3.3.               Advantages of Immediate Mode GPUs

Immediate mode GPUs have been the predominant desktop design for decades. A lot of rendering techniques, tricks, and optimizations have been designed around immediate mode rendering. As such, immediate mode GPUs have become very complex and capable.

Since an immediate mode rendering starts processing commands as soon as they are ready, simple tasks can be completed more quickly and efficiently on immediate mode GPUs. Furthermore, they don’t run into as many “glass jaws” based on the amount of data passed to the GPU.

However, the years of design for immediate mode GPUs targeted desktops with massive power supplies. This has resulted in designs that maximized performance at the cost of power. This is why deferred mode renders have dominated the mobile market. But research and development in immediate mode GPUs have been driving down power utilization rapidly; this can be seen in Intel HD Graphics included in Intel Core processors.

4.    Optimizing for Intel GPUs

As shown in Table 2, Intel Atom processors designed for Android use PowerVR GPUs.

Table 2: Intel Atom Processors Designed for Android Use and Their GPUs. (More details about individual processors can be found at ark.intel.com.)

Source: Intel Corporation, 2012

 It’s important to refer to Imagination Technologies’ documentation on PowerVR. General optimization tips and tricks provided by Imagination Technologies are just as important on Intel platforms as other platforms with PowerVR.

To get a good understanding of the PowerVR hardware, please review Imaginations Technologies’ architecture guide: http://www.imgtec.com/powervr/insider/docs/POWERVR%20Series5%20Graphics.SGX%20architecture%20guide%20for%20developers.1.0.8.External.pdf.

To get a good understanding of how to optimize for PowerVR hardware, please review Imaginations Technologies’ developer recommendations: http://www.imgtec.com/powervr/insider/docs/POWERVR%20SGX.OpenGL%20ES%202.0%20Application%20Development%20Recommendations.1.8f.External.pdf.Pay close attention to the “golden rules.”

It’s important to use good texture compression on mobile devices. Proper texture compression will decrease download sizes, improve visual quality, increase performance, and decrease impact on memory bandwidth. However, this is one of the biggest challenges on Android. Since Android supports a wide range of hardware, there isn’t one texture format that runs well on all devices. OpenGL ES only requires that the hardware supports ETC texture compression. Sadly, this format doesn’t support an alpha channel. So developers are forced to support multiple texture formats. For PowerVR, developers should use PVRTC to compress all textures.

5.    Conclusion

This chapter provided a brief overview of mobiles GPUs and how to best optimize for GPUs included with Intel Atom processors. The next chapter will take a closer look at the API used to drive the GPU, OpenGL ES.

1. Introduction

The standard API for 3D graphics on Android is OpenGL ES, which is the most widely used 3D graphics API on all mobile devices today. Android uses OpenGL ES to accelerate both 2D and 3D graphics. In early releases of Android, OpenGL ES acceleration was somewhat optional, but as Android has evolved and screen sizes have grown, accelerated OpenGL ES has become an essential part of the Android graphics system.

The three versions of OpenGL ES are 1.0 and 1.1, which have been supported on Android from the beginning, and 2.0, which was added in Android 2.2. Today, Android developers can choose to use any version. Table 1 summarizes all of the major releases of Android to date and which releases have system images for the Intel^® Atom™ processor built in.

Table 1: Summary of Android* Versions with Integrated OpenGL ES* and Intel^® Atom™ Processor System Images

Android has been supported on the Intel Atom platform since Android 2.3.3, including OpenGL ES 1.0, 1.1, and 2.0. The support for OpenGL ES on Intel Atom processors is comprehensive and outperforms most other Android solutions due to a unique combination of features:

• PowerVR SGX540 and SGX544MP2 GPUs (at 400 MHz and up)
• Faster floating-point
• x86 System Images for Android Virtual Device Emulation
• Intel^® Hardware Accelerated Execution Manager (Intel HAXM)
• Intel^® Graphics Performance Analyzers (Intel GPA)

Intel has partnered with Google and is committed to continue to provide outstanding support for the Android platform with ongoing releases of x86 system images, Intel HAXM, and Intel GPA for future versions of Android.

2. x86 System Images for Android Virtual Device Emulation

Every embedded developer knows how a virtual device emulator can speed up development of new application software. But using an Android Virtual Device (AVD) for an ARM system image is painfully slow because the AVD must emulate every ARM instruction on a Windows* or Linux* development system. It can take 5 minutes or longer just to boot Android on a typical ARM AVD. Intel has solved this problem with the Intel Hardware Accelerated Execution Manager (Intel HAXM). When this tool is installed and used with an Intel x86 Atom system image AVD, your application development will be greatly accelerated and you don’t even need Intel Atom hardware to get started.

Note that Google’s AVD emulation currently only supports OpenGL ES 1.0 and 1.1 development and not 2.0. This is a limitation of Google’s emulation software irrespective of the architecture of the CPU or GPU.

3.Intel® Graphics Performance Analyzers

Another important tool available to OpenGL ES app developers targeting Android on Intel Atom processors is Intel Graphics Performance Analyzers (Intel GPA). This suite of tools provides a real-time view of dozens of critical system metrics covering the CPU, GPU, and OpenGL ES. Intel GPA run on either a Windows or Ubuntu Linux development system and communicate with driver components running on the Android target device through the Android debug interface (adb). By running some experiments, developers can quickly spot bottlenecks in the graphics pipeline visually and identify the best opportunities for code optimization.

For more information and to download the latest version of Intel GPA (2012 R4) for Android development, see: http://software.intel.com/en-us/vcsource/tools/intel-gpa?cid=sem121p7972

4.Where to Get the OpenGL ES Drivers

Obtaining OpenGL ES drivers for the Intel Atom processors for Android is easy. They are already integrated into the x86 system images when you download an Android SDK that supports Intel Atom processors. Intel and Google developers have worked together to make Android application development just as easy for x86 devices as ARM devices, even if your app makes extensive use of OpenGL ES.

Android versions 2.3.3 (Gingerbread), 4.0.3 (Ice Cream Sandwich), and 4.1 (Jelly Bean) have full support for Intel Atom processors built in, including the drivers for OpenGL ES 1.1 and 2.0. Simply select one of these versions from the Android SDK Manager. Make sure the version you select lists “Intel x86 Atom System Image” as being included. Also, be sure to download and install the Intel Hardware Accelerated Execution Manager (Intel HAXM), which is listed in the SDK Manager under “Extras.” If you don't already have the Android SDK Manager installed, you can download it from:http://developer.android.com/sdk/index.html

Alternatively, you can download Intel x86 System Images directly from Intel’s site as well: http://software.intel.com/en-us/articles/android-ice-cream-sandwich-x86-emulator-image

5.The PowerVR* GPU

The Intel Atom processors feature the PowerVR graphics accelerators, which are the most widely used OpenGL ES accelerators in mobile devices today. PowerVR is a mature, proven design built on the Universal Scalable Shader Engine (USSE) architecture. However, not all PowerVR cores are created equal. The SGX540 series has twice the number of USSEs than SGX530 cores, and the SGX544MP2 core has quadruple, so the performance would be doubled or quadrupled, respectively, if the clock rates were the same. However, the Intel Atom processors also feature higher clock rates than other implementations, which provide even higher performance for OpenGL ES and ultimately a smoother user experience. Table 2 summarizes the PowerVR core families featured in Intel Atom processors.

Table 2: OpenGL ES* Accelerators in Intel® Atom™ processors for Android*

The USSE architecture in PowerVR can actually handle the unified shader model requirements of OpenGL 2.1 and DirectX* 10.1, but only the features that are exposed by OpenGL ES 1.1 and OpenGL ES 2.0, and their extensions, are available to Android developers.

6.Extensions to OpenGL ES

The OpenGL ES feature set is required to be mostly the same across platforms by the Khronos standard documents that define OpenGL ES 1.1 and 2.0. That is the purpose of a standardized API. However, GPU developers are permitted to expose special features of their GPU through extensions to OpenGL ES. The official online registry for OpenGL ES extensions maintained by Khronos where all extensions are documented is at: http://www.khronos.org/registry/gles

The most important extensions to OpenGL ES are available on most Android platforms, such as support for compressed textures and direct texture streaming, but there are many different formats for compressed textures in use today with OpenGL ES. The PowerVR core in Intel Atom processors offers the widest support for the various compressed texture formats.

Compressing textures is an important technique for 3D applications to reduce their memory requirements and improve performance, but the various formats in use are defined only by extensions and therefore vary for each platform. The most widely supported format is Ericsson Texture Compression (ETC1_RGB8), but it only supports 8 bit-per-pixel precision and has no support for per-pixel alpha. In addition to ETC1_RGB8, the PowerVR GPU also supports the PVRTC formats, which have some important advantages over ETC1_RGB8. The PVRTC formats support compressed textures with either 2 or 4 bits-per-pixel precision and with optional per-pixel alpha information. These features can significantly reduce the size of textures over the ETC1_RGB8 format and provide greater flexibility in creating alpha blending effects.

PowerVR cores and PVRTC are also used in all generations of the Apple iPhone*, iPod* Touch, and iPad* devices, so this provides some compatibility with Android on Intel Atom processors beyond the base OpenGL ES standard, which is important when developing apps across both the Android and iOS platforms. For more information, see “Texture compression support” at:

http://developer.android.com/guide/topics/graphics/opengl.html

Other important extensions to OpenGL ES provide for fast streaming of texture images between OpenGL ES and other parts of the Android system, like video frames from OpenMAX*, for example. Intel Atom processor drivers for OpenGL ES support these important extensions as well.

Android applications should never assume that any particular extension to OpenGL ES is available on any particular device. Instead, well-behaved apps will query OpenGL ES for a list of available extensions at runtime. The extension lists can be obtained from the OpenGL ES and EGL drivers with these calls:

glGetString(GL_EXTENSIONS);

eglQueryString(eglGetCurrentDisplay(), EGL_EXTENSIONS);

There is a useful app at the Google play site that will perform this query and display the returned list for any Android device it is run on: https://play.google.com/store/apps/details?id=com.realtechvr.glview

The OpenGL ES extensions that are available for Android vary significantly based upon the GPU core, not because of differences in the CPU architecture. Intel Atom processors provide essentially the same OpenGL ES extensions as any other Android platform with a PowerVR GPU, even though the Intel Atom processor has an x86 CPU architecture. In fact, the PowerVR core on Intel Atom processors supports more exclusive extensions to OpenGL ES than most other GPUs and some of these are quite useful. Of course, using these exclusive extensions will limit the portability of your application to Android devices with PowerVR cores. Extensions with names ending in “IMG” are likely to be exclusive to PowerVR, but this rule is not absolute. It’s best to test a range of Android devices yourself for the presence of the extensions you need with a tool like GLView.

Here are some examples of OpenGL ES Extensions Exclusive to PowerVR

glFramebufferTexture2DMultisampleIMG()
	glRenderbufferStorageMultisampleIMG()
	glMultiDrawArraysEXT()
	glMultiDrawElementsEXT()

7.Floating-Point Performance

It’s critical that both the CPU and GPU cores provide fast floating-point performance for OpenGL ES applications to perform well. Shader programs make extensive use of floating-point, which is executed on the GPU, but OpenGL ES application code typically requires a lot of floating-point calculation as well, which must be performed on the CPU in preparation for calls into OpenGL ES. This is another area where Intel Atom processors have a distinct advantage over ARM-based solutions because they have fast floating-point execution on both the CPU and GPU cores.

Systems that do not have floating-point hardware use fixed-point math instead with a disparate driver for OpenGL ES 1.1 called “Common-Lite.” But the system images Intel provides for Android include only the “Common” (floating-point) driver for OpenGL ES 1.1 because all Intel Atom processors have hardware floating-point built into both the CPU and GPU cores, so there is no need to ever use fixed-point. The Khronos standard for OpenGL ES 2.0 mandates floating-point only.

8.The Android Framework SDK

The Android SDK offers the easiest way to use OpenGL ES in your Android application by using the GLSurfaceView class. This class handles most of the initialization of the EGL, threading, and allocating a surface that OpenGL ES can render to and that Android can display. OpenGL ES can also render to a TextureView object that has some additional capabilities, like transformations and alpha blending, but requires more code to set up and use. The Android SDK provides support for OpenGL ES through bindings for Java* in these packages from Google and Khronos:

• jvax.microedition.khronos.egl: The Khronos standard implementation
• javax.microedition.khronos.opengles: The Khronos standard implementation
• android.opengl: Updated to provide better performance

The three versions of the OpenGL ES API that can be used today on Android are: 1.0, 1.1, and 2.0. OpenGL ES 1.0 has been superseded by 1.1. OpenGL ES 2.0 offers greater flexibility through shader programming, but is not compatible with legacy code written for OpenGL ES 1.1. Table 3 summarizes the versions of the OpenGL ES API that can be used for application development and the classes that define them for Android.

Table 3: OpenGL ES Support Classes in Android

The Intel Atom processor platform for Android provides full support for applications that use any of these versions of OpenGL ES through either the SDK or the NDK.

9.The Android NDK

The Native Development Kit (NDK) was developed by Google to help developers achieve better performance in their Android applications by bypassing the Dalvik VM and running C/C++ code natively. Google decided to make the NDK available to all Android developers because it simplifies the process of porting existing applications written in C/C++ and allows the best possible performance in applications that need it the most, like 3D games.

The Android NDK supports both OpenGL ES 1.1 and 2.0, and provides some example apps for both. Most applications using OpenGL ES are written in C/C++, and the NDK provides a mechanism for combining C/C++ code with an Android framework, which is based on Java. This is called the Java Native Interface (JNI) and it’s becoming the dominate approach for implementing apps that require fast graphics on Android. The NDK supports the JNI for Intel Atom processors beginning with release r6b, which you can download from: http://developer.android.com/sdk/ndk/index.html

10.Renderscript

Renderscript was first introduced in Android 3.0. It is another technology that Google developed to help accelerate computationally intensive algorithms, including graphics, by bypassing the Dalvik VM. But, unlike the NDK, Renderscript code is compiled at runtime on the Android device. Renderscript is designed to exploit multiple processors, but it currently only utilizes the processing cores available on the CPU and not the GPU. Google will probably improve Renderscript to utilize GPU cores in a future release and existing Renderscript code should be able to exploit that new power when it becomes available, hopefully without modification.

Renderscript abstracts the hardware it runs on so that app developers need not be concerned about the CPU architecture or even how many processors are actually available. But Renderscript does not use existing parallel computing standards to accomplish this, like GLSL or OpenCL*. It is instead a new language based on C99 with support for OpenGL ES built in. Renderscript’s abstraction guarantees that it will run on any Android device, including Intel Atom processors. For more information on Renderscript, see: http://android-developers.blogspot.com/2011/02/introducing-renderscript.html

11.Conclusion

The Intel Atom processor’s x86 architecture is not an issue when developing OpenGL ES applications for Android because the processor provides all of the same features developers expect of ARM-based solutions and more. The architecture of the GPU is much more important for assuring OpenGL ES compatibility across Android platforms and Intel Atom processor’s PowerVR core is the most widely used GPU in mobile devices today. The Intel Atom processor’s combination of best-in-class PowerVR cores with fast floating-point and superior support software for fast AVD emulation and graphics pipeline performance analysis provides the best overall solution for OpenGL ES applications on Android.

12. About the Author

Clay D. Montgomery is a leading developer of drivers and apps for OpenGL on embedded systems. His experience includes the design of graphics accelerator hardware, graphics drivers, APIs, and OpenGL applications across many platforms at STB Systems, VLSI Technology, Philips Semiconductors, Nokia, Texas Instruments, AMX, and as an independent consultant. He was instrumental in the development of some of the first OpenGL ES, OpenVG, and SVG drivers and applications for the Freescale i.MX and TI OMAP platforms and the Vivante, AMD, and PowerVR graphics cores. He has developed and taught workshops on OpenGL * ES development on embedded Linux and represented several companies in the Khronos Group.

OpenGL ES, OpenMAX and OpenVG are trademarks of the Khronos Group.

OpenCL and the OpenCL logo are trademarks of Apple Inc and are used by permission of Khronos.

DirectX is a trademark of Microsoft Corporation.

Copyright September 25, 2012, Intel Corporation

利用英特尔® Android USB 驱动程序包，您能够将您基于 Windows* 的机器连接至安装了英特尔® 凌动™ 处理器的 Android 设备。

注：英特尔 USB 驱动程序包（版本 1.1.5）增加了对 Microsoft Windows* 8 的支持，可供 Android 应用开发人员使用。如欲了解有关用户设备支持的具体信息，请联系您的设备制造商。我们还为该驱动程序的早期版本 1.1.4 提供了一个下载链接，请见以下链接

Microsoft Windows*
Windows 8 (32/64 位), Windows 7 (32/64 位), Windows Vista (32/64 位), Windows XP (仅限 32 位)
安装指南和系统要求 - Windows

     
我们还根据《英特尔 Android 设备 USB 驱动程序终端用户许可协议》提供了以下下载。

附件	大小
intelandroiddrvsetup1.1.5.zip	8.78 MB
intelandroiddrvsetup1.1.4.zip	8.78 MB

英特尔硬件加速执行管理器（英特尔® HAXM）是一个硬件辅助虚拟化引擎（管理程序）,该引擎可以使用英特尔虚拟化技术（英特尔® VT）加快主机上的 Android 应用模拟速度。配合使用英特尔提供的 Android x86 模拟器映像和正式版的 Android SDK 管理器，HAXM 可以帮助您在英特尔 VT 支持的系统上更快地进行模拟。
英特尔 HAXM 可以支持以下几种平台：

• Microsoft Windows*
  Windows 8 (32/64 位), Windows 7 (32/64 位), Windows Vista* (32/64 位), Windows XP (仅限 32 位)
  
  安装指南和系统要求 - Windows

• Mac OS* X
  基于英特尔、预装 Mac 操作系统的 Mac 机 X 10.6 以及更新的产品 (32/64 位)
  
  安装指南和系统要求 - Mac OS X

已知问题：
当 HAXM 和 VirtualBox v4.2.14（或更新的版本）同时在一台机器上运行时， Android 模拟器可能会失灵。我们经过测试后发现 v4.2.12 版的 VirtualBox 及更早的版本未出现该问题。

• Linux
  Ubuntu (64 位)

  
版权所有© 2013 英特尔公司。
所有权利受到保护。

再次分发。在满足以下条件的情况下，允许以二进制的形式进行再次分发或使用（不作修改）：

1. 再次分发必须在文档和/或其他随分发提供的材料中保留上述版权通知以及下述免责声明。

2. 未经英特尔事先明确书面许可，不可使用英特尔公司的名称或其供应商的名称进行背书或者促销从该软件派生的产品。

3. 不准对本软件进行逆向工程、反向编译或反汇编。有限的专利许可。英特尔公司针对它现在或今后拥有或控制的专利授予全球性的、免版税的、非独家的许可，被许可方可以制作、已经制作、使用、进口、要约出售和出售（“利用”）本软件，但是其范围仅限于有必要借助任何此类专利利用该软件。不准将该专利许可用于任何包含本软件的组合。任何硬件本身并不在本许可范围之内。

免责条款。
此软件由版权持有者和献助者按“原样”提供，绝不提供其他任何明确或隐含的担保（包括，但不限于，商品适销性和或适用于特定目的适用性的担保）。在任何情况下，版权持有者或 献助者对使用本软件而以任何方式产生之直接的、间接的、事故性的、特殊的、惩罚性的或后果性的损失（包括，但不限于，购买替代产品或服务，使用、数据或利润的减少，或者业务中断）概不承担责任，不论损失是如何造成的及根据任何责任理论（无论是按合同法、严格责任或侵权 - 包括疏忽或其它 -），即使事先被告知这种损失的可能性。

点击以接受《最终用户许可协议》并下载 haxm-windows_r03.zip

 
x86 Android* 4.3 (Jelly Bean) 模拟器系统映像支持您在您的开发机器上运行 Android 模拟。 通过与 Android SDK 结合使用，您可以在基于英特尔架构的虚拟 Android 设备上测试您的 Android 应用。

要安装模拟器映像插件，您可以利用 Android SDK 管理器（推荐方法）：

• 安装指南 - 推荐方法。

或者，您也可以下载二进制 zip 文件并解压缩，然后将包含的目录复制到 Android SDK 安装路径的插件目录中。 （请注意这种方法不支持插件自动更新）：

• 安装指南 - 备选方法。

    
介绍

本指南在安装面向 Android* Jelly Bean 的英特尔® 凌动™ x86 映像方面提供了相关指导，该映像可用于英特尔 x86 架构上的开发。

前提条件

Android x86 模拟器映像要求安装 Android SDK。 有关安装和配置 Android SDK 的说明，请访问 Android 开发人员网站(http://developer.android.com/sdk/)。

可选: 英特尔硬件加速执行管理器 (HAXM)有助于加快面向 Android 的 X86 模拟器映像的速度。 更多信息，请见本指南中的“优化”部分。

已知问题：

• 摄像头问题： 当在 android 4.2 系统映像上录制视频时摄像头会失灵，该问题已经记录在： http://code.google.com/p/android/issues/detail?id=41227
• 浏览器问题： 浏览器与 Vista 32 位机上的模拟器会出现随机冲突 该问题已经记录在： http://code.google.com/p/android/issues/detail?id=42733
• 稳定性问题： 当一个 AVD 使用的设备 RAM 大小为 1024 时，模拟器可能会失灵。 英特尔正在调查该问题，并将进一步提供说明。

安装

通过Android SDK 管理器下载

1. 启动 Android SDK 管理器。
2. 在 Android 4.2 (API 17) 下，选择 "Intel x86 Atom System Image"：
   
   
3. 选中后，点击“Install Package”按钮。
4. 查看英特尔公司许可协议。 如您接受所述条款，选择“Accept”并点击“Install”。
5. SDK 管理器会自动下载系统映像，并将其解压到 Android SDK 目录下的适当位置中。

使用系统映像

1. 启动 Android AVD 管理器并创建一个新的 AVD，将 "Target"设置为 "Android 4.2 – API Level 17"，同时将 "CPU/ABI"设置为 "Intel Atom (x86)"。

   面向 Android Jelly Bean 的英特尔凌动 x86 映像能利用硬件 GPU 特性来提高提高游戏、图形密集型项目以及用户界面相关元素的性能。 如果想获得最佳性能，请务必在创建映像时选中 "Use Host GPU"复选框。

   注： GPU 加速的功能性和性能在很大程度上取决于您电脑上的显卡和显卡驱动程序。 GPU 加速必须在单个 AVD 上分别启用。
   
   

   注：如果 "Intel Atom (x86)" CPU/ABI 选项无法使用，请确认系统映像是否已正确安装。

2. 点击 "Create AVD"按钮。
3. AVD 已安装成功并可投入使用：
   
   

优化

CPU 加速

通过使用基于英特尔 VT-x 技术的硬件虚拟化，面向 Android Jelly Bean 的英特尔凌动 x86 映像的性能将得到显著提升。

如果您的电脑使用的是支持 VT-x 技术的英特尔处理器，我们建议您在使用该系统映像时同时使用英特尔硬件加速执行管理器 (HAXM)。 有关英特尔 HAXM 的更多信息，请访问 http://www.intel.com/software/android。

注：英特尔 HAXM 仅适用于 Windows 与 OS X 操作系统。 对于 Linux 主机，可使用基于内核的虚拟机（KVM）来提升模拟性能。 有关在 Ubuntu 上安装和配置 KVM 的更多信息，请参考： https://help.ubuntu.com/community/KVM/Installation

<sub>版权所有 (C) 2013 英特尔公司。 保留所有权利。
英特尔、Intel 标识、Atom 和凌动是英特尔公司在美国和其他国家（地区）的商标。
此处涉及的所有产品、计算机系统、日期和数字信息均为依据当前期望得出的初步结果，可随时更改，恕不另行通知。
* 其它名称和品牌可能是各自所有者的财产。</sub>

  
介绍

本文将指导您安装英特尔® 硬件加速执行管理器（英特尔® HAXM），这是一款可以使用英特尔® 虚拟化技术（VT）加快 Android* 开发速度的硬件辅助虚拟化引擎（管理程序）。

前提条件

英特尔 HAXM 要求首先安装 Android* SDK (版本为 17 或更高)。 更多信息，请访问 Android* 开发人员网站 (http://developer.android.com/sdk/)。

系统要求

硬件要求：

• 支持 VT-x、EM64T 和病毒防护 (XD) 功能的英特尔® 处理器
• 至少 1 GB 的可用 RAM

支持的操作系统：

• Microsoft Windows* 8 (32/64 位)
• Microsoft Windows* 7 (32/64 位)
• Microsoft Windows Vista* (32/64 位)
• Microsoft Windows* XP SP2 (仅限 32 位)

重要提示： 英特尔 HAXM 在具备以下特点的系统上无法使用：不使用英特尔处理器；或者使用的英特尔处理器缺少以上“硬件要求”章节中描述的硬件特性。
如欲确定您的英特尔处理器具备哪些功能，请访问http://ark.intel.com/zh-cn/
。此外，英特尔 HAXM 必须和英特尔提供的 Android* x86 模拟器映像一同使用。
英特尔 HAXM 不能和 ARM* Android* 模拟器映像或非英特尔 x86 Android* 模拟器映像一起使用。

下载英特尔® HAXM

综述
安装英特尔 HAXM 时可以选择通过 Android* SDK 管理器的方式 (推荐)，或者通过手动的方式（即手动从英特尔的网站下载安装程序）。
注：英特尔 HAXM 现在还不能自动检查更新。 如欲获取最新版本，请使用 Android* SDK 管理器 (推荐) 或者从 英特尔® 开发人员专区 Android* 开发人员网站下载英特尔 HAXM 软件包。

手动下载

1. 请转至 http://software.intel.com/en-us/android。
2. 为您的平台选择英特尔 HAXM 安装程序包。
3. 解压安装程序并使用适合您平台的安装说明。

通过 Android* SDK 管理器下载

1. 启动 Android* SDK 管理器。
2. 在 Extras 下，选中紧挨着 "Intel x86 Emulator Accelerator (HAXM)"的复选框。
   
   
3. 点击 "Install package…"按钮。
4. 查看英特尔公司许可协议。 如您接受所述条款，选择“Accept”并点击“Install”。
5. SDK 管理器会将安装程序下载到 SDK 主目录下的 "extras"目录中。 SDK 管理器可能会提示 "Installed"， 但该提示的真实意思是指下载了英特尔 HAXM 可执行文件。 此时仍然需要您从 "extras"目录中运行安装程序，以保证安装顺利完成。
6. 解压 "extras"目录中的安装程序，并使用适合您平台的安装说明。

在 Windows* 上安装英特尔® HAXM

警告： 如果您的系统不符合系统要求（包括对诸如英特尔虚拟化技术 (VT) 等英特尔处理器特性的支持），英特尔 HAXM 将无法安装。

1. 从 http://software.intel.com/en-us/android处或者使用 SDK 管理器下载安装程序包。
2. 运行安装程序（并在适用的情况下接受 UAC 提示)。
   1. 如果已经安装了较老版本的英特尔 HAXM，您将会看到一个对话框通知：
      
      

      点击 "Yes"升级英特尔 HAXM，或者点击 "No"离开安装页面，使英特尔 HAXM 保持为当前安装的版本。

   2. 您会看到一个欢迎屏幕：
      
      

      注： 您可以通过点击英特尔 HAXM 文档随时访问文档

3. 点击 "Next"
4. 系统会提示您调整分配给英特尔 HAXM 的 RAM 容量：
   
   

   注： 本安装程序也可用作英特尔 HAXM 的配置工具。 如欲改变内存的设置，请再次运行该安装程序。

5. 下一个屏幕将对您的英特尔 HAXM 内存分配设置进行确认：
   
   
6. 英特尔 HAXM 安装完成之后，请点击“Finish ”离开安装程序。
   英特尔 HAXM 现已安装完成，可投入使用。

如欲查明英特尔 HAXM 是否正在运行，请打开一个命令提示符窗口并执行以下命令： sc query intelhaxm

如果英特尔 HAXM 正在运行，该命令将显示一个状态信息，指示状态为： "4 RUNNING"。
如欲停止或启动英特尔 HAXM，请使用以下命令：
停止：

sc stop intelhaxm

开始：

sc start intelhaxm

调整英特尔® HAXM 内存分配

如欲改变分配给英特尔 HAXM 的内存容量，请再次运行安装程序。

移除英特尔 HAXM

警告： 在移除英特尔 HAXM 之前请关闭所有的 Android* x86 模拟器实例。 正在使用中的 HAXM 无法移除。

如欲卸载英特尔 HAXM，请再次运行安装程序或者使用控制面板。

重要提示： 移除英特尔 HAXM 之后所有的英特尔® x86 Android* 模拟器的加速功能将被禁用。 现有的 Android* 虚拟设备将继续工作，但却无法获得加速。

重新安装英特尔 HAXM 之后将重新启用 Android* 模拟器加速。

故障排除

英特尔 HAXM 要求使用一个由英特尔提供的 Android* x86 系统映像。 这些映像可以通过 Android* SDK 管理器进行下载，或者通过手动的方式从英特尔® 开发人员专区网站下载。

英特尔病毒防护 (XD) 功能错误

在安装英特尔 HAXM 时，您可能会遇到一个有关英特尔 XD 支持的错误。
这种错误信息可能是由以下情况导致的：

• 英特尔 XD 不受计算机处理器的支持。
• 英特尔 XD 未启用。

英特尔 XD 不受支持

英特尔 HAXM 要求使用一个具备病毒防护 (XD) 功能的英特尔处理器，因此不能在缺少这种硬件特性的系统上使用。 如欲确定您的英特尔处理器上具备的功能，请访问 http://ark.intel.com/zh-cn/。

英特尔 XD 未启用

在某些情况下，英特尔 XD 的禁用可能发生在系统 BIOS 中， 因此必须在 BIOS 设置程序中启用。 如欲访问 BIOS 设置程序，必须在电脑启动时按住一个设置键。 具体使用哪个设置键取决于使用的 BIOS，通常而言，该设置键会是 F2、Delete 或 Esc 键中的一个。 在 BIOS 设置程序中，英特尔 XD 可能会被标识为 "XD"、"Execute Disable"、"No Execute"或 "Hardware DEP"，这取决于使用的是哪种 BIOS。

除了英特尔 XD 之外，Windows* 主机可能还需要支持 DEP (数据执行保护)，有关详细信息请参考这篇 Microsoft* KB 文章： http://support.microsoft.com/kb/875352.

有关如何进入 BIOS 设置和启用英特尔 XD 的具体信息，请联系您的硬件制造商。

英特尔虚拟化技术 (VT-x) 功能

在安装英特尔 HAXM 时，您可能会遇到一个有关 VT-x 支持的错误。
这种错误信息可能是由以下情况导致的：

• 英特尔 VT-x 不受计算机处理器的支持
• 英特尔 VT-x 未启用

英特尔 VT-x 不受支持

英特尔 HAXM 要求使用一个具备 VT-x 功能的英特尔处理器，因此不能在缺少这种硬件特性的系统上使用。 如欲确定您的英特尔处理器上具备的功能，请访问 http://ark.intel.com/zh-cn/。

英特尔 VT-x 未启用

在某些情况下，英特尔 VT-x 的禁用可能发生在系统 BIOS 中，因此必须在 BIOS 设置程序中启用。 如欲访问 BIOS 设置程序，必须在电脑启动时按住一个键。 具体使用哪个设置键取决于使用的 BIOS，通常而言，该设置键会是 F2、Delete 或 Esc 键中的一个。 在 BIOS 设置程序中，英特尔 VT 可能会被标识为 "VT"、"Virtualization Technology"或 "VT-d"。确保启用所有的虚拟化特性。

有关如何进入 BIOS 设置和启用英特尔 VT 的具体信息，请联系您的硬件制造商。

提示与技巧

以下的一些建议有助于您通过使用英特尔 HAXM 驱动程序从 Android* 模拟器中获得最佳的体验。

• 在 AVD 管理器中为您的映像启用 GPU 加速。 HAXM 驱动程序可以通过处理器中的英特尔虚拟化技术本地执行大多数的 CPU 指令，同时 GPU 加速也会将 OpenGL* 调用卸载至主机 GPU。
• 从命令行启动模拟器以便获得更详细的输出。
  • 使用以下命令启动模拟器：
    emulator-x86 –avd <avd name> -partition-size 1024 –gpu on -verbose
  • 分区大小为 1024 时允许您安装 1 GB 的应用。 这与 AVD 管理器中的 SD 卡大小不同，该管理器会对模拟器内部专用于媒体文件的存储容量进行指定。 GPU 设置为“on”时会提供更出众的图形性能。
• 确保 GPU 模拟库的 "Path"环境变量通过 Control Panel > System > Advanced System Settings > Environment Variables 的方式进行设置，或者每次在启动一个新的命令提示符时通过手动的方式进行设置。 如果您正在使用多个 SDK 安装，我们建议您通过手动的方式进行设置。 下面的 <sdk install location> 通常指的是 "c:\Users\<your username>\android-sdk"
  set PATH=%PATH%;<sdk install location>\tools\lib
• 在安装英特尔 HAXM 时，请对驱动程序进行设置，确保只使用系统中可用 RAM 的一半容量。 例如，如果您的系统拥有 6 GB 的安装内存，那么请将其中的 3 GB 用于英特尔 HAXM 驱动程序。 这有助于在 HAXM 驱动程序和系统内存之间较好地平衡内存。
• 在创建映像时建议您将“设备 ram 大小”设置为小于 1024MB。
• 有时，在首次启动一个映像时，该映像会显示悬挂在启动屏幕上。 启动过程已经完成，但是主屏幕仍未显示。 点击模拟器上的“home”按钮显示主屏幕。
• 如果在 Windows 8 上发现了性能问题，我们建议您禁用 Hyper-V。
• 如欲了解更多有关启动模拟器的命令行选项，请参考 Android* 开发人员网站。

更改日志

• 在模拟器中已将 Linux 内核更新至 3.4
• 解决了在 VMware 工作站上从一个 Windows 虚拟机之内运行 HAXM 的性能问题
• 通过创建一个 c:\HaxLogs.log 文件在 windows 中添加了调试支持，以便模拟器可以通过一种正常的方式终止，同时不会造成一个 BSOD
• 稳定性提升

   
介绍

本指南在安装面向 Android* Jelly Bean 的英特尔® 凌动™ x86 映像方面提供了相关指导，该映像可用于英特尔 x86 架构上的开发。

前提条件

Android x86 模拟器映像要求安装 Android SDK。 有关安装和配置 Android SDK 的说明，请访问 Android 开发人员网站(http://developer.android.com/sdk/)。

可选: 英特尔硬件加速执行管理器 (HAXM)有助于加快面向 Android 的 X86 模拟器映像的速度。 更多信息，请见本指南中的“优化”部分。

已知问题：

• Caffeinemark 可能存在问题；logcat 可能会显示在 ashmem/libdvm 处存在故障
• 浏览器中播放的视频剪辑只有音频，没有视频。该问题只存在于浏览器中，全屏播放时没有出现。
• 在使用 ddms、uiautomatorviewer 或 monkeylmage 时屏幕捕捉功能会失灵
• 快照功能失灵
• 恢复出厂设置失灵
• 如果不对前后摄像头做任何设置，那么摄像头应用从一开始就会出现故障
• 通话过程中 3G 连接会丢失

安装

通过手动方式进行下载 (适用于 Windows 和 Mac OSX 的使用说明)

1. 关闭所有开启的 SDK 或 AVD 窗口。
2. 转至 http://www.intel.com/software/android。
3. 点击 Tools & Downloads
4. 下载英特尔 x86 凌动系统映像

(Android* 4.3 (Jelly Bean) x86 模拟器系统映像)。

Windows

1. 转至 Android SDK 所在的目录。 如果您安装时使用的是一个可执行文件，您可以在以下位置找到 Android SDK。
   1. 如果您在 64 位机上针对“everyone（每个人）”进行安装： "c:\Program Files (x86)\android" 32 位: "c:\Program Files\android"
   2. 如果是“just for me（只为我）”安装： "c:\users\<username>\AppData\local\android"
2. 以下使用说明和屏幕截图适用于 "just for me" windows 安装，但是文件需要解压到与 Android 安装时采用的路径一致的相对路径
   
3. system-images目录中包含按架构划分的 Android 系统映像： 如果不存在“system-images”目录或 "android-18"目录，您就需要创建这种目录。
   
4. 展开android-18 (此目录中包含 API Level 18 系统映像)：
   
5. 将已下载系统映像文件中包含的 x86目录直接解压到 android-18 目录中。 “./Android-SDK/system-images/android-18/x86/”目录应当包含以下文件：
   
6. 系统映像已成功安装并可投入使用。

Mac OSX

1. 转至您解压 SDK 时所用的目录
   
2. system-images目录中包含按架构划分的 Android 系统映像： 如果不存在“system-images”目录或 "android-18"目录，您就需要创建这种目录。
   
3. 展开android-18 (此目录中包含 API Level 18 系统映像)：
   
4. 将已下载系统映像文件中包含的 x86目录直接解压到 android-18 目录中。 “./android-sdk-macosx/system-images/android-18/x86/” 目录应当包含以下文件：
   
5. 系统映像已成功安装并可投入使用。

使用系统映像

1. 启动 Android AVD 管理器并创建一个新的 AVD， 将 "Target"设置为 "Android 4.3 – API Level 18"，同时将 "CPU/ABI"设置为 "Intel Atom (x86)"。
   面向 Android Jelly Bean 的英特尔凌动 x86 映像可以利用硬件 GPU 特性提升游戏、显卡密集型程序和用户界面组件的性能。 如果想获得最佳性能，请务必在创建映像时选中 "Use Host GPU"复选框。
   注： GPU 加速的功能性和性能在很大程度上取决于您电脑上的显卡和显卡驱动程序。 GPU 加速必须在单个 AVD 上分别启用。
   
   注： 如果 "Intel Atom (x86)" CPU/ABI 选项无法使用，请确认系统映像是否已正确安装。 您可以通过打开 Android SDK 管理器、查看“Android 4.3 (API 18)”下的“Intel x86 Atom System Image”状态的方式确认系统映像的安装情况
2. 点击 "Create AVD"按钮。
3. AVD 已安装成功并可投入使用：
   

优化

CPU 加速

通过使用基于英特尔 VT-x 技术的硬件虚拟化，面向 Android Jelly Bean 的英特尔凌动 x86 映像的性能将得到显著提升。

如果您的电脑使用的是支持 VT-x 技术的英特尔处理器，我们建议您在使用该系统映像时同时使用英特尔硬件加速执行管理器 (HAXM)。 有关英特尔 HAXM 的更多信息，请访问 http://www.intel.com/software/android。

注： 英特尔 HAXM 仅适用于 Windows 与 OS X 操作系统。 对于 Linux 主机，可使用基于内核的虚拟机（KVM）来提升模拟性能。 有关在 Ubuntu 上安装和配置 KVM 的更多信息，请参考：https://help.ubuntu.com/community/KVM/Installation

    
介绍

本指南在安装面向 Android* Jelly Bean 的英特尔® 凌动™ x86 映像方面提供了相关指导，该映像可用于英特尔 x86 架构上的开发。

前提条件

Android x86 模拟器映像要求安装 Android SDK。 有关安装和配置 Android SDK 的说明，请访问 Android 开发人员网站(http://developer.android.com/sdk/)。

可选: 英特尔硬件加速执行管理器 (HAXM)有助于加快面向 Android 的 X86 模拟器映像的速度。 更多信息，请见本指南中的“优化”部分。

已知问题：

• 摄像头问题： 当在 android 4.2 系统映像上录制视频时摄像头会失灵，该问题已经记录在： http://code.google.com/p/android/issues/detail?id=41227
• 浏览器问题： 浏览器与 Vista 32 位机上的模拟器会出现随机冲突 该问题已经记录在： http://code.google.com/p/android/issues/detail?id=42733
• 稳定性问题： 当一个 AVD 使用的设备 RAM 大小为 1024 时，模拟器可能会失灵。 英特尔正在调查该问题，并将进一步提供说明。

安装

手动下载

1. 转至 http://www.intel.com/software/android。
2. 下载英特尔 x86 凌动系统映像。
   
   转至 Android SDK 所在的目录。 就 Windows 而言，该目录会有所不同，这取决于您在安装它时选择的是 "anyone using this computer（使用本电脑的任何人）"还是 "just for me（只为我）"。 如果您是针对“每个人”安装，那么它在一台 64 位 Windows 机器上的位置应该是 "c:\Program Files (x86)\android"如果您选择的是“just for me”，那么它应该位于 "c:\users\<username>\AppData\local\android"。 在一台 mac 机上，它通常安装在 "/home/<username>/Desktop/android-sdk-macosx/"。 以下使用说明和屏幕截图适用于 "just for me" windows 安装，但是文件需要解压到与 Android 安装时采用的路径一致的相对路径（无论是在 Windows 上还是在 Mac 上）
   
   
3. system-images目录中包含按架构划分的 Android 系统映像： 如果不存在适用于 API level 17 的 "android-17"目录，您就需要创建该目录。
   
   
4. 展开android-17 (此目录中包含 API Level 17 系统映像)：
   
   
5. 将已下载系统映像文件中包含的 x86目录直接解压到 android-17 目录中。 该目录结构应当包含以下文件：
   
   
6. 系统映像已成功安装并可投入使用。

使用系统映像

1. 启动 Android AVD 管理器并创建一个新的 AVD，将 "Target"设置为 "Android 4.2 – API Level 17"，同时将 "CPU/ABI"设置为 "Intel Atom (x86)"。

   面向 Android Jelly Bean 的英特尔凌动 x86 映像能利用硬件 GPU 特性来提高游戏、图形密集型项目以及用户界面相关元素的性能。 如果想获得最佳性能，请务必在创建映像时选中 "Use Host GPU"复选框。

   注： GPU 加速的功能性和性能在很大程度上取决于您电脑上的显卡和显卡驱动程序。 GPU 加速必须在单个 AVD 上分别启用。
   
   

   注： 如果 "Intel Atom (x86)" CPU/ABI 选项无法使用，请确认系统映像是否已正确安装。

2. 点击 "Create AVD"按钮。
3. AVD 已安装成功并可投入使用：
   
   

优化

CPU 加速

通过使用基于英特尔 VT-x 技术的硬件虚拟化，面向 Android Jelly Bean 的英特尔凌动 x86 映像的性能将得到显著提升。

如果您的电脑使用的是支持 VT-x 技术的英特尔处理器，我们建议您在使用该系统映像时同时使用英特尔硬件加速执行管理器 (HAXM)。 有关英特尔 HAXM 的更多信息，请访问 http://www.intel.com/software/android。

注： 英特尔 HAXM 仅适用于 Windows 与 OS X 操作系统。 对于 Linux 主机，可使用基于内核的虚拟机（KVM）来提升模拟性能。 有关在 Ubuntu 上安装和配置 KVM 的更多信息，请参考： https://help.ubuntu.com/community/KVM/Installation

<sub>版权所有 (C) 2013 英特尔公司。 保留所有权利。
英特尔、Intel 标识、Atom 和凌动是英特尔公司在美国和其他国家（地区）的商标。
此处涉及的所有产品、计算机系统、日期和数字信息均为依据当前期望得出的初步结果，可随时更改，恕不另行通知。
* 其它名称和品牌可能是各自所有者的财产。</sub>

    
本文将针对英特尔® Android USB 驱动程序包如何安装问题为您提供指导。借助该程序包，您可以将基于 Windows* 的机器连接至安装了英特尔凌动™ 处理器的 Android 设备上。

系统要求

硬件要求：
安装有英特尔凌动处理器 Z2460 的 Android 移动设备。
一根 USB-USB 微缆（用于为设备充电的同一根电缆）

支持的主机操作系统：
Windows 7 (32/64 位)
Windows Vista (32/64 位)
Windows XP (仅限 32 位)

支持的 Android 设备操作系统：
Android 2.3.7 – Gingerbread (GB)
Android 4.0.x – Ice Cream Sandwich (ICS)

安装步骤

警告： 确保安装过程中您的 Android 设备没有连接到您的电脑上。

1. 从 http://www.intel.com/software/android下载安装程序包
2. 运行安装程序，并接受“Windows User Account Control (UAC)”提示（如适用）。
3. 您会看到如下屏幕。 单击“Next”继续。 （如果安装程序发现存在较老的驱动程序版本，请接受卸载该版本。）

4. 您会看到如下屏幕。 阅读并接受《英特尔 Android USB 驱动程序最终用户许可协议》(EULA)。

5. 系统将提示您选择以下屏幕上显示的组件。 单击“Next”按钮继续。

6. 选择安装路径并单击“Install”。

7. 安装程序将继续安装 Android USB 驱动程序。 这个过程可能需要几分钟的时间。

8. 驱动程序安装完成后，请单击弹出通知上的“OK”，然后单击“Finish”以关闭安装程序。

支持的 USB 配置

安装完 USB 驱动程序包后，请使用您的 USB-USB 微缆将您的 Android 设备连接至电脑。 以下是英特尔 Android USB 驱动程序包支持的 USB 配置：

• ADB（Android 调试桥）：这是 Android 的调试接口。 ise 由于需要重新刷新和调试，因此必须选择此接口。
  要启用/禁用此协议：
  • ICS： Settings > Developer options > USB Debugging
  • GB： Settings > Applications > Development > USB Debugging

• MTP（媒体传输协议）：这是用于传输媒体文件的 Windows 协议。
  要启用/禁用此协议：
  • ICS： Settings > Storage > Click context menu > USB Computer connection > MTP

• PTP（图片传输协议）：这是用于将图像从数码相机传输至电脑的 Windows 协议。
  要启用/禁用此协议：
  • ICS： Settings > Storage > Click context menu > USB Computer connection > PTP

• RNDIS:此功能提供了一种使用电话网络的虚拟以太网链接。
  要启用/禁用此功能：
  • ICS： Settings > More… > Tethering and portable hostpot > USB tethering
  • GB: Settings > Wireless & Network > Tethering and portable hostpot > USB tethering

• CDC 串口（调制解调器 AT 代理）：此功能提供了通往调制解调器的链接，支持通过虚拟 com 端口使用 AT 命令：
  • GB:启动 adb 外壳。 (http://developer.android.com/guide/developing/tools/adb.html#shellcommands)
    • 启用： setprop persist.ril-daemon.disable 0
    • 禁用： setprop persist.ril-daemon.disable 1
  • ICS:启动 adb 外壳。 (http://developer.android.com/guide/developing/tools/adb.html#shellcommands)
    • 启用： setprop persist.system.at-proxy.mode 1
    • 禁用： setprop persist.system.at-proxy.mode 0

故障排除

如果设备未被识别为一个 Android 设备，请遵循以下步骤解决该问题。

检查 Windows Device Manager（Windows 设备管理器）
打开 Windows Device Manager:

1. 您看到的可能是 USB Mass Storage（USB 大容量存储），而不是 ADB Device（ADB 设备）。 如果是前者，请右键单击“Mass Storage device”图标并选择“Uninstall”。 然后从电脑中拔出设备并再次安装驱动程序
2. 您可能会看到 带有黄色警告图标的 Android 设备。 在这种情况下，请右键单击“Android Device”图标并选择“Uninstall”。 然后从电脑中拔出设备并再次安装驱动程序

Enable USB debugging（启用 USB 调试）
确保您尝试连接的设备已经启用 USB 调试。

在 Android 2.3 (Gingerbread) 设备中，该选项位于Settings > Applications > Development下。

在 Android 4.0.x (Ice Cream Sandwich) 设备中，该选项位于Settings > Development Options下。

Further Questions & Support（更多问题及支持）
如欲获得其他有关故障排除的支持，请在英特尔支持论坛上向 Android 开发人员提出问题： (http://www.intel.com/software/android)