PLEASE - No generic "This is awesome" or "Thank you!" posts. In fact, unless you're a themer or ROM developer with technical questions about this project, please refrain from cluttering the thread for the time being. This is NOT ready for users yet and needs a lot of work before it will be.
So, it has come up multiple times that users want some way to theme their devices. The problem is that until recently, the only option for that was CyanogenMod's theme engine. Unfortunately, integrating this is problematic for many ROMs - while it's fine for cherry-pickers who don't care about understanding what they're throwing into their project, it's a big issue for someone who does not want to put 13,000 lines of code into their project in a single patch. (CMTE is 13,000 lines of changes in frameworks/base, which is the very core of Android.) Also, it has been known to have resource usage and performance issues.
Over the past year, Sony has worked on getting a runtime resource overlay (RRO) implementation merged into Android. Most of the implementation was in Android 5.0, and a few bugfixes were in AOSP master until Android 5.1 was released.
A few months ago, a few developers figured out how to use RRO for theming. This system was called Layers, and initially appeared to have a huge amount of potential. Unfortunately, for various reasons, the system stagnated. The original set of commits to implement Layers had a whole pile of issues and clearly had not gone through code review, and when attempts were made to fix these issues, the Layers team wanted to make no further changes. For Omni, a core requirement we have for any theme system is that it cannot affect the user experience when no theme is in use/installed. Layers fails this criteria. (For example, in AOSP, the text on the battery history graph is pure black with no transparency. In Layers, it is mapped to "exposed_primary_text_light" which is a shade of black that includes transparency. There is no way for an overlay to change the other graphical elements that reference this resource without also affecting the battery history graph text, and vice versa. There were numerous other cases of "colors redefined" and "multiple different colors mapped to a single resource".)
I've been talking with members of a few project (including Slim and LiquidSmooth) about taking the basic concept behind Layers and fleshing it out into a mature system that addresses the various issues with Layers. Also, there's a desire to try and implement as much compatibility with CyanogenMod themes as possible without making excessive sacrifices (bloat, major mangling of Sony's RRO approach to facilitate compatibility with legacy themes... Despite nearly all themes requiring a rearchitecture for Lollipop...) in order to make it easier for themers to support this new approach.
So, it has come up multiple times that users want some way to theme their devices. The problem is that until recently, the only option for that was CyanogenMod's theme engine. Unfortunately, integrating this is problematic for many ROMs - while it's fine for cherry-pickers who don't care about understanding what they're throwing into their project, it's a big issue for someone who does not want to put 13,000 lines of code into their project in a single patch. (CMTE is 13,000 lines of changes in frameworks/base, which is the very core of Android.) Also, it has been known to have resource usage and performance issues.
Over the past year, Sony has worked on getting a runtime resource overlay (RRO) implementation merged into Android. Most of the implementation was in Android 5.0, and a few bugfixes were in AOSP master until Android 5.1 was released.
A few months ago, a few developers figured out how to use RRO for theming. This system was called Layers, and initially appeared to have a huge amount of potential. Unfortunately, for various reasons, the system stagnated. The original set of commits to implement Layers had a whole pile of issues and clearly had not gone through code review, and when attempts were made to fix these issues, the Layers team wanted to make no further changes. For Omni, a core requirement we have for any theme system is that it cannot affect the user experience when no theme is in use/installed. Layers fails this criteria. (For example, in AOSP, the text on the battery history graph is pure black with no transparency. In Layers, it is mapped to "exposed_primary_text_light" which is a shade of black that includes transparency. There is no way for an overlay to change the other graphical elements that reference this resource without also affecting the battery history graph text, and vice versa. There were numerous other cases of "colors redefined" and "multiple different colors mapped to a single resource".)
I've been talking with members of a few project (including Slim and LiquidSmooth) about taking the basic concept behind Layers and fleshing it out into a mature system that addresses the various issues with Layers. Also, there's a desire to try and implement as much compatibility with CyanogenMod themes as possible without making excessive sacrifices (bloat, major mangling of Sony's RRO approach to facilitate compatibility with legacy themes... Despite nearly all themes requiring a rearchitecture for Lollipop...) in order to make it easier for themers to support this new approach.
Last edited: