[PLANNING][WIP]Towards a new theme system

Search This thread

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
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.
 
Last edited:

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
Proposed Roadmap and Status

Here's a proposed roadmap I discussed with some guys from Slim and LS in a discussion on G+. None of this is set in stone though.

1) Merge CM's resource exposure commits. While there are many aspects of CMTE I dislike, these are unambiguously superior to the Layers resource exposure commits and I find nothing objectionable to any of them I've looked at so far, although they have yet to go through full review. STATUS: Up on Gerrit, they seem good.

2) Write a Python script that handles translating the overlays of a CMTE theme to one compatible with the new system - STATUS: Semi-working, but requires item 4 and fails for any theme that uses the "common" resource overlay. Themes that don't use "common" (like Mono and FlatshadeUI) can be translated in 3-4 minutes. Well-formed themes that use "common" require typically 20-30 minutes to manually dereference any "common" references. Some themes rely on some hacks CM has to handle incomplete styles in overlays and thus won't be supportable without hacks that may be undesirable.

3) Implement support for loading overlays from somewhere on /data - STATUS: Not started yet. Needs some good security gurus/SELinux guys to do right.

4) Implement support for overlays being able to reference their own resources. CMTE has this, I haven't quite figured out how they implemented it as it's 13,000 lines of code changes to sift through. - STATUS: See the commit list, this is currently working, however it is "proof of concept" quality

5) Implement support for a "common" overlay - many CMTE themes use this and more are using it as time goes on - STATUS: Not started yet. This may not be possible without architectural mangling to a degree that is undesirable

6) Well, this is more in parallel with items 4/5, but implement an app for managing overlays - it has to be after 3 though. Someone who sucks less than I do at UI/UX stuff needs to do this. :) - STATUS: Obviously not started yet. I've had a few people express interest in this stuff.

7) Longterm goal - Implement support for parsing a CMTE theme in the manager app. Gives similar results to CMTE, except the big difference is putting the "heavy lifting" in an app instead of frameworks/base. This keeps the really nasty code separate from the core frameworks and thus more maintainable. - STATUS: Not even close to started. There are some components of CMTE that I really dislike and this may not be possible to do without those components. It's also far more likely to fail in ways that make a themer look bad for something not necessarily their fault.

Ideally it should be able to provide fairly high compatibility with CMTE but without the system bloat and performance impacts that CMTE seems to entail.
 
Last edited:

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
Show me the Code! (Patches)

THESE PATCHES ARE A PROOF-OF-CONCEPT/WORK IN PROGRESS. DO NOT MERGE THESE INTO ANY PROJECT. I will NOT work with anyone who merges these before they are ready!
You can submit them to your own Gerrit for review, but DON'T merge them.

Resource exposure patches
These are similar to the patches that make up "Type 2 Layers" - but to maximize compatibility with CM themes, we're using CM's resource naming. In fact, all of these patches are cherry-picks from CM
https://gerrit.omnirom.org/#/c/13292/
https://gerrit.omnirom.org/#/c/13293/
https://gerrit.omnirom.org/#/c/13294/
https://gerrit.omnirom.org/#/c/13295/

Allowing overlays to reference their own resources
A major limitation of the vanilla RRO implementation is that an overlay cannot reference its own resources. Sometimes this is annoying, in other cases (such as windowBackground attributes - see http://developer.android.com/guide/topics/ui/themes.html ), it makes doing certain things impossible. One of my main goals has been to find the minimum amount of change to allow this. Currently, the patches below are also all extracted from CMTE's frameworks/base megacommit. If this architecture is preserved I'm going to fix authorship of these commits, but right now I'm hoping to use these to gain ideas for a better way to do this and in the process rewrite them. These commits in their current implementation have some serious architectural limitations.
https://gerrit.omnirom.org/#/c/13346/ - The core implementation. This allows overlays to use their own resources. I'm in the process of analyzing this to determine if there's a way to do this without the current limitations it has. Specifically, if you attempt to use a "standard" overlay with package ID 0x7f, the overlay will completely fail and cause severe issues.
https://gerrit.omnirom.org/13347/ - Treat a few other PackageIDs as being "static" packages. I'm still in the process of reading through Android's code to figure out the differences between static and dynamic references. Overlays must be one of these packageIDs or they will fail.
https://gerrit.omnirom.org/13350/ - Allow aapt to override the packageID by specifying it as an argument to -x - this is needed to produce overlays that don't bork the system

Overlay best-fit hacks
https://gerrit.omnirom.org/#/c/13324/ - With standard RRO, if an overlay only has one resolution of resource, and the overlaid package has a resource that is a better fit (for example, overlay only has xxhdpi and device is xhdpi), the overlaid package's resource would get used. The end result in Layers is that some overlays would behave inconsistently on some devices. (For example, I've never seen a Layers overlay for Hangouts properly theme chat bubbles on any of my devices...)

Misc other fixes
https://gerrit.omnirom.org/#/c/13356/ - Quick settings tiles have a hardcoded AnimatedVectorDrawable class. This doesn't need to be hardcoded and can be a generic Drawable - for example, some themers want to use a RippleDrawable here. This commit is from Steve Kondik
 
Last edited:

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
Frequently Asked Questions

Q: What is this sytem's name?
A: To be determined. Names I've thought of so far are Light Weight Theme System (LWTS) and Phoenix (rising from the layers of ash) - I'm personally leaning towards LWTS because it's very neutral and I also hate flashy names.

Q: How is this different from AOSP/Sony RRO?
A: It is RRO with some small changes to address limitations in the current AOSP/Sony implementation, such as inability of overlays to reference their own resources.

Q: How is this different from Layers?
A: Any patch that is part of this system will go through code review with stakeholders from multiple projects invited to participate. Also, a core requirement of this system is that it does not change the behavior/look of the system when a theme is not installed.

Q: How is this different from CyanogenMod's Theme Engine?
A: While the current state of this is almost entirely cherry-picks of subcomponents of CMTE, it is only 150-200 total lines of code vs. CMTE's 13,000 in frameworks/base alone. There are some components of CMTE that we either don't want or will require too much invasive code to implement. So far one architectural difference is that like Layers, the current plan is for most of the "heavy lifting" (AAPT) to be done on a themer's PC, not on-device. Also, like Layers, this approach currently DOES support multiple overlays for a given package target. (This is most commonly used by Layers themers to change navbar icons independently of whatever other theme is installed for the rest of SystemUI)

Q: If this is intended to be a multi-ROM collaborative project, why is it in the Omni forum?
A: Most of the existing "generic" forums have a lot of clutter. One of the things I want to discuss with people is a better location for this. :) Same goes for the current usage of Omni's Gerrit.

Q: Needing a hacked AAPT sucks! I hate this!
A: I don't like it either. Trying to find a better solution is a work in progress. :)

Q: What about fonts?
A: Something I'd like to support, but not implemented yet.

Q: What about icon-packs?
A: Something I'd like to support, but not implemented yet. CM's approach depends on some of their massive architectural changes to RRO. Also, most launchers have built-in support for icon packs. (CMTE also allows a method for themes to include icon packs that will work with any launcher.)

Q: What about bootanimations?
A: Something I'd like to support, but not implemented yet. Should not be hard

Q: What about wallpapers?
A: Someone should probably work on this. I personally hated any theme that overwrote my nice wallpapers from InterfaceLIFT... So someone else will need to work on it. This NEEDS the ability for a user to disable by default. :)

Q: What about applying themes/overlays without reboot?
A: Unlikely, this capability of CMTE is the root of many of their massive architectural changes to RRO, and is responsible for many of the other tentacles it has throughout frameworks/base unrelated to resource lookup. Implementing this is almost guaranteed bloat.

Where are the Dialer/InCallUI resource exposure commits?
I need to take a look at these, CMTE doesn't have any - it may be that they are unnecessary when combined with the ability for overlays to self-reference resources. For example, looking at https://gerrit.omnirom.org/#/c/11674/2 there is no need to modify anything in res/drawable with CMTE or this approach, as the items in res/drawable can simply be overlaid. I have not yet looked at the other items.
 
Last edited:

SPAstef

Senior Member
Apr 29, 2014
306
485
Ferrara
Just want to say 2 things:

1) Icon packs are actually possible to make, I made for "educational purpose" a port of a little part of Moonshine Icon Pack, GemFlat theme icons and some icons I personally made.
There are some advantages compared to CM: you don't have to insert app activity in any XML file, but just overlay the icon using a layer that target the app you want to theme.

2) I didn't understand well a thing about portings: do you actually mean on Layers or on this new type of theme engine?
 

orangekid

Sr. Mod / Mod Committee / RC-RT Committee
Staff member
Apr 10, 2009
14,775
9,160
Just a quick heads up.

Let's please read the OP before posting. If your post is not going to contribute to a technical discussion of the situation, please do not post it here. If your post mysteriously disappears with no warning, it is because such was not heeded.

Thanks.
 

Orion116

Senior Member
Nov 20, 2014
955
527
Just want to say 2 things:

1) Icon packs are actually possible to make, I made for "educational purpose" a port of a little part of Moonshine Icon Pack, GemFlat theme icons and some icons I personally made.
There are some advantages compared to CM: you don't have to insert app activity in any XML file, but just overlay the icon using a layer that target the app you want to theme.

2) I didn't understand well a thing about portings: do you actually mean on Layers or on this new type of theme engine?

I believe this new way.

LiquidSmooth maintainer for d2usc/vzw & p600
 

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
Just want to say 2 things:

1) Icon packs are actually possible to make, I made for "educational purpose" a port of a little part of Moonshine Icon Pack, GemFlat theme icons and some icons I personally made.
There are some advantages compared to CM: you don't have to insert app activity in any XML file, but just overlay the icon using a layer that target the app you want to theme.

2) I didn't understand well a thing about portings: do you actually mean on Layers or on this new type of theme engine?
1) Well, right now, icon packs can be loaded by launchers that are "icon pack" aware. CMTE allows any launcher to load an icon pack from the theme itself by altering the icon resource of the app itself. Right now "system icon packs" are pretty low priority since MOST popular launchers support loading icon packs themselves, unless someone can state a good use case for them other than "supports any launcher".

2) Since CMTE is the most common theming system with a LOT of themers behind it, it's ideal to try and make the transition from CMTE to any other system as painless as possible for a themer. A theme engine without themes is pretty useless. Layers attracted a lot of themers unhappy with CMTE mainly due to how Cyngn ran some of their theme contests, but many of those themers were still supporting CMTE. If you want someone to support more than one theme engine, and you're NOT the biggest one out there, you've got to make their life as easy as possible. (Strangely, one member of the Layers team said that everything he did was "for the themers" - but the majority of what he did made things harder for themers AND ROM developers, especially themers coming from CMTE.)

Also, just one request to moderators: Try to go light on the moderation unless things go bad. It's a long story, but one of my issues with the Layers team was going overboard on the moderation. That said, the post deleted was just a link to the Layers community with no other comments other than saying "don't reply to me"...
 
Last edited:

SPAstef

Senior Member
Apr 29, 2014
306
485
Ferrara
1) Well, right now, icon packs can be loaded by launchers that are "icon pack" aware. CMTE allows any launcher to load an icon pack from the theme itself by altering the icon resource of the app itself. Right now "system icon packs" are pretty low priority since MOST popular launchers support loading icon packs themselves, unless someone can state a good use case for them other than "supports any launcher".

2) Since CMTE is the most common theming system with a LOT of themers behind it, it's ideal to try and make the transition from CMTE to any other system as painless as possible for a themer. A theme engine without themes is pretty useless. Layers attracted a lot of themers unhappy with CMTE mainly due to how Cyngn ran some of their theme contests, but many of those themers were still supporting CMTE. If you want someone to support more than one theme engine, and you're NOT the biggest one out there, you've got to make their life as easy as possible. (Strangely, one member of the Layers team said that everything he did was "for the themers" - but the majority of what he did made things harder for themers AND ROM developers, especially themers coming from CMTE.)

Also, just one request to moderators: Try to go light on the moderation unless things go bad. It's a long story, but one of my issues with the Layers team was going overboard on the moderation. That said, the post deleted was just a link to the Layers community with no other comments other than saying "don't reply to me"...
I am a themer of both CM and Layers. Now, CM has many features that Layers hasn't (such as fonts, wallpapers, boot animations...) But talking about app themes only I like very much more Layers because of exposed colors. In new "Layers 2.1" various errors that have been made during first exposing were fixed (as did @atl4ntis alone in his ROM), and you don't have to struggle with styles.xml for most of the things (so it's more noob friendly). Obviously there have been many situations where I missed thee possibility to link something to something other in the overlay.
So I think that layers isn't confusing very much. I found more confusing cm. I think that someone who never made themes would prefer layers to cmte. This is my opinion BTW :)
 

Mazda

Retired Recognized Developer
Oct 19, 2008
5,273
12,519
I am a themer of both CM and Layers. Now, CM has many features that Layers hasn't (such as fonts, wallpapers, boot animations...) But talking about app themes only I like very much more Layers because of exposed colors. In new "Layers 2.1" various errors that have been made during first exposing were fixed (as did @atl4ntis alone in his ROM), and you don't have to struggle with styles.xml for most of the things (so it's more noob friendly). Obviously there have been many situations where I missed thee possibility to link something to something other in the overlay.
So I think that layers isn't confusing very much. I found more confusing cm. I think that someone who never made themes would prefer layers to cmte. This is my opinion BTW :)
I think the whole thing about whether is easy or hard can easily be fixed by creating templates just like in the CMTE where a "noob" can just git clone that and start off with that.......

If the template is done right with comments and all, it shouldn't be an issue. Then you have support threads which can be made after things are set and done where people can help each other and get things going.

Nothing is ever going to be "noob proof". Just take a look around at all the guides and everything for the most simple things. As easy as it is to flash a ROM, there's actually videos and guides for that and people STILL find themselves with that deer in the headlight look
 

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
I am a themer of both CM and Layers. Now, CM has many features that Layers hasn't (such as fonts, wallpapers, boot animations...) But talking about app themes only I like very much more Layers because of exposed colors. In new "Layers 2.1" various errors that have been made during first exposing were fixed (as did @atl4ntis alone in his ROM), and you don't have to struggle with styles.xml for most of the things (so it's more noob friendly). Obviously there have been many situations where I missed thee possibility to link something to something other in the overlay.
So I think that layers isn't confusing very much. I found more confusing cm. I think that someone who never made themes would prefer layers to cmte. This is my opinion BTW :)
Well, CMTE exposes colors too - can you provide a specific example of something that was easier in Layers than CMTE due to not being exposed?

I'm guessing probably something in Dialer or InCallUI, since the resource exposure commits in the rest of CMTE are pretty similar to Layers with a few exceptions. I'm willing to consider some "laziness commits" that expose resources as long as they don't conflict with existing ways of doing things.

Other themers I've spoken to preferred CMTE over Layers by a long shot. I think the learning curve of Layers for basic theming might be a bit shorter, however CMTE allows a themer to do much more. I've seen piles of things in Mono, Coalfield, and FlatshadeUI that would be an utter nightmare to do on Layers, if even possible. (As evidenced by the fact that some guy has been trying to port Coalfield to Layers for 2-3 weeks now - I had Coalfield working about 20-30 minutes after I started working on getting it to work with the new system.)

I looked into these fixes you claim they made... They're the fixes I fought for two months to get people to agree on, it appears that after I gave up and said "I've had enough", they squashed the fixup commits into the original ones and changed authorship (In addition to removing the post with my proposal from their community). For reference - the original fixup commits that I put forward for Layers 2.1 are at https://gerrit.omnirom.org/#/q/status:open+topic:rro2p1 and were originally written in late February. Similarly, any CMTE resource naming convention compatibility in Layers was proposed by myself for Layers 3 (WIP at https://gerrit.omnirom.org/#/c/12323/2) and rejected along with the Layers 2.1 fixes - it appears they pulled THIS in too and called the whole thing 2.1. (You'd think that a naming convention change would merit a major version number bump...)
 

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
I think the whole thing about whether is easy or hard can easily be fixed by creating templates just like in the CMTE where a "noob" can just git clone that and start off with that.......

If the template is done right with comments and all, it shouldn't be an issue. Then you have support threads which can be made after things are set and done where people can help each other and get things going.

Nothing is ever going to be "noob proof". Just take a look around at all the guides and everything for the most simple things. As easy as it is to flash a ROM, there's actually videos and guides for that and people STILL find themselves with that deer in the headlight look
One thing I want to do is to try and write some convenience tools for themers... This may be necessary to handle the "common" nightmare as I might need to preprocess "common" resources.

Of course, there are a lot of tradeoffs here... Sometimes making things TOO easy prompts a flood of some really awful stuff. Theme DIY was a great idea but it's led to a bunch of really horrible paid themes on the Play Store (despite the TDIY author stating that the tool was not to be used for paid themes), making people more reluctant to actually buy paid themes that ARE good.

Which is why I'm still torn on one feature of CMTE that handles cases where an overlay has an incomplete style that is missing attributes - Now, this makes a themer's life easier, but in general, the themes where lack of this feature has been a problem were ones of poor quality... One of the stated reasons for the patch was handling cases where an app updated causing the overlay to crash. The problem in this case is that it's better for something to be obviously wrong than for it to fail in subtle weird ways. Look at Facebook for example - at some point they made a MASSIVE overhaul of their styles. Some themes overlaid the "old" styles - as a result of the changes, they crashed with this engine, but caused strange graphical glitches in CMTE. (In fact, I need to check, but I think one themer removed all of his style overlays for Facebook from a theme because of this - at least he was considering it.)

I want to make themer's lives easier BUT I also don't want to encourage bad practices... There are some tough tradeoffs here.
 

SPAstef

Senior Member
Apr 29, 2014
306
485
Ferrara
I agree with you.
If also users with no theming capacity starts making paid themes this will be a pain for good themers.
Another question, do you have any ETA to complete this? (Or at least first points)
 
  • Like
Reactions: Orion116

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
I agree with you.
If also users with no theming capacity starts making paid themes this will be a pain for good themers.
Another question, do you have any ETA to complete this? (Or at least first points)

As far as ETAs - there are a lot of unknowns here. Also, I need to finish up some core Omni stuff that I let slide for... WAY too long because I was spending time on theming and Layers. There's a gigantic CAF ifdef effort I need to finish so we can start nightlies.

Also, if I recall correctly, you were working with the guy behind Carbon UI? (Elixium Dark is the Layers form of Carbon UI???) - https://play.google.com/store/apps/details?id=com.zyxxeil.carbon.ui

That was a pretty easy port since he only used common for some of the keyboard drawables. :)

MilosUI took about ten minutes (mostly, again, handling "common" in the keyboard).

I think I'm gonna pop back over to FlatshadeUI for a while though. :)
 

SPAstef

Senior Member
Apr 29, 2014
306
485
Ferrara
As far as ETAs - there are a lot of unknowns here. Also, I need to finish up some core Omni stuff that I let slide for... WAY too long because I was spending time on theming and Layers. There's a gigantic CAF ifdef effort I need to finish so we can start nightlies.

Also, if I recall correctly, you were working with the guy behind Carbon UI? (Elixium Dark is the Layers form of Carbon UI???) - https://play.google.com/store/apps/details?id=com.zyxxeil.carbon.ui

That was a pretty easy port since he only used common for some of the keyboard drawables. :)

MilosUI took about ten minutes (mostly, again, handling "common" in the keyboard).

I think I'm gonna pop back over to FlatshadeUI for a while though. :)
I didn't port it. We did it together (actually Elixium Dark was out 2 weeks before Carbon), so there was no problems into porting, because they are 2 different themes. With that project we showed that it's possible to make very good themes with both CM and Layers.
Milos is a port (but with some changes), yeah it was quite quick to port it.
Mainly the "hard work" is with common and with framework, systemUI and settings, as they are quite different to theme between the 2 platforms
 

skynet11

Senior Member
Oct 14, 2010
1,935
686
I look forward to adding this to my comparison between Layers and the CyanogenMod Theme Engine when I publish it :cool:
 

Top Liked Posts

  • There are no posts matching your filters.
  • 51
    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.
    30
    Proposed Roadmap and Status

    Here's a proposed roadmap I discussed with some guys from Slim and LS in a discussion on G+. None of this is set in stone though.

    1) Merge CM's resource exposure commits. While there are many aspects of CMTE I dislike, these are unambiguously superior to the Layers resource exposure commits and I find nothing objectionable to any of them I've looked at so far, although they have yet to go through full review. STATUS: Up on Gerrit, they seem good.

    2) Write a Python script that handles translating the overlays of a CMTE theme to one compatible with the new system - STATUS: Semi-working, but requires item 4 and fails for any theme that uses the "common" resource overlay. Themes that don't use "common" (like Mono and FlatshadeUI) can be translated in 3-4 minutes. Well-formed themes that use "common" require typically 20-30 minutes to manually dereference any "common" references. Some themes rely on some hacks CM has to handle incomplete styles in overlays and thus won't be supportable without hacks that may be undesirable.

    3) Implement support for loading overlays from somewhere on /data - STATUS: Not started yet. Needs some good security gurus/SELinux guys to do right.

    4) Implement support for overlays being able to reference their own resources. CMTE has this, I haven't quite figured out how they implemented it as it's 13,000 lines of code changes to sift through. - STATUS: See the commit list, this is currently working, however it is "proof of concept" quality

    5) Implement support for a "common" overlay - many CMTE themes use this and more are using it as time goes on - STATUS: Not started yet. This may not be possible without architectural mangling to a degree that is undesirable

    6) Well, this is more in parallel with items 4/5, but implement an app for managing overlays - it has to be after 3 though. Someone who sucks less than I do at UI/UX stuff needs to do this. :) - STATUS: Obviously not started yet. I've had a few people express interest in this stuff.

    7) Longterm goal - Implement support for parsing a CMTE theme in the manager app. Gives similar results to CMTE, except the big difference is putting the "heavy lifting" in an app instead of frameworks/base. This keeps the really nasty code separate from the core frameworks and thus more maintainable. - STATUS: Not even close to started. There are some components of CMTE that I really dislike and this may not be possible to do without those components. It's also far more likely to fail in ways that make a themer look bad for something not necessarily their fault.

    Ideally it should be able to provide fairly high compatibility with CMTE but without the system bloat and performance impacts that CMTE seems to entail.
    18
    Show me the Code! (Patches)

    THESE PATCHES ARE A PROOF-OF-CONCEPT/WORK IN PROGRESS. DO NOT MERGE THESE INTO ANY PROJECT. I will NOT work with anyone who merges these before they are ready!
    You can submit them to your own Gerrit for review, but DON'T merge them.

    Resource exposure patches
    These are similar to the patches that make up "Type 2 Layers" - but to maximize compatibility with CM themes, we're using CM's resource naming. In fact, all of these patches are cherry-picks from CM
    https://gerrit.omnirom.org/#/c/13292/
    https://gerrit.omnirom.org/#/c/13293/
    https://gerrit.omnirom.org/#/c/13294/
    https://gerrit.omnirom.org/#/c/13295/

    Allowing overlays to reference their own resources
    A major limitation of the vanilla RRO implementation is that an overlay cannot reference its own resources. Sometimes this is annoying, in other cases (such as windowBackground attributes - see http://developer.android.com/guide/topics/ui/themes.html ), it makes doing certain things impossible. One of my main goals has been to find the minimum amount of change to allow this. Currently, the patches below are also all extracted from CMTE's frameworks/base megacommit. If this architecture is preserved I'm going to fix authorship of these commits, but right now I'm hoping to use these to gain ideas for a better way to do this and in the process rewrite them. These commits in their current implementation have some serious architectural limitations.
    https://gerrit.omnirom.org/#/c/13346/ - The core implementation. This allows overlays to use their own resources. I'm in the process of analyzing this to determine if there's a way to do this without the current limitations it has. Specifically, if you attempt to use a "standard" overlay with package ID 0x7f, the overlay will completely fail and cause severe issues.
    https://gerrit.omnirom.org/13347/ - Treat a few other PackageIDs as being "static" packages. I'm still in the process of reading through Android's code to figure out the differences between static and dynamic references. Overlays must be one of these packageIDs or they will fail.
    https://gerrit.omnirom.org/13350/ - Allow aapt to override the packageID by specifying it as an argument to -x - this is needed to produce overlays that don't bork the system

    Overlay best-fit hacks
    https://gerrit.omnirom.org/#/c/13324/ - With standard RRO, if an overlay only has one resolution of resource, and the overlaid package has a resource that is a better fit (for example, overlay only has xxhdpi and device is xhdpi), the overlaid package's resource would get used. The end result in Layers is that some overlays would behave inconsistently on some devices. (For example, I've never seen a Layers overlay for Hangouts properly theme chat bubbles on any of my devices...)

    Misc other fixes
    https://gerrit.omnirom.org/#/c/13356/ - Quick settings tiles have a hardcoded AnimatedVectorDrawable class. This doesn't need to be hardcoded and can be a generic Drawable - for example, some themers want to use a RippleDrawable here. This commit is from Steve Kondik
    17
    Frequently Asked Questions

    Q: What is this sytem's name?
    A: To be determined. Names I've thought of so far are Light Weight Theme System (LWTS) and Phoenix (rising from the layers of ash) - I'm personally leaning towards LWTS because it's very neutral and I also hate flashy names.

    Q: How is this different from AOSP/Sony RRO?
    A: It is RRO with some small changes to address limitations in the current AOSP/Sony implementation, such as inability of overlays to reference their own resources.

    Q: How is this different from Layers?
    A: Any patch that is part of this system will go through code review with stakeholders from multiple projects invited to participate. Also, a core requirement of this system is that it does not change the behavior/look of the system when a theme is not installed.

    Q: How is this different from CyanogenMod's Theme Engine?
    A: While the current state of this is almost entirely cherry-picks of subcomponents of CMTE, it is only 150-200 total lines of code vs. CMTE's 13,000 in frameworks/base alone. There are some components of CMTE that we either don't want or will require too much invasive code to implement. So far one architectural difference is that like Layers, the current plan is for most of the "heavy lifting" (AAPT) to be done on a themer's PC, not on-device. Also, like Layers, this approach currently DOES support multiple overlays for a given package target. (This is most commonly used by Layers themers to change navbar icons independently of whatever other theme is installed for the rest of SystemUI)

    Q: If this is intended to be a multi-ROM collaborative project, why is it in the Omni forum?
    A: Most of the existing "generic" forums have a lot of clutter. One of the things I want to discuss with people is a better location for this. :) Same goes for the current usage of Omni's Gerrit.

    Q: Needing a hacked AAPT sucks! I hate this!
    A: I don't like it either. Trying to find a better solution is a work in progress. :)

    Q: What about fonts?
    A: Something I'd like to support, but not implemented yet.

    Q: What about icon-packs?
    A: Something I'd like to support, but not implemented yet. CM's approach depends on some of their massive architectural changes to RRO. Also, most launchers have built-in support for icon packs. (CMTE also allows a method for themes to include icon packs that will work with any launcher.)

    Q: What about bootanimations?
    A: Something I'd like to support, but not implemented yet. Should not be hard

    Q: What about wallpapers?
    A: Someone should probably work on this. I personally hated any theme that overwrote my nice wallpapers from InterfaceLIFT... So someone else will need to work on it. This NEEDS the ability for a user to disable by default. :)

    Q: What about applying themes/overlays without reboot?
    A: Unlikely, this capability of CMTE is the root of many of their massive architectural changes to RRO, and is responsible for many of the other tentacles it has throughout frameworks/base unrelated to resource lookup. Implementing this is almost guaranteed bloat.

    Where are the Dialer/InCallUI resource exposure commits?
    I need to take a look at these, CMTE doesn't have any - it may be that they are unnecessary when combined with the ability for overlays to self-reference resources. For example, looking at https://gerrit.omnirom.org/#/c/11674/2 there is no need to modify anything in res/drawable with CMTE or this approach, as the items in res/drawable can simply be overlaid. I have not yet looked at the other items.
    9
    Porting CMTE Themes

    *Documentation on how to port a CMTE theme to the new system goes here*