Galcon Games
Phil Hassey - game dev blog
Phil Hassey as Wolverine
"What kind of
arrogant jerk
has a website like this?"

Android Day 7: Leftovers

I did some basic testing of the app, and I found a number of minor things to cleanup.

Step 1 – going back to single touch for better device support:

My use of MouseMotion didn’t work on the Droid because the Droid is Android 2.1 (SDK7). So that means e.getMaskedEvent() didn’t work. And though it seems the Nexus has support for some basic MultiTouch, it didn’t work on the Droid, so I’m dropping Galcon back to single touch. Most users only use single touch anyways.

Along with this I did my build at SDK level 4, so I could be sure I wasn’t doing anything else. Recall I have it set to 8 so that the build doesn’t choke on my android:installLocation=”preferExternal” .. So I’ll have to set it back to 8 once I’m done so that feature can be used on phones that support it.

Step 2 – finding out the UDID of the device:

Getting the UDID works on some platforms not others. Here’s a snippet:

    // JNI to get the ANDROID-ID
    public static String get_udid() {
        String r = Secure.getString(app.getContentResolver(), Secure.ANDROID_ID);
        if (r == null) { r = "unknown"; }
        Log.v("get_udid",r);
        return r;
    }

Step 3 – enabling in-game volume controls:

To get the volume control to work you have to add this to your onCreate method:

setVolumeControlStream(AudioManager.STREAM_MUSIC);

And have your onKeyDown method return false.

Step 4 – keeping the Droid keyboard from closing the game:

Getting the keyboard not to close the app on the Droid required adding this to the Activity tag:

android:configChanges="keyboard|keyboardHidden|orientation"

See this page for explanation:

http://developer.android.com/reference/android/R.attr.html#configChanges

Step 5 – Using Licensing vs standard Copy Protection:

I investigated the new Licensing stuff:

http://developer.android.com/guide/publishing/licensing.html

It appears to be fairly involved to add, so I’ll be passing on it for now. The drawback is that using the built-in copy protection of the marketplace requires that my app will be installed on the system memory. On the plus side, I’ve gotten Galcon down to 4MB, which is only 2% of the system memory. From reviewing the top 20 or so Android games, 4MB appears to be an acceptable size.

“A limitation of copy protection is that applications using it can be installed only on compatible devices that provide a secure internal storage environment. For example, a copy-protected application cannot be downloaded from Market to a device that provides root access, and the application cannot be installed to a device’s SD card.”

On the plus side, if I do decide to disable the standard copy protection in a future build and add licensing, I can do that via the publishing site apparently.

“After uploading your licensed application, remember to remove copy protection from the application, if it is currently used. To check and remove copy protection, sign in to the publisher site and go the application’s upload details page. In the Publishing options section, make sure that the Copy Protection radio button selection is “Off”.”

Step 6 – bugs due to overuse of memory:

I’ve noticed the occasional crash during my crossfade. The crossfade uses glCopyTexImage2D coupled with a 1024×1024 texture. That’s a good 4MB of memory and a function which seems to cause trouble. I’m going to remove that for now. The crossfade looks nice, but it doesn’t radically enhance the user experience. (Certainly not enough to off-set a crash!) If the crash persists, I’ll re-add the crossfade.

Step 7 – Signing the App:

Last phase is getting a signed version of my app created. This is required to submit an app to the marketplace. I’m not doing this immediately, but the directions here seem fairly straightforward.

http://developer.android.com/guide/publishing/app-signing.html

2 Responses to “Android Day 7: Leftovers”

  1. Chris Says:

    Note that you can set your minSdkVersion to 4 and your targetSdkVersion to 8, thereby maintaining compatibility with 1.6+ and still using optional features from 2.2 (like the preferred install location, or new multitouch apis). Just be careful not to call functions that didn’t exist in older system versions. There’s an Android Developer Blog post about this.

  2. philhassey Says:

    Yeah .. I eventually decided to just stick with only using SDK version 4 since so many people don’t have devices with newer versions. The preferred install location I might change in the future, but for now since I’ve got the binary small enough I’m not going to mess with it. I don’t want to risk accidentally releasing a build that calls functions that don’t exist (which is what I found I was doing during testing.)

    -Phil