The Android Software Developer Kit is what you use to develop Android applications. You get it from here.
GUI Versus Command Line
Most developers seem to prefer GUI tools. However, this makes it difficult to choose different IDEs or text editors. Also sometimes more complex builds require the execution of custom scripts at build time, and only the command line offers the flexibility to cope with this.
Android apps do not have to be written entirely in Java. It is possible to include C/C++ code and compile it with the Native Development Kit (NDK). This code then interfaces with the Java code through the Java Native Interface (JNI), of which the Dalvik virtual machine includes a (mostly) complete implementation.
When you might want to use the NDK:
- Port C/C++ code from another platform.
- Java code is too slow—but beware: “premature optimization is the root of all evil” (variously attributed to Donald Knuth or Tony Hoare). Do actual testing to determine where the slow parts of your code are, before trying to speed them up: the performance bottlenecks are often not where you think they are.
- Allocate more memory than the 20MB or so permitted for your Java heap.
Reasons not to use the NDK:
- Your compiled code ends up being architecture-specific. Sure, you can include alternative versions for, say, both ARM and MIPS to cover the likely bases for now, but what happens if Intel’s Atom efforts pay off, and future devices make more use of x86 chips?
- Debugging is hard. Instead of seeing a nice Java exception traceback in the logcat, pointing to the exact source line where the error occurred, you get a crash register dump. However, it is possible to narrow down the point of the error through the standard expedient of outputting debug messages at strategic points in the code (see Logging, below).
Better JNI Glue
The standard Android-provided jni.h makes it slightly awkward to call JNI routines. You can improve this by processing jni.h through JNIGlue, which generates more convenient static inline wrapper routines. For example, instead of
const jclass SystemClass = (**env).FindClass(env, "java/lang/System");
you can do
const jclass SystemClass = JNFindClass(env, "java/lang/System");
In Java code, you can write messages to the logcat using either the Log class, or simply write to the standard Java System.err diagnostic stream or System.out output stream. In the first case, you can set the logging level and the “tag” string used to prefix your messages; in the second case, the level is always warning (W), and the tag is always “System.err”, and in the last case, the level is info (I) and the tag is “System.out”.
In native code, the usual stdio streams of stdout and stderr are defined, but do not work—certainly trying to write to stdout or stderr not only does not display messages anywhere, it can lead to strange crashes elsewhere in your code.
Instead, you can use the native logging library. There is no public documentation for this, but the routines are in the android/log.h header file that you can include in your C/C++ code. Also in your Android.mk for building the native code, add -llog to the definition of your LOCAL_LDLIBS variable.
Messages written to the logcat in this way look like
W/System.err( 1288): test app successfully started
The log levels as enumerated in android/log.h, and the corresponding single-letter codes that appear in the messages, are:
The C and C++ compilers included with the NDK are built from GCC, so you have access to the usual GCC capabilities. For example, you can do the C99 #include <stdbool.h> and use the bool type, with values true and false, in conditional expressions in your code. You can enable more general C99 capabilities by putting a line like this in your Android.mk:
LOCAL_CFLAGS += -std=c99
A possible example of setting up android development
This is a walkthrough of a typical setup of android development .
Mint Linux edition 15 dvd is downloaded , burned to a dvd which is verified, and then the computer is rebooted with the mint dvd.
Custom installation is chosen, and with the unused disc space that was reserved when windows installed , or otherwise use the obsolete linux's root partition , because it won't work anyway when it's upgraded.
Once mint is installed, the IDE will be eclipse because it is so flexible, and tons of other development junk can be put on it later, so eclipse kepler/ whatever the latest edition is downloaded , the toplink / most popular download is chosen ( the one with java development and plugin development). This is unzipped in a user directory, and we try to execute it . Hopefully it does, e.g. fortunately we didn't chose the 64 bit version of eclipse when the 32 bit of Mint was installed.
A little hello world java program is written, to see if the eclipse IDE has a working java compiler. At least the java runtime should be working, because eclipse wouldn't run otherwise. If not, go to synaptic or the mint applications loader and find a java runtime, e.g. openjdk 7 in 2013.
The next bit is to get the android sdk. In Nov 2013, it was the r22 one, found at http://dl.google.com/android/android-sdk_r22.3-linux.tgz, and this is downloaded and unzipped. It might not work if you have a 64 bit Mint environment though, maybe a redhat one would. To get it working in this case, you have to execute tools/emulator and see what it says.
If it says something like there is no file or directory called .. blah/emulator , then likely you don't have a 32 bit environment installed, so get the libc 32 bit environment from synaptic.
If you aren't the administrator, open a terminal first, run su, then type the administrator password (the first user created when mint was installed ). Then type synaptic.
then install libc6-i386.
Keep running emulator and install the libraries it pines for, e.g. lib32stdc++6.
Something else won't work either, which is the aapt build tool in the version of build tools from android, which requires the 32 bit version of the zlib library , lib32z1 . It shows up later , when you find that the generated R class for your android app doesn't generate automatically when editing your project, and everything R.xx is underlined in red.
Run the ./tools/android exec, funny it should actually work even if there is no 32 bit libs. This is to get your android platforms loaded, e.g. platform for 4.4 kitkat, or 4.3 ice cream sandwich, or 2.2 froyo, and also the down in the Extras folder at the bottom, the latest android "support" package, because this gives you backward compatibility of an application written in a later library with an earlier device, if the support library is included in your project. Also you need the ARM system image as a minimum , and maybe the Intel one, but each image makes the download longer, and you can easily end up with 1 gig of development crap just to get hello world on android.
Install the plugin in eclipse, by running eclipse and going to the right most help menu item, and "install new stuff" , then at the top, add in a new software repository site by clicking the button at the top on right "Add.." , and pasting the url in the second "Location" field,
then chose the android development plugin, and maybe the NDK , if you are hardcore gnu ( but you wouldn't be because you are using eclipse ).
After this try creating a blank activity android project, and try running it.
This requires setting up by clicking under the "Window" menu item in eclipse and "Android Virtual Device Manager" , and then choose a low grunt virtual device like Nexus One , so that you don't grow too old waiting for the virtual device to start. Click the second tab in the avd manager, and then select Nexus One from the list on the left, and the "create AVD" button on the right becomes enabled, and then create a virtual device with the ARM system image and whatever level of Android API, and maybe snapshot checked at the bottom, but beware of use "Native GL" because the 32 bit libraries for these may not be loaded, and it will still let a non-functional device be created.
After this , you can try to get a calculator project going, but don't do the programming one from google search 2010, just use the layout editor for the main activity xml , as you can but 4 buttons in one horizontal layout, copy the layout, and paste it to get the other rows. You can also set the onClick method for all the buttons by use ctrl-click to multiple select all the buttons, and then right click in the Outline view over a highlighted button, and choose the menu item "Other property.." and choosing "OnClick", and typing the method name to receive e.g. buttonPressed. Then create a public method in the Activity.java file , called "public void buttonPressed(View v)" , and handle any button clicks by identifying the button using the button's label. (Cast the v passed in into a Button object first ).
Happy android programming, and may the market whim be with you.