docs/README-android.md
author Philipp Wiesemann <philipp.wiesemann@arcor.de>
Sat, 14 Feb 2015 00:16:27 +0100
changeset 9344 83f4ab8fb0b8
parent 9066 c2af3ff967cc
child 10092 f1949a74dce5
permissions -rw-r--r--
Emscripten: Fixed throwing JavaScript exception if no audio context available.

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