So I have been meaning to write this up about using rro vs cm’s theme engine so let’s provide some back history and then explain how both systems work.
Overlays have been supported in android for a very long time.
Actually all the device trees in the android source code works by overlays (now know as static overlays), developers are very familiar with these because we use them all the time.

Overlays work on the concept of changing out resources of android for the purpose of making things specific to a device, runtime resource overlays have actually been in android since about the gingerbread days and is actually what the theme engine is based on.

Cm uses the overlays to provide themes but at the time of the inception of the theme engine, there was a not a simple way to have overlays be swappable so what did cm do, they decided to port aapt (android asset packaging tool) onto the device so they modify app’s assets (resources) in real time but at the cost of modifying that actual app. (This is a major security hole in itself)

Sony decided to go about replicating this behavior for their xperia themes and submitted it to aosp and they got shot down because of using aapt on device because of the possible security implementations.

So with Sony intent on having swappabale themes worked with google to devise the current implementation of rro that provides a much more secure way of going about it.

They modified the asset manager to accept apks with just resources and map out the id of each resource in android and then overlay the modified resources at just runtime so those resources can map out to rro’s changed or new resources to act like they were always part of those resources but only as long as that apk is there and loaded into the system.

With this system, it provides security because the system is already given permission but still confined in all of android but it is also powerful because new resources can made to add features, translations and so forth very quickly (OEMS are actually using it now to prototype )

With this system in place, the code was merged into aosp for lollipop, unfortunately with google keeping lollipop source mostly hidden, nobody realized that it broke in the process until 5.0 was already out and Sony quickly patched it in aosp for the next release (the 5 commits that need to be cherry picked for rro to properly work)

This means that future stock builds of android has this native theme engine built into it and Sony and Samsung and HTC are actually already using it (rumor is this works already in gpe Sony and Samsung lollipop builds) so it makes sense for the community to embrace it and build on it as our own project.

Cm though decided instead of embracing RRO (maybe they didn’t know about it) ported their legacy code up for the theme engine with so much effort instead of looking for a new way with 13,000+ lines of code instead of probably about 200 lines of code to adapt the theme engine into was was already there so there is a ton of redundant code that is completely ridiculous.

Now unfortunately because cm completely disregard the native theme engine, they caused conflicts with it and aosp code.

Now the problem we are seeing is that since rro and our own project here to work with it and make it more extensible is a infant project just starting out, it is a bit unknown about how powerful it is and that it does the same exact thing as the theme engine is the downfall while we are still tuning it.

This is causing a bit of a split in the community because most people know the cm theme engine because it has been around for years so everyone in the community knows it so Roms (even ones that are supposed to be purely aosp based) are at a crossroads because the demand for themes is very high and the pressure to add the cm theme engine is high for them even though it caused issues in kit kat.

I discovered rro while I was looking for ways to add code without hard coding it into my source code for frank and started discussing it with brian gill, Reinhard/bitstra and aldy about implementing this and the benefit it would have for the community not just for Roms but for stock android firmware so this project was born.

The goal is still for adding features without hard coding tons of fragile code but we saw the demand for themes are high so we have been focusing on that.

The overlay manager and methods that we are creating will become open source once we fine tune it and create simple ways for users and themers/developers to work with it easily so it feels like native functions and something the community can adopted and be proud of.