Hi there, I suppose this is a developer's choice. If you want to develop an application that depends on the specific manufacture's API then you will stick with him. But you would choose to do something like this?
Spybee On Jul 4, 7:40 pm, Mark Murphy <[email protected]> wrote: > 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-han... > > 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 -~----------~----~----~----~------~----~------~--~---
