doc/README-android.md
author Gabriel Jacobo <gabomdq@gmail.com>
Tue, 29 Jul 2014 09:20:12 -0300
changeset 9023 276802355854
permissions -rw-r--r--
Rearrange documentation

1) Moves all READMEs to docs/
2) Renames them to *.md, adds some Markdown with the idea to add a lot more
3) Moves the doxyfile config to doc/ and makes it parse the headers at ../include as well as the md files in docs.
4) Skips SDL_opengl*.h headers from the docs
5) Minor fixes to doxyfile
gabomdq@9023
     1
Android
gabomdq@9023
     2
================================================================================
gabomdq@9023
     3
gabomdq@9023
     4
Requirements:
gabomdq@9023
     5
gabomdq@9023
     6
Android SDK (version 12 or later)
gabomdq@9023
     7
http://developer.android.com/sdk/index.html
gabomdq@9023
     8
gabomdq@9023
     9
Android NDK r7 or later
gabomdq@9023
    10
http://developer.android.com/tools/sdk/ndk/index.html
gabomdq@9023
    11
gabomdq@9023
    12
Minimum API level supported by SDL: 10 (Android 2.3.3)
gabomdq@9023
    13
Joystick support is available for API level >=12 devices.
gabomdq@9023
    14
gabomdq@9023
    15
================================================================================
gabomdq@9023
    16
 How the port works
gabomdq@9023
    17
================================================================================
gabomdq@9023
    18
gabomdq@9023
    19
- Android applications are Java-based, optionally with parts written in C
gabomdq@9023
    20
- As SDL apps are C-based, we use a small Java shim that uses JNI to talk to 
gabomdq@9023
    21
the SDL library
gabomdq@9023
    22
- This means that your application C code must be placed inside an Android 
gabomdq@9023
    23
Java project, along with some C support code that communicates with Java
gabomdq@9023
    24
- This eventually produces a standard Android .apk package
gabomdq@9023
    25
gabomdq@9023
    26
The Android Java code implements an "Activity" and can be found in:
gabomdq@9023
    27
android-project/src/org/libsdl/app/SDLActivity.java
gabomdq@9023
    28
gabomdq@9023
    29
The Java code loads your game code, the SDL shared library, and
gabomdq@9023
    30
dispatches to native functions implemented in the SDL library:
gabomdq@9023
    31
src/core/android/SDL_android.c
gabomdq@9023
    32
gabomdq@9023
    33
Your project must include some glue code that starts your main() routine:
gabomdq@9023
    34
src/main/android/SDL_android_main.c
gabomdq@9023
    35
gabomdq@9023
    36
gabomdq@9023
    37
================================================================================
gabomdq@9023
    38
 Building an app
gabomdq@9023
    39
================================================================================
gabomdq@9023
    40
gabomdq@9023
    41
For simple projects you can use the script located at build-scripts/androidbuild.sh
gabomdq@9023
    42
gabomdq@9023
    43
There's two ways of using it:
gabomdq@9023
    44
gabomdq@9023
    45
androidbuild.sh com.yourcompany.yourapp < sources.list
gabomdq@9023
    46
androidbuild.sh com.yourcompany.yourapp source1.c source2.c ...sourceN.c
gabomdq@9023
    47
gabomdq@9023
    48
sources.list should be a text file with a source file name in each line
gabomdq@9023
    49
Filenames should be specified relative to the current directory, for example if
gabomdq@9023
    50
you are in the build-scripts directory and want to create the testgles.c test, you'll
gabomdq@9023
    51
run:
gabomdq@9023
    52
    
gabomdq@9023
    53
./androidbuild.sh org.libsdl.testgles ../test/testgles.c
gabomdq@9023
    54
gabomdq@9023
    55
One limitation of this script is that all sources provided will be aggregated into
gabomdq@9023
    56
a single directory, thus all your source files should have a unique name.
gabomdq@9023
    57
gabomdq@9023
    58
Once the project is complete the script will tell you where the debug APK is located.
gabomdq@9023
    59
If you want to create a signed release APK, you can use the project created by this
gabomdq@9023
    60
utility to generate it.
gabomdq@9023
    61
gabomdq@9023
    62
Finally, a word of caution: re running androidbuild.sh wipes any changes you may have
gabomdq@9023
    63
done in the build directory for the app!
gabomdq@9023
    64
gabomdq@9023
    65
gabomdq@9023
    66
For more complex projects, follow these instructions:
gabomdq@9023
    67
    
gabomdq@9023
    68
1. Copy the android-project directory wherever you want to keep your projects
gabomdq@9023
    69
   and rename it to the name of your project.
gabomdq@9023
    70
2. Move or symlink this SDL directory into the <project>/jni directory
gabomdq@9023
    71
3. Edit <project>/jni/src/Android.mk to include your source files
gabomdq@9023
    72
4. Run 'ndk-build' (a script provided by the NDK). This compiles the C source
gabomdq@9023
    73
gabomdq@9023
    74
If you want to use the Eclipse IDE, skip to the Eclipse section below.
gabomdq@9023
    75
gabomdq@9023
    76
5. Create <project>/local.properties and use that to point to the Android SDK directory, by writing a line with the following form:
gabomdq@9023
    77
sdk.dir=PATH_TO_ANDROID_SDK
gabomdq@9023
    78
6. Run 'ant debug' in android/project. This compiles the .java and eventually 
gabomdq@9023
    79
   creates a .apk with the native code embedded
gabomdq@9023
    80
7. 'ant debug install' will push the apk to the device or emulator (if connected)
gabomdq@9023
    81
gabomdq@9023
    82
Here's an explanation of the files in the Android project, so you can customize them:
gabomdq@9023
    83
gabomdq@9023
    84
android-project/
gabomdq@9023
    85
	AndroidManifest.xml	- package manifest. Among others, it contains the class name
gabomdq@9023
    86
				  of the main Activity and the package name of the application.
gabomdq@9023
    87
	build.properties	- empty
gabomdq@9023
    88
	build.xml		- build description file, used by ant. The actual application name
gabomdq@9023
    89
				  is specified here.
gabomdq@9023
    90
	default.properties	- holds the target ABI for the application, android-10 and up
gabomdq@9023
    91
	project.properties	- holds the target ABI for the application, android-10 and up
gabomdq@9023
    92
	local.properties	- holds the SDK path, you should change this to the path to your SDK
gabomdq@9023
    93
	jni/			- directory holding native code
gabomdq@9023
    94
	jni/Android.mk		- Android makefile that can call recursively the Android.mk files
gabomdq@9023
    95
				  in all subdirectories
gabomdq@9023
    96
	jni/SDL/		- (symlink to) directory holding the SDL library files
gabomdq@9023
    97
	jni/SDL/Android.mk	- Android makefile for creating the SDL shared library
gabomdq@9023
    98
	jni/src/		- directory holding your C/C++ source
gabomdq@9023
    99
	jni/src/Android.mk	- Android makefile that you should customize to include your 
gabomdq@9023
   100
                                  source code and any library references
gabomdq@9023
   101
	res/			- directory holding resources for your application
gabomdq@9023
   102
	res/drawable-*		- directories holding icons for different phone hardware. Could be
gabomdq@9023
   103
				  one dir called "drawable".
gabomdq@9023
   104
	res/layout/main.xml	- Usually contains a file main.xml, which declares the screen layout.
gabomdq@9023
   105
				  We don't need it because we use the SDL video output.
gabomdq@9023
   106
	res/values/strings.xml	- strings used in your application, including the application name
gabomdq@9023
   107
				  shown on the phone.
gabomdq@9023
   108
	src/org/libsdl/app/SDLActivity.java - the Java class handling the initialization and binding
gabomdq@9023
   109
				  to SDL.  Be very careful changing this, as the SDL library relies
gabomdq@9023
   110
				  on this implementation.
gabomdq@9023
   111
gabomdq@9023
   112
gabomdq@9023
   113
================================================================================
gabomdq@9023
   114
 Build an app with static linking of libSDL
gabomdq@9023
   115
================================================================================
gabomdq@9023
   116
gabomdq@9023
   117
This build uses the Android NDK module system.
gabomdq@9023
   118
gabomdq@9023
   119
Instructions:
gabomdq@9023
   120
1. Copy the android-project directory wherever you want to keep your projects
gabomdq@9023
   121
   and rename it to the name of your project.
gabomdq@9023
   122
2. Rename <project>/jni/src/Android_static.mk to <project>/jni/src/Android.mk
gabomdq@9023
   123
   (overwrite the existing one)
gabomdq@9023
   124
3. Edit <project>/jni/src/Android.mk to include your source files
gabomdq@9023
   125
4. create and export an environment variable named NDK_MODULE_PATH that points
gabomdq@9023
   126
   to the parent directory of this SDL directory. e.g.:
gabomdq@9023
   127
gabomdq@9023
   128
   export NDK_MODULE_PATH="$PWD"/..
gabomdq@9023
   129
gabomdq@9023
   130
5. Edit <project>/src/org/libsdl/app/SDLActivity.java and remove the call to
gabomdq@9023
   131
   System.loadLibrary("SDL2") line 42.
gabomdq@9023
   132
6. Run 'ndk-build' (a script provided by the NDK). This compiles the C source
gabomdq@9023
   133
gabomdq@9023
   134
gabomdq@9023
   135
================================================================================
gabomdq@9023
   136
 Customizing your application name
gabomdq@9023
   137
================================================================================
gabomdq@9023
   138
gabomdq@9023
   139
To customize your application name, edit AndroidManifest.xml and replace
gabomdq@9023
   140
"org.libsdl.app" with an identifier for your product package.
gabomdq@9023
   141
gabomdq@9023
   142
Then create a Java class extending SDLActivity and place it in a directory
gabomdq@9023
   143
under src matching your package, e.g.
gabomdq@9023
   144
	src/com/gamemaker/game/MyGame.java
gabomdq@9023
   145
gabomdq@9023
   146
Here's an example of a minimal class file:
gabomdq@9023
   147
--- MyGame.java --------------------------
gabomdq@9023
   148
package com.gamemaker.game;
gabomdq@9023
   149
gabomdq@9023
   150
import org.libsdl.app.SDLActivity; 
gabomdq@9023
   151
gabomdq@9023
   152
/* 
gabomdq@9023
   153
 * A sample wrapper class that just calls SDLActivity 
gabomdq@9023
   154
 */ 
gabomdq@9023
   155
gabomdq@9023
   156
public class MyGame extends SDLActivity { }
gabomdq@9023
   157
gabomdq@9023
   158
------------------------------------------
gabomdq@9023
   159
gabomdq@9023
   160
Then replace "SDLActivity" in AndroidManifest.xml with the name of your
gabomdq@9023
   161
class, .e.g. "MyGame"
gabomdq@9023
   162
gabomdq@9023
   163
================================================================================
gabomdq@9023
   164
 Customizing your application icon
gabomdq@9023
   165
================================================================================
gabomdq@9023
   166
gabomdq@9023
   167
Conceptually changing your icon is just replacing the "ic_launcher.png" files in
gabomdq@9023
   168
the drawable directories under the res directory. There are four directories for
gabomdq@9023
   169
different screen sizes. These can be replaced with one dir called "drawable",
gabomdq@9023
   170
containing an icon file "ic_launcher.png" with dimensions 48x48 or 72x72.
gabomdq@9023
   171
gabomdq@9023
   172
You may need to change the name of your icon in AndroidManifest.xml to match
gabomdq@9023
   173
this icon filename.
gabomdq@9023
   174
gabomdq@9023
   175
================================================================================
gabomdq@9023
   176
 Loading assets
gabomdq@9023
   177
================================================================================
gabomdq@9023
   178
gabomdq@9023
   179
Any files you put in the "assets" directory of your android-project directory
gabomdq@9023
   180
will get bundled into the application package and you can load them using the
gabomdq@9023
   181
standard functions in SDL_rwops.h.
gabomdq@9023
   182
gabomdq@9023
   183
There are also a few Android specific functions that allow you to get other
gabomdq@9023
   184
useful paths for saving and loading data:
gabomdq@9023
   185
SDL_AndroidGetInternalStoragePath()
gabomdq@9023
   186
SDL_AndroidGetExternalStorageState()
gabomdq@9023
   187
SDL_AndroidGetExternalStoragePath()
gabomdq@9023
   188
gabomdq@9023
   189
See SDL_system.h for more details on these functions.
gabomdq@9023
   190
gabomdq@9023
   191
The asset packaging system will, by default, compress certain file extensions.
gabomdq@9023
   192
SDL includes two asset file access mechanisms, the preferred one is the so
gabomdq@9023
   193
called "File Descriptor" method, which is faster and doesn't involve the Dalvik
gabomdq@9023
   194
GC, but given this method does not work on compressed assets, there is also the
gabomdq@9023
   195
"Input Stream" method, which is automatically used as a fall back by SDL. You
gabomdq@9023
   196
may want to keep this fact in mind when building your APK, specially when large
gabomdq@9023
   197
files are involved.
gabomdq@9023
   198
For more information on which extensions get compressed by default and how to
gabomdq@9023
   199
disable this behaviour, see for example:
gabomdq@9023
   200
    
gabomdq@9023
   201
http://ponystyle.com/blog/2010/03/26/dealing-with-asset-compression-in-android-apps/
gabomdq@9023
   202
gabomdq@9023
   203
================================================================================
gabomdq@9023
   204
 Pause / Resume behaviour
gabomdq@9023
   205
================================================================================
gabomdq@9023
   206
gabomdq@9023
   207
If SDL is compiled with SDL_ANDROID_BLOCK_ON_PAUSE defined (the default),
gabomdq@9023
   208
the event loop will block itself when the app is paused (ie, when the user
gabomdq@9023
   209
returns to the main Android dashboard). Blocking is better in terms of battery
gabomdq@9023
   210
use, and it allows your app to spring back to life instantaneously after resume
gabomdq@9023
   211
(versus polling for a resume message).
gabomdq@9023
   212
gabomdq@9023
   213
Upon resume, SDL will attempt to restore the GL context automatically.
gabomdq@9023
   214
In modern devices (Android 3.0 and up) this will most likely succeed and your
gabomdq@9023
   215
app can continue to operate as it was.
gabomdq@9023
   216
gabomdq@9023
   217
However, there's a chance (on older hardware, or on systems under heavy load),
gabomdq@9023
   218
where the GL context can not be restored. In that case you have to listen for
gabomdq@9023
   219
a specific message, (which is not yet implemented!) and restore your textures
gabomdq@9023
   220
manually or quit the app (which is actually the kind of behaviour you'll see
gabomdq@9023
   221
under iOS, if the OS can not restore your GL context it will just kill your app)
gabomdq@9023
   222
gabomdq@9023
   223
================================================================================
gabomdq@9023
   224
 Threads and the Java VM
gabomdq@9023
   225
================================================================================
gabomdq@9023
   226
gabomdq@9023
   227
For a quick tour on how Linux native threads interoperate with the Java VM, take
gabomdq@9023
   228
a look here: http://developer.android.com/guide/practices/jni.html
gabomdq@9023
   229
If you want to use threads in your SDL app, it's strongly recommended that you
gabomdq@9023
   230
do so by creating them using SDL functions. This way, the required attach/detach
gabomdq@9023
   231
handling is managed by SDL automagically. If you have threads created by other
gabomdq@9023
   232
means and they make calls to SDL functions, make sure that you call
gabomdq@9023
   233
Android_JNI_SetupThread before doing anything else otherwise SDL will attach
gabomdq@9023
   234
your thread automatically anyway (when you make an SDL call), but it'll never
gabomdq@9023
   235
detach it.
gabomdq@9023
   236
gabomdq@9023
   237
================================================================================
gabomdq@9023
   238
 Using STL
gabomdq@9023
   239
================================================================================
gabomdq@9023
   240
gabomdq@9023
   241
You can use STL in your project by creating an Application.mk file in the jni
gabomdq@9023
   242
folder and adding the following line:
gabomdq@9023
   243
APP_STL := stlport_static
gabomdq@9023
   244
gabomdq@9023
   245
For more information check out CPLUSPLUS-SUPPORT.html in the NDK documentation.
gabomdq@9023
   246
gabomdq@9023
   247
================================================================================
gabomdq@9023
   248
 Additional documentation
gabomdq@9023
   249
================================================================================
gabomdq@9023
   250
gabomdq@9023
   251
The documentation in the NDK docs directory is very helpful in understanding the
gabomdq@9023
   252
build process and how to work with native code on the Android platform.
gabomdq@9023
   253
gabomdq@9023
   254
The best place to start is with docs/OVERVIEW.TXT
gabomdq@9023
   255
gabomdq@9023
   256
gabomdq@9023
   257
================================================================================
gabomdq@9023
   258
 Using Eclipse
gabomdq@9023
   259
================================================================================
gabomdq@9023
   260
gabomdq@9023
   261
First make sure that you've installed Eclipse and the Android extensions as described here:
gabomdq@9023
   262
	http://developer.android.com/tools/sdk/eclipse-adt.html
gabomdq@9023
   263
gabomdq@9023
   264
Once you've copied the SDL android project and customized it, you can create an Eclipse project from it:
gabomdq@9023
   265
 * File -> New -> Other
gabomdq@9023
   266
 * Select the Android -> Android Project wizard and click Next
gabomdq@9023
   267
 * Enter the name you'd like your project to have
gabomdq@9023
   268
 * Select "Create project from existing source" and browse for your project directory
gabomdq@9023
   269
 * Make sure the Build Target is set to Android 2.0
gabomdq@9023
   270
 * Click Finish
gabomdq@9023
   271
gabomdq@9023
   272
gabomdq@9023
   273
================================================================================
gabomdq@9023
   274
 Using the emulator
gabomdq@9023
   275
================================================================================
gabomdq@9023
   276
gabomdq@9023
   277
There are some good tips and tricks for getting the most out of the
gabomdq@9023
   278
emulator here: http://developer.android.com/tools/devices/emulator.html
gabomdq@9023
   279
gabomdq@9023
   280
Especially useful is the info on setting up OpenGL ES 2.0 emulation.
gabomdq@9023
   281
gabomdq@9023
   282
Notice that this software emulator is incredibly slow and needs a lot of disk space.
gabomdq@9023
   283
Using a real device works better.
gabomdq@9023
   284
gabomdq@9023
   285
================================================================================
gabomdq@9023
   286
 Troubleshooting
gabomdq@9023
   287
================================================================================
gabomdq@9023
   288
gabomdq@9023
   289
You can create and run an emulator from the Eclipse IDE:
gabomdq@9023
   290
 * Window -> Android SDK and AVD Manager
gabomdq@9023
   291
gabomdq@9023
   292
You can see if adb can see any devices with the following command:
gabomdq@9023
   293
	adb devices
gabomdq@9023
   294
gabomdq@9023
   295
You can see the output of log messages on the default device with:
gabomdq@9023
   296
	adb logcat
gabomdq@9023
   297
gabomdq@9023
   298
You can push files to the device with:
gabomdq@9023
   299
	adb push local_file remote_path_and_file
gabomdq@9023
   300
gabomdq@9023
   301
You can push files to the SD Card at /sdcard, for example:
gabomdq@9023
   302
	adb push moose.dat /sdcard/moose.dat
gabomdq@9023
   303
gabomdq@9023
   304
You can see the files on the SD card with a shell command:
gabomdq@9023
   305
	adb shell ls /sdcard/
gabomdq@9023
   306
gabomdq@9023
   307
You can start a command shell on the default device with:
gabomdq@9023
   308
	adb shell
gabomdq@9023
   309
gabomdq@9023
   310
You can remove the library files of your project (and not the SDL lib files) with:
gabomdq@9023
   311
	ndk-build clean
gabomdq@9023
   312
gabomdq@9023
   313
You can do a build with the following command:
gabomdq@9023
   314
	ndk-build
gabomdq@9023
   315
gabomdq@9023
   316
You can see the complete command line that ndk-build is using by passing V=1 on the command line:
gabomdq@9023
   317
	ndk-build V=1
gabomdq@9023
   318
gabomdq@9023
   319
If your application crashes in native code, you can use addr2line to convert the
gabomdq@9023
   320
addresses in the stack trace to lines in your code.
gabomdq@9023
   321
gabomdq@9023
   322
For example, if your crash looks like this:
gabomdq@9023
   323
I/DEBUG   (   31): signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 400085d0
gabomdq@9023
   324
I/DEBUG   (   31):  r0 00000000  r1 00001000  r2 00000003  r3 400085d4
gabomdq@9023
   325
I/DEBUG   (   31):  r4 400085d0  r5 40008000  r6 afd41504  r7 436c6a7c
gabomdq@9023
   326
I/DEBUG   (   31):  r8 436c6b30  r9 435c6fb0  10 435c6f9c  fp 4168d82c
gabomdq@9023
   327
I/DEBUG   (   31):  ip 8346aff0  sp 436c6a60  lr afd1c8ff  pc afd1c902  cpsr 60000030
gabomdq@9023
   328
I/DEBUG   (   31):          #00  pc 0001c902  /system/lib/libc.so
gabomdq@9023
   329
I/DEBUG   (   31):          #01  pc 0001ccf6  /system/lib/libc.so
gabomdq@9023
   330
I/DEBUG   (   31):          #02  pc 000014bc  /data/data/org.libsdl.app/lib/libmain.so
gabomdq@9023
   331
I/DEBUG   (   31):          #03  pc 00001506  /data/data/org.libsdl.app/lib/libmain.so
gabomdq@9023
   332
gabomdq@9023
   333
You can see that there's a crash in the C library being called from the main code.
gabomdq@9023
   334
I run addr2line with the debug version of my code:
gabomdq@9023
   335
	arm-eabi-addr2line -C -f -e obj/local/armeabi/libmain.so
gabomdq@9023
   336
and then paste in the number after "pc" in the call stack, from the line that I care about:
gabomdq@9023
   337
000014bc
gabomdq@9023
   338
gabomdq@9023
   339
I get output from addr2line showing that it's in the quit function, in testspriteminimal.c, on line 23.
gabomdq@9023
   340
gabomdq@9023
   341
You can add logging to your code to help show what's happening:
gabomdq@9023
   342
gabomdq@9023
   343
#include <android/log.h>
gabomdq@9023
   344
gabomdq@9023
   345
	__android_log_print(ANDROID_LOG_INFO, "foo", "Something happened! x = %d", x);
gabomdq@9023
   346
gabomdq@9023
   347
If you need to build without optimization turned on, you can create a file called
gabomdq@9023
   348
"Application.mk" in the jni directory, with the following line in it:
gabomdq@9023
   349
APP_OPTIM := debug
gabomdq@9023
   350
gabomdq@9023
   351
gabomdq@9023
   352
================================================================================
gabomdq@9023
   353
 Memory debugging
gabomdq@9023
   354
================================================================================
gabomdq@9023
   355
gabomdq@9023
   356
The best (and slowest) way to debug memory issues on Android is valgrind.
gabomdq@9023
   357
Valgrind has support for Android out of the box, just grab code using:
gabomdq@9023
   358
	svn co svn://svn.valgrind.org/valgrind/trunk valgrind
gabomdq@9023
   359
... and follow the instructions in the file README.android to build it.
gabomdq@9023
   360
gabomdq@9023
   361
One thing I needed to do on Mac OS X was change the path to the toolchain,
gabomdq@9023
   362
and add ranlib to the environment variables:
gabomdq@9023
   363
export RANLIB=$NDKROOT/toolchains/arm-linux-androideabi-4.4.3/prebuilt/darwin-x86/bin/arm-linux-androideabi-ranlib
gabomdq@9023
   364
gabomdq@9023
   365
Once valgrind is built, you can create a wrapper script to launch your
gabomdq@9023
   366
application with it, changing org.libsdl.app to your package identifier:
gabomdq@9023
   367
--- start_valgrind_app -------------------
gabomdq@9023
   368
#!/system/bin/sh
gabomdq@9023
   369
export TMPDIR=/data/data/org.libsdl.app
gabomdq@9023
   370
exec /data/local/Inst/bin/valgrind --log-file=/sdcard/valgrind.log --error-limit=no $*
gabomdq@9023
   371
------------------------------------------
gabomdq@9023
   372
gabomdq@9023
   373
Then push it to the device:
gabomdq@9023
   374
	adb push start_valgrind_app /data/local
gabomdq@9023
   375
gabomdq@9023
   376
and make it executable:
gabomdq@9023
   377
	adb shell chmod 755 /data/local/start_valgrind_app
gabomdq@9023
   378
gabomdq@9023
   379
and tell Android to use the script to launch your application:
gabomdq@9023
   380
	adb shell setprop wrap.org.libsdl.app "logwrapper /data/local/start_valgrind_app"
gabomdq@9023
   381
gabomdq@9023
   382
If the setprop command says "could not set property", it's likely that
gabomdq@9023
   383
your package name is too long and you should make it shorter by changing
gabomdq@9023
   384
AndroidManifest.xml and the path to your class file in android-project/src
gabomdq@9023
   385
gabomdq@9023
   386
You can then launch your application normally and waaaaaaaiiittt for it.
gabomdq@9023
   387
You can monitor the startup process with the logcat command above, and
gabomdq@9023
   388
when it's done (or even while it's running) you can grab the valgrind
gabomdq@9023
   389
output file:
gabomdq@9023
   390
	adb pull /sdcard/valgrind.log
gabomdq@9023
   391
gabomdq@9023
   392
When you're done instrumenting with valgrind, you can disable the wrapper:
gabomdq@9023
   393
	adb shell setprop wrap.org.libsdl.app ""
gabomdq@9023
   394
gabomdq@9023
   395
================================================================================
gabomdq@9023
   396
 Why is API level 10 the minimum required?
gabomdq@9023
   397
================================================================================
gabomdq@9023
   398
gabomdq@9023
   399
API level 10 is the minimum required level at runtime (that is, on the device) 
gabomdq@9023
   400
because SDL requires some functionality for running not
gabomdq@9023
   401
available on older devices. Since the incorporation of joystick support into SDL,
gabomdq@9023
   402
the minimum SDK required to *build* SDL is version 12. Devices running API levels
gabomdq@9023
   403
10-11 are still supported, only with the joystick functionality disabled.
gabomdq@9023
   404
gabomdq@9023
   405
Support for native OpenGL ES and ES2 applications was introduced in the NDK for
gabomdq@9023
   406
API level 4 and 8. EGL was made a stable API in the NDK for API level 9, which
gabomdq@9023
   407
has since then been obsoleted, with the recommendation to developers to bump the
gabomdq@9023
   408
required API level to 10.
gabomdq@9023
   409
As of this writing, according to http://developer.android.com/about/dashboards/index.html
gabomdq@9023
   410
about 90% of the Android devices accessing Google Play support API level 10 or
gabomdq@9023
   411
higher (March 2013).
gabomdq@9023
   412
gabomdq@9023
   413
================================================================================
gabomdq@9023
   414
 A note regarding the use of the "dirty rectangles" rendering technique
gabomdq@9023
   415
================================================================================
gabomdq@9023
   416
gabomdq@9023
   417
If your app uses a variation of the "dirty rectangles" rendering technique,
gabomdq@9023
   418
where you only update a portion of the screen on each frame, you may notice a
gabomdq@9023
   419
variety of visual glitches on Android, that are not present on other platforms.
gabomdq@9023
   420
This is caused by SDL's use of EGL as the support system to handle OpenGL ES/ES2
gabomdq@9023
   421
contexts, in particular the use of the eglSwapBuffers function. As stated in the
gabomdq@9023
   422
documentation for the function "The contents of ancillary buffers are always 
gabomdq@9023
   423
undefined after calling eglSwapBuffers".
gabomdq@9023
   424
Setting the EGL_SWAP_BEHAVIOR attribute of the surface to EGL_BUFFER_PRESERVED
gabomdq@9023
   425
is not possible for SDL as it requires EGL 1.4, available only on the API level
gabomdq@9023
   426
17+, so the only workaround available on this platform is to redraw the entire
gabomdq@9023
   427
screen each frame.
gabomdq@9023
   428
gabomdq@9023
   429
Reference: http://www.khronos.org/registry/egl/specs/EGLTechNote0001.html
gabomdq@9023
   430
gabomdq@9023
   431
================================================================================
gabomdq@9023
   432
 Known issues
gabomdq@9023
   433
================================================================================
gabomdq@9023
   434
gabomdq@9023
   435
- The number of buttons reported for each joystick is hardcoded to be 36, which
gabomdq@9023
   436
is the current maximum number of buttons Android can report.
gabomdq@9023
   437