Thanks for the replies of Mark and Dianne on other thread. I received 2 points on feedback from Dianne: ------------- Feedback1 Currently to be an Android compatible phone, you are going to need to have a GPS and the various other things that applications depend on.
Since we have market place for Android today and mostly ----------- ----------Feedback2 Market already takes care of this, and won't display applications that aren't compatibility with the target phone. Ideally, though, the platform should take care of most of these things -- the introduction of soft keyboards being a representative example, where the platform goes to a fair amount of work to ensure that applications that were written for a hard keyboard still work with the input method. --------- 1) Are we mandating that all Android phones need to have GPS? If so, it would be quite strange. Why do we want every consumers to unnecessarily pay additional costs even if they are not interested. What happens if Android is taken to PMP kind of devices?? So I come back to my fundamental questions. There must be an architectural thought either on how we eliminate applications on products which do not have the required hardware or atleast make a guideline to application to check the hardware capabilities and throw appripriate errors. 2) I do not understand on how Market Place is taking care of applications that are not compatible with target phone. Is it manually checked? So what is the strategy for non-Smart Phone products? Thanks, Regards Rangan. On Jul 5, 2:40 am, 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 -~----------~----~----~----~------~----~------~--~---
