Project tips

From Android Wiki

Revision as of 08:47, 31 January 2013 by Ldo (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, searcha

The Android SDK will create a project directory structure for you (using the android create project command), but some things could be done better.

Note that the following tips are oriented towards command-line-oriented builds using a build.xml file with the Ant tool. Google also provide an Eclipse plug-in, but GUI tools are never going to be free of limitations and inflexibilities; the ultimate in power is always going to reside in the command line.

Contents

Main Activity Title

The android create project command forces the title that appears in the main activity window to be the same as the main activity class name (and disallows spaces and other non-alphanumeric characters). But there is no requirement for this; the title can be any text string.

Application Label vs Activity Label

The value of the label attribute on the <activity> tag is the one that shows in the launcher’s scrolling list of available applications, and is the one that shows when you add an app shortcut on a home screen. The label on the <application> tag is only used when you look to manage installed applications in your Settings.

Too Many Subdirectories

Java source files are kept in the src/ subdirectory. The Java tradition is to create a subdirectory level for each component of the fully-qualified package name; thus, the source file for a class com.example.myproj.Main would be in src/com/example/myproj/Main.java. I find this is excessive. And it turns out the Android build tools don’t care how the directory hierarchy is laid out underneath src/, they will simply compile every *.java file they find anywhere under there. So for a small project, you can just as easily move all your source files to reside directly within src/. For a larger project, you might group things into subdirectories say, one level down. But the choice is yours, you don’t have to be consistent with the package hierarchy names.

Manifest minSdkVersion/targetSdkVersion vs build.xml/project.properties target

The project.properties file referenced from build.xml defines the “target” property, which specifies the version of the Android API to use to build your app. In the manifest there is the <uses-sdk> tag, which specifies “minimum” and “target” Android API versions under which your app will run.

The two are not automatically kept in sync; it is up to you to manage them. Normally target would match targetSdkVersion, but you would temporarily lower it to minSdkVersion while doing test builds to verify that your main app classes are not making references to newer API features that would cause them to fail to load on older system versions.

Native Builds

If you use the NDK to build C/C++ code for your project, it provides the ndk-build command to compile that code. Instead of invoking ndk-build as a separate step, why not include a call to it in your build.xml file, so a single ant compile command will compile everything? You can do this by adding a call to ndk-build in the -pre-build target in your build.xml, as follows:

   <target name="-pre-build">
       <exec executable="${ndk.dir}/ndk-build"/>
   </target>

(I define ndk.dir in my local.properties to point to the directory where I have the NDK installed.)

Similarly, it is convenient if ant clean can delete all automatically-generated files in a single step, instead of having to do a separate ndk-build clean step to get rid of the compiled native code. Here is how I customize the clean target in build.xml:

   <target name="clean" description="Removes output files created by other targets.">
       <delete dir="${out.absolute.dir}" verbose="${verbose}" />
       <delete dir="${gen.absolute.dir}" verbose="${verbose}" />
       <delete dir="${native.libs.dir}" verbose="${verbose}" />
       <delete dir="obj" verbose="${verbose}" />
   </target>

Omit Unnecessary Stuff

If you aren’t going to obfuscate your code, you can delete the automatically-created proguard.cfg file.

Also, don’t forget to omit build products from Version control. A repository should only include things generated by actual humans; all else can be automatically generated as part of the build process. Remember, the fewer manual steps there are, the less chance to make errors.

One-Step Signing

It is easy to customize build.xml so that a single ant signed command will do all the compilation, signing and aligning of the output .apk file in one step. Details are in Signing packages.

See Also

  • new-android-project is a Python script wrapper around the android create project command which implements the above recommendations.
  • Kumar Bibek’s “Automating Builds on Android”, part 1 and part 2.
Personal tools