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