The first Android P Developer preview has been released recently. With the new version number came tons of changes to the Android OS, but one under-the-hood change made thousands of users upset: custom overlays can no longer be installed on Android, starting with the version number "P".

Google introduced Sony’s Overlay Manager Service (OMS) in Android Oreo, letting us install custom themes using the app "Substratum", without the need of root permissions.
However, OMS was locked down by Adam Lesinski (Google employee), with no apparent or described reason in the March Oreo update.

Substratum is a powerful app with roughly 1M users, this commit changed everything for the hundreds of thousands of people that want to install custom themes from the PlayStore without rooting their device. That means no more rootless Substratum. No more custom themes. It’s all gone.

If this doesn’t apply to you and all you are interested in are modifying overlays through building AOSP P and expecting OMS to work, it will not. With, or without root, you will be relying on custom ROMs to disable this check.

The Overlay Manager Service is no small feat. It’s a constant running service in the background of your device to allow for resource replacements on target packages. Android was meant to be the land of the free, but now it seems like you want to approach overlays in the wrong direction as you locked this heavy framework service down and limited it to only Google/OEM specific overlays.

If you wanted to lock down OMS, only allow elevated system calls to this system, rather than locking it to platform. At the very least, building AOSP from scratch and using adb root will work (or Magisk root users). We care more about the freedom of the users to utilize this existing resource as this is the principle of freedom. People should also know that OMS is a huge framework change that is being locked to elevated privileged users (root users).

Another option is to whitelist certain resources to be overlaid. For example, if you’re afraid of strings to be changed, block the overlay from reading from the overlay for strings. This includes booleans, layouts, menu/ or xml/ files!

Overlays themselves are NOT security vulnerabilities. Users cannot just install an overlay and expect it to work magically. They have to be informed individuals to enable an overlay, let alone know how to install one at the first place. People who are installing overlays and enabling them are smart, self-coordinating users that know the dangers and risks when installing overlays. The design of an overlay is genius, in the sense that ONLY resource files are changeable rather than ANY COMPILED CODE or Manifest entries! There has yet to have any malicious overlays since Gingerbread when RRO (Runtime Resource Overlay Framework) was merged. If you’re storing ANY sensitive data in assets or res/raw, then you’re clearly in need of some Android documentation 101. If you don’t want a boolean to be changed, change your coding practices, learn that bools can be HARDCODED.

Google, let Android users install custom overlays again. Without themers on an open platform that is undisruptive, you would not get the CURRENT DESIGN of your Android Settings on P to be a certain “copy” of one of our themer’s themes, Flux White - as we can all scream that the design was completely ripped off.

Our themers on stock create their visions on what they believe Android should look like in their eyes and you can always hop on to check it out. Locking us down will not only harm our users, but also your profits for outsourced, community-developed designs.

To those who read this far, please support us by signing this petition, and starring our request in Google's issue tracker. Thank you. #FreeSubstratum #FreeAndroid

Share our tweets:

https://twitter.com/Chris_Kardas/status/972032139091947520

https://twitter.com/Chris_Kardas/status/972529147431014400

Signed off by: Nicholas Chum, Christopher Kardas, Harsh Shandilya and Mike Finnegan.