9. NDK = /cygdrive/c/ndk Las variables de entorno utilizadas por Cygwin (NDK y HOME) es mejor definirlas con el formato 'cygdrive/...' para evitar el warning que da Cygwin al usarlas.
21. Add native support Esto básicamente lo que hace es crear el proyecto C++ integrado en el proyecto Java. También añade una nueva perspectiva a Eclipse diseñada para trabajar con aplicaciones mixtas.
22. Compilar desde Eclipse Para que la parte nativa de un proyecto compile, hay que ir a sus propiedades y rellenar [Build command] dentro de [C/C++ Build]* con la siguiente instrucción: {CYGWIN}/bin/bash.exe --login -c "cd {ProjectPath} && $NDK/ndk-build 2>&1 | awk '{gsub(/{ProjectPath}/,amp;quot;amp;quot;);print}'" Esto ejecuta bash.exe y dentro, ejecuta los siguientes comandos: cd {ProjectPath} Nos posiciona en la raiz del directorio del proyecto. $NDK/ndk-build 2>&1 | awk '{gsub(/{ProjectPath}/,amp;quot;amp;quot;);print}' Ejecuta el script ndk-build el cual compila la parte nativa. Con gsub, lo que hacemos es recortar el path de los errores para que eclipse pueda ir a ellos con doble clic NOTA: No olvidéis usar los caracteres de escape en el primer parámetro de gsub. *Ha de estar en una perspectiva de C/C++ (Android Native también sirve)
28. Y en C/C++ Application, elegimos Standard Create Process Launcher
29. Esto sirve para que cuando creemos configuraciones de depuración, nos utilice ese lanzador por defecto.
30.
31. Modificar el script ndk-gdb Comentar la última linea: #$GDBCLIENT -x $GDBSETUP -e $APP_PROCESS Y la 5ª linea empezando por el final #echo "target remote :$DEBUG_PORT" >> $GDBSETUP La 1ª impide que se lance el cliente de GDB ya que vamos a usar Eclipse como cliente. Y la 2ª es para que el script no cree la linea “ target remote:5039 ” en el fichero gdb.setup . El cliente GDB de Eclipse no admite ese parámetro a través del fichero de configuración.
32. Preparar la sesión de depuración Poner un breakpoint al principio de la ejecución de la aplicación. Por ejemplo en onCreate. No interrumpáis antes de System.loadLibrary ya que si no, la librería no estará cargada y no podréis añadir breakpoints desde el CDT. Iniciar la sesión de depuración y esperar a que el punto de interrupción sea alcanzado. ¿Para que sirve esto?: Desafortunadamente, GDB sólo se puede vincular a un proceso ya activo. Por eso necesitamos que la aplicación haya arrancado y tenga un PID válido. Este método no sirve para una aplicación nativa pura, ya que no podemos pararla con un breakpoint en la máquina virtual. NOTA: Poner Debugable=true en AndroidManifest.xml
33. En este punto la aplicación está lista para que le vinculemos el GDB.
34. Vincular GDB con nuestra aplicación Abrir una sesión en la consola de Cygwin. Esta sesión conviene no cerrarla para futuras depuraciones. cd {ProjectPath} Desde el directorio de nuestra aplicación, ejecutar el script: $NDK/ndk-gdb Esto, entre otras cosas, arrancará GDB y lo vinculará a nuestra aplicación.
35. Configurar el cliente GDB en Eclipse para este proyecto (sólo se hace la 1ª vez) Primero hemos de crear una configuración de depuración para nuestro proyecto. Vamos al menú Run y Debug Configurations... En C/C++ Application, botón derecho -> New. En la pestaña Main: En el campo C/C++ Aplication, ponemos: {ProjectPath}/obj/local/armeabi/app_process Este fichero lo crea el script ndk-gdb, así que si no lo hemos ejecutado con éxito, no estará. Seleccionamos “Disable auto build” ya que cuando iniciemos la sesión de depuración, la aplicación ya la tenemos compilada y corriendo. (Aunque parada en un VM Breakpoint)
36.
37. En la pestaña Debugger: Elegimos gdbserver como Debugger y desmarcamos la casilla: [X] Stop on startup at: En la subpestaña Main: En el campo GDB debugger, ponemos: {NDK}/toolchains/arm-eabi-4.4.0/prebuilt/windows/bin/arm-eabi-gdb En el campo GDB command file, ponemos: {ProjectPath}/obj/local/armeabi/gdb.setup Y marcamos la casilla: [X] Verbose console mode En la subpestaña Connection: Type: TCP Host name or IP address: localhost Port number: 5039