[Omni Features Development] Entropy512:
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.