5 ms·

Great project. The importance of something like this is increasingly growing, as Android ecosystem is getting more and more dependent on Google's proprietary so

Great project. The importance of something like this is increasingly growing, as Android ecosystem is getting more and more dependent on Google's proprietary software. For the next steps, it would be nice to have some onboarding document for this project, as otherwise it will probably look to complex and unwelcoming. I see that most of the replacements are in a very early phase (and one of them is empty), so I hope that this project manages to survive this early state to grow into something we can actually rely on.

DCKing 12y ago
> as Android ecosystem is getting more and more dependent on Google's proprietary software This is untrue when you're talking about app development, which this is about. It can be demonstrated by simply pointing out that Microsoft's, Amazon's and Baidu's Android derivatives are fully functioning commercially even though the Google Play Services are not available on these devices. The Amazon App Store even has 240,000+ apps. There's an increasing amount of propietary Google software running on Android phones, but that has no consequences for other apps. No functionality of AOSP is being absorbed into Play Services at all.
- ricardolopes 12y ago
  Google is frequently pushing new Google Play Services that developers can use for their apps. Those services have the massive advantage over AOSP APIs of having OTA updates for all, not having to rely on carriers and manufacturers for full OS upgrades. In addition, those services offer new and useful functionality that is not always present in AOSP. Therefore, it is only natural that, on a general basis, developers start using more and more of Google's proprietary APIs. This is not to say that pure AOSP is broken, or that it is impossible to have products like Kindle Fire and Nokia X. But it is a growing problem, and the fact that Amazon has to spend so much time replicating Play Services' APIs to have a decent app store (that is still considerable smaller than Google Play Store) is concerning.
  - DCKing 12y ago
    That is true. Although AOSP in itself is a complete operating system, most apps require the need for the "extras" that are provided by some cloud service. Although you can manage without, apps assume an "ecosystem" with additional cloud services rather than an OS to be present. It would be wrong to have AOSP depend on Google cloud APIs, and seperating those cloud APIs in Google Play Services also has problems. There's really no winning here for an open platform.
    - jayd16 12y ago
      I think a good solution would be to abstract the Google Play Services behind some 'cloud-api service' that others, such as Amazon, could re-implement and drop in. The Google play store would be the canonical implementation. Google controls the API but Amazon is free to expand the functionality on their devices. This way, the developer can simply call Context.getSystemService(CLOUD_SERVICE) and have access to whatever cloud service the user as installed. Every other part of android, from keyboards to cameras, works this way and these services could as well.
      - DCKing 12y ago
        That would be difficult, I think. "Cloud service" does not really define any capabilities present or absent in the library. Even if you split it up in things like "mapping service" and "cast service" then a lot of details will differ between otherwise equivalent providers. It's not something you can easily generalize. And if you generalize it, you're stuck with this generic API until your phone gets updated. This project and some of Amazon's libraries basically take a subset of Google's Play Services API as canonical and reimplement those. That's not an ideal solution either, but at least it provides minimal pain for app developers.
        jayd16 12y ago
        >And if you generalize it, you're stuck with this generic API until your phone gets updated. The cloud service version and the client library code would not be coupled to OS version and updated with APKs just like how Google Play Services does. Its not any harder than exactly what Google is currently doing with play services. I'm not proposing anything that isn't already being done besides some standardized calls and some extra service discovery.
- Zigurd 12y ago
  > but that has no consequences for other apps. No functionality of AOSP is being absorbed into Play Services at all. That's technically correct. But apps that are in AOSP can be supplanted by Google proprietary apps and turn into abandonware. Goggle has never outright misbehaved w.r.t. AOSP, and in some cases put things like ART into AOSP very early, ahead of commercialization by Google's OEM partners. BUT that doesn't mean that Google Play Services isn't effectively shrinking AOSP's share of the standard complement of apps.
  - mattl 12y ago
    Android 3.0 wasn't released by AOSP until Android 4.0 came out. That was certainly a strange time.
    - jayd16 12y ago
      Go back and use a 3.0 device. It was a mess.
      - Zigurd 12y ago
        It wasn't a mess. There was never a good reason to withhold the source code. It was eventually released, and there was nothing terrible in it.
        yareally 12y ago
        My guess for withholding Android 3.x was to prevent Amazon from using Android 3.x on the original Kindle Fire. Instead, the original Fire was stuck using a modded Phone OS (Android 2.3) while Android 3.x remained exclusive to tablets licensed by Google.

DCKing 12y ago

> as Android ecosystem is getting more and more dependent on Google's proprietary software This is untrue when you're talking about app development, which this is about. It can be demonstrated by simply pointing out that Microsoft's, Amazon's and Baidu's Android derivatives are fully functioning commercially even though the Google Play Services are not available on these devices. The Amazon App Store even has 240,000+ apps. There's an increasing amount of propietary Google software running on Android phones, but that has no consequences for other apps. No functionality of AOSP is being absorbed into Play Services at all.

ricardolopes 12y ago
Google is frequently pushing new Google Play Services that developers can use for their apps. Those services have the massive advantage over AOSP APIs of having OTA updates for all, not having to rely on carriers and manufacturers for full OS upgrades. In addition, those services offer new and useful functionality that is not always present in AOSP. Therefore, it is only natural that, on a general basis, developers start using more and more of Google's proprietary APIs. This is not to say that pure AOSP is broken, or that it is impossible to have products like Kindle Fire and Nokia X. But it is a growing problem, and the fact that Amazon has to spend so much time replicating Play Services' APIs to have a decent app store (that is still considerable smaller than Google Play Store) is concerning.
- DCKing 12y ago
  That is true. Although AOSP in itself is a complete operating system, most apps require the need for the "extras" that are provided by some cloud service. Although you can manage without, apps assume an "ecosystem" with additional cloud services rather than an OS to be present. It would be wrong to have AOSP depend on Google cloud APIs, and seperating those cloud APIs in Google Play Services also has problems. There's really no winning here for an open platform.
  - jayd16 12y ago
    I think a good solution would be to abstract the Google Play Services behind some 'cloud-api service' that others, such as Amazon, could re-implement and drop in. The Google play store would be the canonical implementation. Google controls the API but Amazon is free to expand the functionality on their devices. This way, the developer can simply call Context.getSystemService(CLOUD_SERVICE) and have access to whatever cloud service the user as installed. Every other part of android, from keyboards to cameras, works this way and these services could as well.
    - DCKing 12y ago
      That would be difficult, I think. "Cloud service" does not really define any capabilities present or absent in the library. Even if you split it up in things like "mapping service" and "cast service" then a lot of details will differ between otherwise equivalent providers. It's not something you can easily generalize. And if you generalize it, you're stuck with this generic API until your phone gets updated. This project and some of Amazon's libraries basically take a subset of Google's Play Services API as canonical and reimplement those. That's not an ideal solution either, but at least it provides minimal pain for app developers.
      - jayd16 12y ago
        >And if you generalize it, you're stuck with this generic API until your phone gets updated. The cloud service version and the client library code would not be coupled to OS version and updated with APKs just like how Google Play Services does. Its not any harder than exactly what Google is currently doing with play services. I'm not proposing anything that isn't already being done besides some standardized calls and some extra service discovery.
Zigurd 12y ago
> but that has no consequences for other apps. No functionality of AOSP is being absorbed into Play Services at all. That's technically correct. But apps that are in AOSP can be supplanted by Google proprietary apps and turn into abandonware. Goggle has never outright misbehaved w.r.t. AOSP, and in some cases put things like ART into AOSP very early, ahead of commercialization by Google's OEM partners. BUT that doesn't mean that Google Play Services isn't effectively shrinking AOSP's share of the standard complement of apps.
- mattl 12y ago
  Android 3.0 wasn't released by AOSP until Android 4.0 came out. That was certainly a strange time.
  - jayd16 12y ago
    Go back and use a 3.0 device. It was a mess.
    - Zigurd 12y ago
      It wasn't a mess. There was never a good reason to withhold the source code. It was eventually released, and there was nothing terrible in it.
      - yareally 12y ago
        My guess for withholding Android 3.x was to prevent Amazon from using Android 3.x on the original Kindle Fire. Instead, the original Fire was stuck using a modded Phone OS (Android 2.3) while Android 3.x remained exclusive to tablets licensed by Google.