Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

An alternative would be to use GSM as a shim, that just calls through to AOSP if the functionality is there, or fills in the functionality if it's not.

But I'm not seeing the advantage to Google of doing that - as everyone gets GSM if they go for the major phones.



There is one factor that causes what's going into GMS and what into AOSP, that the article conveniently glosses over:

Functionality in GMS requries server side support. It can be computational capacity or server-side dabatases (fused location with wifi and cell towers? Google caller id? Map tiles? Storage? Server side push? Cloud support for games? All of them require something on the other side of connection).

Unless someone is willing to step in and provide this, there will be no AOSP equivalent.


>Functionality in GMS requries server side support.

Really? My calendar client, mail client, and launcher require server side support from Google?


Launcher certainly does - where do you think that Google Now prepares it's data?

Launcher without Google Now is part of AOSP.

Both Calendar and Email are available in AOSP, Play Store has their binary builds for those that for some reason do not have current Android version. They can have at least current apps.


They could have made google now a plugin.

Calendar and email in AOSP suck.


Most GSM APIs are based around Google services and products, so some of the APIs don't really have an equivalent in AOSP. One of the other reasons why Google likes GSM over AOSP is the fact that there is much better control over versions of code out in the wild, whereas AOSP rollouts that come with updates to the phone propagate more slowly and inconsistently.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: