stub implementations of Play Services APIs

[thestinger]

The approach taken by microG to Play Services isn't acceptable for us. It depends on Google services like Google Cloud Messaging and in some cases even uses Google binaries. It would be a legal liability in a product / popular project and also a major robustness issue since it's chasing after a moving target with undocumented server APIs, etc. Google has demonstrated that they are serious about enforcing their licensing and terms of use for their Play Services code and APIs. The microG approach to bypassing the Play Services SDK signature checks is also a significant security liability and so would adding a substantial amount of code that's going to be perpetually half-baked due to being an understaffed project with a huge amount of ground to cover by writing substantial amounts of new code. That's backed up by the current state of it. It's true that the current low hanging security issues could be dealt with without enormous effort, but security isn't a one time thing and since they aren't taking care of this stuff on their own it's going to be an ongoing issue.

However, it would be useful to have stub implementations of Play APIs done via a properly scoped permission check override to make the app-side Play Services SDK code compatible. It can be scoped to only allow faking the Google Play Services signature and only by the specific stub implementation, not as a generally available permission.

This would be targeted at specific apps to implement (partial) compatibility with them. For example, many apps will work fine with a stub implementation of GCM and just won't have push notifications when the app is in the background.

[thestinger]

Note: this doesn't apply to everything in Play Services, since some of what it provides are not app-facing APIs but rather providers of OS APIs like geocoding. Those are things we want to implement for real: #650 #652. However, existing implementations don't fit within the goals of CopperheadOS. Extremely simple, maintainable code with a lot of attention to a secure design is important to us. Just as we needed our own Updater and PDF Viewer apps, we'll need our own approach to these due to lack of shared priorities with the broader Android community.

[thestinger]

Note: this doesn't apply to everything in Play Services, since some of what it provides are not app-facing APIs but rather providers of OS APIs like geocoding. Those are things we want to implement for real: #650 #652. However, existing implementations don't fit within the goals of CopperheadOS. Extremely simple, maintainable code with a lot of attention to a secure design is important to us. Just as we needed our own Updater and PDF Viewer apps, we'll need our own approach to these due to lack of shared priorities with the broader Android community.