changeset 9066 c2af3ff967cc
parent 9065 c8a8b11fd0ad
child 10092 f1949a74dce5
--- a/docs/	Fri Aug 15 23:18:57 2014 +0200
+++ b/docs/	Fri Aug 15 23:39:14 2014 +0200
@@ -18,9 +18,9 @@
 - Android applications are Java-based, optionally with parts written in C
 - As SDL apps are C-based, we use a small Java shim that uses JNI to talk to 
-the SDL library
+  the SDL library
 - This means that your application C code must be placed inside an Android 
-Java project, along with some C support code that communicates with Java
+  Java project, along with some C support code that communicates with Java
 - This eventually produces a standard Android .apk package
 The Android Java code implements an "Activity" and can be found in:
@@ -42,15 +42,15 @@
 There's two ways of using it: com.yourcompany.yourapp < sources.list com.yourcompany.yourapp source1.c source2.c ...sourceN.c
+ com.yourcompany.yourapp < sources.list
+ com.yourcompany.yourapp source1.c source2.c ...sourceN.c
 sources.list should be a text file with a source file name in each line
 Filenames should be specified relative to the current directory, for example if
 you are in the build-scripts directory and want to create the testgles.c test, you'll
-./ org.libsdl.testgles ../test/testgles.c
+    ./ org.libsdl.testgles ../test/testgles.c
 One limitation of this script is that all sources provided will be aggregated into
 a single directory, thus all your source files should have a unique name.
@@ -74,7 +74,9 @@
 If you want to use the Eclipse IDE, skip to the Eclipse section below.
 5. Create <project>/ and use that to point to the Android SDK directory, by writing a line with the following form:
+       sdk.dir=PATH_TO_ANDROID_SDK
 6. Run 'ant debug' in android/project. This compiles the .java and eventually 
    creates a .apk with the native code embedded
 7. 'ant debug install' will push the apk to the device or emulator (if connected)
@@ -125,7 +127,7 @@
 4. create and export an environment variable named NDK_MODULE_PATH that points
    to the parent directory of this SDL directory. e.g.:
-   export NDK_MODULE_PATH="$PWD"/..
+       export NDK_MODULE_PATH="$PWD"/..
 5. Edit <project>/src/org/libsdl/app/ and remove the call to
@@ -142,7 +144,7 @@
 Then create a Java class extending SDLActivity and place it in a directory
 under src matching your package, e.g.
-	src/com/gamemaker/game/
+    src/com/gamemaker/game/
 Here's an example of a minimal class file:
@@ -184,9 +186,9 @@
 There are also a few Android specific functions that allow you to get other
 useful paths for saving and loading data:
+* SDL_AndroidGetInternalStoragePath()
+* SDL_AndroidGetExternalStorageState()
+* SDL_AndroidGetExternalStoragePath()
 See SDL_system.h for more details on these functions.
@@ -228,6 +230,7 @@
 For a quick tour on how Linux native threads interoperate with the Java VM, take
 a look here:
 If you want to use threads in your SDL app, it's strongly recommended that you
 do so by creating them using SDL functions. This way, the required attach/detach
 handling is managed by SDL automagically. If you have threads created by other
@@ -242,7 +245,8 @@
 You can use STL in your project by creating an file in the jni
 folder and adding the following line:
-APP_STL := stlport_static
+    APP_STL := stlport_static
 For more information check out CPLUSPLUS-SUPPORT.html in the NDK documentation.
@@ -293,39 +297,39 @@
 You can see if adb can see any devices with the following command:
-	adb devices
+    adb devices
 You can see the output of log messages on the default device with:
-	adb logcat
+    adb logcat
 You can push files to the device with:
-	adb push local_file remote_path_and_file
+    adb push local_file remote_path_and_file
 You can push files to the SD Card at /sdcard, for example:
-	adb push moose.dat /sdcard/moose.dat
+    adb push moose.dat /sdcard/moose.dat
 You can see the files on the SD card with a shell command:
-	adb shell ls /sdcard/
+    adb shell ls /sdcard/
 You can start a command shell on the default device with:
-	adb shell
+    adb shell
 You can remove the library files of your project (and not the SDL lib files) with:
-	ndk-build clean
+    ndk-build clean
 You can do a build with the following command:
-	ndk-build
+    ndk-build
 You can see the complete command line that ndk-build is using by passing V=1 on the command line:
-	ndk-build V=1
+    ndk-build V=1
 If your application crashes in native code, you can use addr2line to convert the
 addresses in the stack trace to lines in your code.
@@ -345,7 +349,7 @@
 You can see that there's a crash in the C library being called from the main code.
 I run addr2line with the debug version of my code:
-	arm-eabi-addr2line -C -f -e obj/local/armeabi/
+    arm-eabi-addr2line -C -f -e obj/local/armeabi/
 and then paste in the number after "pc" in the call stack, from the line that I care about:
@@ -360,7 +364,8 @@
 If you need to build without optimization turned on, you can create a file called
 "" in the jni directory, with the following line in it:
-APP_OPTIM := debug
+    APP_OPTIM := debug
@@ -370,7 +375,7 @@
 The best (and slowest) way to debug memory issues on Android is valgrind.
 Valgrind has support for Android out of the box, just grab code using:
-	svn co svn:// valgrind
+    svn co svn:// valgrind
 ... and follow the instructions in the file to build it.
@@ -389,15 +394,15 @@
 Then push it to the device:
-	adb push start_valgrind_app /data/local
+    adb push start_valgrind_app /data/local
 and make it executable:
-	adb shell chmod 755 /data/local/start_valgrind_app
+    adb shell chmod 755 /data/local/start_valgrind_app
 and tell Android to use the script to launch your application:
-	adb shell setprop "logwrapper /data/local/start_valgrind_app"
+    adb shell setprop "logwrapper /data/local/start_valgrind_app"
 If the setprop command says "could not set property", it's likely that
 your package name is too long and you should make it shorter by changing
@@ -408,11 +413,11 @@
 when it's done (or even while it's running) you can grab the valgrind
 output file:
-	adb pull /sdcard/valgrind.log
+    adb pull /sdcard/valgrind.log
 When you're done instrumenting with valgrind, you can disable the wrapper:
-	adb shell setprop ""
+    adb shell setprop ""
  Why is API level 10 the minimum required?