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