The goal is the ability to build 3D/GL apps with Android to work on 1.5+ without the need for special cases / multiple apks. The problem is that 1.6+ can scale images, but 1.5 does not recognize the 1.6 solution for no scaling. Scaling images is a no-no with OpenGL due to power of 2 requirements for textures, so if Android platform scales images this can break the GL app.

The solution:

1. Add the following into the AndroidManifest.xml:

Also add the tag with everything set to true for all screen sizes and density.

2. Put all desired unscaleable images into just the drawable resource dir. Sadly drawable-nodpi is rejected on 1.5 as it’s a new API feature of 1.6 / API level 4.

3. Create a small helper class (UnscaledBitmapFactory in Typhon) that uses reflection on 1.6+ to set inScaled of BitmapFactory.Options to false when loading bitmaps. With Typhon there are texture loading utilities that will use it under the hood, so end user/dev doesn’t have to use the helper class, however, use this helper class as necessary for unscaled images.

4. Compile with API level 4 and make sure no specific API level 4 code is used such that things will run on 1.5 / API level 3. When doing a GL app/game this is quite possible.

Result: A GL app that is 1.5+ compatible that plays nice with 1.6+ high density / DPI devices w/ no image scaling and thus power of 2 textures are consistent and one apk / app release in the market will hit all devices.

Relevant dev group email threads:
http://groups.google.com/group/android-developers/browse_thread/thread/5a73be55101d4052/d2e6bba95c7294e0

http://groups.google.com/group/android-developers/browse_thread/thread/97d910033eca7a93/210b62120e8e0253

You can implement the above or just use Typhon for GL app creation; coming really darn soon..

Regarding my above post. A week or so ago I had a G2/Ion in my hands w/ 1.5 for a couple hours and such and made the mistake in not examining if there was any new API level 4 fields in the android.os.Build & android.os.Build.VERSION classes; there are, so that tripped me up until I got some more testing done today on 1.5 devices; Cliq & Hero. So my statement on android.os.Build not being present until 1.6 was hastily made.

Now a reasonably cool tool to use for testing and this should be reasonably known out there in the mobile world is DeviceAnywhere (www.deviceanywhere.com). I of course have a bitter pill to swallow as I was the 1st US dev hired there and basically took the prototype through several serious revisions over 3 years adding most of the major features and dealing with scalability/performance and had a large hand in making it what it is on the software side as an architect (what I was doing before Android dev), but the founders are greedy as hell and sharing with no one in that company; no engineer (or other employee) left there happy; IE it’s not a good place to work if you are an engineer. Just saying.. ;P

Anyway… ;P I recommend it for testing Android devices particularly devices with out of date OSes. Here is a press release regarding which Android devices are currently available:
http://www.deviceanywhere.com/index.aspx?sid=6&nid=158

I successfully tested Typhon/tutorials on the Cliq & Hero today with DeviceAnywhere. There is a 3 hour free trial and when signing up you need to assign all the carriers (Verizon/T-Mobile/Sprint/etc) that have Android devices that they support as they don’t have an Android package available yet to choose. Now this is going to be of limited use for an app that is crashing with the generic force close dialog as there is no access to adb/debug log, however if using Typhon since there is extended force close dialog w/ error reporting and email support it’s possible to email stack traces and such and examine things that way. So this is a workable solution for testing on Android devices without owning one and you can also test on world wide carriers. I’ll definitely continue to use this service and only buy the really hot new devices as needed. It sure kicks the emulators rear at least for GL dev as you are working on a real device albeit remotely. I might even write a tutorial on the service as it actually is way better to use it than the emulator for any GL dev sans device in hand.

———-
Here is a slightly modified comment on a similar topic posted on Wired last week
———-

Indeed this is quite the issue and the main ones that have held up the release of Typhon (http_//typhon_egrsoftware_com/) and subsequently the Android tutorials here: http_//www_android-tactelus_com/ The good news is that I’m about done with absorbing all of the recent OS changes and a release is quite imminent. There are four major additions to Android resources w/ Typhon since the 2.0 release / Droid.

- The 1st is the ability to start up OpenGL ES with multiple sets of attributes / configuration parameters then dynamically select a render path depending on which set of configuration parameters were accepted by the device.

- The 2nd if any errors occur the next GL config set is tried, but if there are unrecoverable errors (or uncaught exceptions on the Typhon clock/timing thread) instead of just crashing with a generic force closed dialog a specific GL error or the exception + stack track is printed to a custom force close dialog. Also listed is the device and Android build info. In addition to a force close button there is a “force close & email dev” button and this will close the app, but load the error message + device build info into an email and allow it to be sent to one or more defined dev bug addresses. So detailed error info can be sent to devs in 2 clicks by a user from any device. This not only empowers the user giving them specific error info, but also a 2 click incentive to send it to the developers.

The 3rd is a way to set keyboard defaults and any necessary overriding parameters for input control sensitivities (in case the accelerometer is different on a particular device) via a static XML document.

The final addition is a default activity to allow the user to change the key defaults. This is applicable of course with any game/app using Typhon on Android. The user defined key defaults take precedence over the static XML defined ones.

With these additions I’m fairly confident now that for game/app development Typhon provides a good set of additional resources to deal with the Android ecosystem.

—–

Sadly a major thorn on a per device situation is the underlying implementation of OpenGL; the device driver and GPU specific work, etc. I’ve already noticed that things fail with the underlying implementation of OpenGL between the G1 and Droid. I can get the Droid to spin wait on particular GL configuration functions and the G1 doesn’t fail this way.

There are also more in depth discussions on how to solve even deeper per device OpenGL ES issues such as GPU specific extensions that require additional entry points / API that can not be handled by providing a static android.jar file to compile against. IE for instance the Droid supports OpenGL 2.X (and 1.X too), but because all devices don’t support 2.X (android.jar API) all of Android is limited to 1.X right now. Also as mentioned there are particular extensions available on the Droid / PowerVR SGX that are not exposed because their entry points can’t be added to android.jar. The only way to solve this is to provide additional device specific jar files with the API to be compiled against then implement some sort of dynamic loading mechanism (I’ve chosen OSGi for Typhon; though it’s not implemented for Typhon yet on Android) that after the GL configuration process can dynamically load a jar file with the render path appropriate for the GPU on the device. Without this it’s impossible to support specific GPU functionality (extension specific).

————-

The rapid growth of Android and the fact that it is important to address the Android ecosystem of devices _is_ a legitimate challenge and for a lot devs a problem especially new ones unfamiliar with the different OS versions prior to their 1st device/OS experience. The largest problems I’ve seen between 1.5/1.6/2.0 stock (no carrier/manufacturer mods) Android SDK/OS releases are the following:

- In 1.6 with the addition of various screen sizes and such the AndroidManifest entries for “supports-screens” fails on 1.5. It’s important to include this for an app to utilize/manage the full screen size of a device otherwise it’s automatic compatibility mode.

- The ability in the resources directory to distinguish resources for different screen sizes or “-nodpi” fails on 1.5. I do a lot of games/game engine work and if you don’t have “-nodpi” on 1.6 and 2.0 your images are scaled for automatic compatibility. While “ok” with a general application this is undesirable for games / GL development due to image size power of 2 requirements.

- It doesn’t help that the standard way to reach Android build and device info is located at android.os.Build which is present 1.6 and beyond.

The above is specific Android API / manifest additions. The following are general OpenGL issues:

- It’s necessary to address devices with various attribute configurations. For instance the G1 supports a depth size max of 16 where the Droid w/ better GPU supports up to 24. If you make an app requesting depth size of 24 then it’ll fail on the G1. Yes this is general GL app concern, but each developer will need to custom code this or see below for an API that solves it already. Google doesn’t provide some assistance API to do this.

- To make things worse the underlying implementation in “eglChooseConfig” changed between 1.6 and 2.0, and while it was changed to the correct OpenGL ES specification this change alone has broken most GL apps on 2.0 as prior to 1.6 you could request a 565 RGB config and receive one; now you get the highest rated EGLConfig returned first (different order than pre 2.0) and that may be 888. The fix here is custom developer code to choose the correct EGLConfig after receiving the list from “eglChooseConfig”, but each developer has implement this now and it totally is unclear that this is necessary except for complaints/messages of the dev email list; again see platform / API solution below.

Ah yes.. Now for the plug.. I’ve had a real time oriented API for developing Java apps on the desktop that deals with configuration issues and provides a healthy component oriented platform to do GL app/game development. I’ve ported it to Android and have added features that edge off Android dev; for GL dev this is a standard way to setup GL with multiple attribute paths and linking to separate render paths. There are lots of goodies for game development and by using Typhon 98% of GL app can cross-compile between desktop and Android leaving just a little bit of setup code that is unique to both.

Some info on Typhon; http_//typhon_egrsoftware_com

In addition a client of mine, Tactel, has sponsored the release of Typhon for Android and a major tutorial series on doing real time app/game development. This is (and will be) available here: http_//android-tactelus_com

Now note I’ve been reeling with all the OS changes and updates to Typhon and making sure it addresses the Android ecosystem and not one device or OS release. The good news is that I’ve essentially got it covered for Android 2.0. Check out the tutorial site and hit up Twitter or RSS to get an announcement. It’ll be worth it..