4 ms·
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
by AndrewDucker 13y ago
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.
- vetinari 13y agoThere 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.
- wyager 13y ago>Functionality in GMS requries server side support. Really? My calendar client, mail client, and launcher require server side support from Google?
- vetinari 13y agoLauncher 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.
- wyager 13y agoThey could have made google now a plugin. Calendar and email in AOSP suck.
- king_jester 13y agoMost 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.