[...] take a look at the Android fragmentation that carriers are creating. Mobile Blogging from here. Tags: fragmentation, Sprint, [...]

[...] is Google’s answer to the ever increasing Android fragmentation? They choose to develop web applications that run in a mobile browser instead of trying to build [...]

[...] has followed our lead and decided to begin publishing the percent of devices that are running different versions of [...]

I’d love to see this as a monthly feature…pretty useful stats to have access to

Well.. I know this is not a developer forum, but I’ll just mention what solved the 1.5/1.6 fragmentation issues for Typhon & me (mentioned above in a couple posts). It’s been the case many times a need to fish in the dev email group or via web searches to put together the right info and this is just one more location some Android dev might stumble across, so here it goes.

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.. ;)

Why is it in all these pools i never hear mention of the rogers magic, I have a rogers magic and last time i checked it was an official HTC phone running android, so when u guys are taking your polls and whatnot and then proceed to state which phone are still stuck on 1.5, don,t forget the rogers magic……….

[...] though the Motorola Droid has been out less than a month, it accounts for nearly 25 percent of the Android traffic to our site. Admob data has also confirmed this by listing the Droid as the [...]

@CJ – A little wishful thinking. Google itself can’t even provide developers with adequate access to the SDK in a timely manner (1.6/2.0) before public / OTA / new device release let alone require everyone to synchronize efforts. The Open Handset Alliance should set best practices, but enforcement is not really possible. The 80%/20% release w/ bugs & problems mindset has thoroughly taken hold in the tech world; besides we’re talking about corporations whose bottom line is to make money, so there is little incentive on updating devices after release (or we’ll see who plays nice soon enough in the Android ecosystem; support those manufacturers/carriers who update their devices and ignore those who don’t!). As mentioned in my post I can’t wait for the device specific OpenGL crashes due to non-standard low level device driver implementation and such.. Fun fun fun…

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.

I hate to say this but the open nature of Android is going to present a big problem as the OS becomes more widely used. Google needs to mandate that all apps for Android will work on all Android phones whether they be touchscreen only, keyboard only, or both. When a new version of Android is released it should be mandatory that the manufacturers make it available for their phone. If this doesn’t happen you will a system of haves and have nots with some phones running the latest OS and others stuck running outdated OSes. One only needs to look to Apple for why this becomes important. All iPhones get updated to the latest software. 1 can argue that Apple only has to support 1 form factor but even if they released an iPhone with a keyboard they’d surely make the software compatible between touchscreen only and keyboard only. Freedom is good but only if there’s someone to keep it from running a muck!

The apps you purchase are tied to your Google account. They are easily transferred from phone to phone and you do not have to repurchase them.