Replying to this in a better list... Zod wrote: > And as I see manufacturers trying hard to customize their android > versions, to make their products more appealing to the consumers.
Some will, some won't. There will be three major flavors of devices: -- "Google experience" devices, such as the T-Mobile G1, which uses the standard Android UI and theme and such. These devices still may vary in terms of what applications are pre-installed (e.g., Amazon MP3 store only available on T-Mobile G1 in select markets). -- Devices working strictly off the Android open source tree. Makers of such devices can do what they want, within the confines of the open source license. These will not have the proprietary Google apps, like Android Market and Googla Maps. -- A middle ground of devices which are heavily customized yet still come with various Google applications pre-loaded. http://www.crunchgear.com/2009/05/28/google-expects-18-20-android-handsets-this-year/ How the Android branding guidelines (http://www.android.com/branding.html) get involved here is unclear to me, other than only "Google experience" phones can have the Google logo on the device. > So how can Google (and the Android team) defend the platform from > becoming fragmented ? I mean I'm pretty sure that no manufacturer can > modify the base framework in a way which makes existing apps > incompatible with it and still call it Android powered (am I right?). I am not aware of any rules stipulating that use of the Android trademark in a device's description requires compliance with some compatibility kit. This is akin to Linux itself -- manufacturers can claim devices to be "powered by Linux" despite bearing little resemblance to a classic desktop distribution. I have not played around with the firmware that much, though, so I may have missed something here. > But what if they extend the framework with apis that I as a developer > can use, and if I choose to use it, will I be out in the cold alone to > sell it somehow outside the Market ? Android 1.5 introduced an official "add-ons" system, of which Google Maps support is the first. If you write your application that uses an add-on, AFAIK, Android will not install it on devices lacking Google Maps. I would hope the Android Market might even filter it out. You could distribute a separate version of your app that skipped Google Maps support, if you so chose. If a device manufacturer exposes some additional device-specific APIs and follows the add-on system, I would guess that you will have a similar experience. Alternatively, they may tell you to just use reflection to detect (and use) their API at runtime on devices that have it. If you follow that advice, you can write an application that works on devices both with and without their API. If, however, you choose to write an application that *needs* the proprietary API, and they did not implement that API using the add-ons system...that may be bad. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://twitter.com/commonsguy Need help for your Android OSS project? http://wiki.andmob.org/hado --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
