[Galaxy Note II Original Android Development] rovo89:
Thanks!

I just played around a bit with manipulating the theme. FYI, I hooked ActivityInfo.getThemeResource() and changed the result, because that is the theme which was parsed from AndroidManifest.xml. It works for some apps, but here are a few problems with that:

- It works only if the apps doesn't explicitely set the background color

- There are lots of different themes. You already mentioned a variant for dialogs. There are many more, just have a look at android.R.style.Theme*. What would be needed is a lookup map which defines which for each light theme what the replacement for it should be. In your case: Theme_DeviceDefault_Light_Dialog_Alert => Theme_DeviceDefault_Dialog_Alert. There is also a Theme_Black, but I haven't checked that.

- Some apps - especially the more complex ones, define their own themes. A lookup map won't work here. Maybe a forced theme? But which one? With title bar? Fullscreen? What about dialogs? etc.

- When a theme is forced, all the customization done on top of the theme is lost. E.g. Twitter crashes due to this because it relies on some custom attributes in its theme.

It would be great if themes themselves could be changed, especially the parent theme they inherit from. Then the hierarchy could be searched for a known standard theme, which could then be replaced with the known replacement theme, leaving all overridden values intact.

But as I mentioned before, styles (and themes are just styles) are evaluated in native code, so they are pretty hard to hack. I spend some hours of my weekend to analyse again how styles are saved and processed. Some things I learned:

- a theme is structured like this:

resource 0x7f020002 de.robv.android.xposed.mods.misc:style/MyTheme: <bag>
Parent=0x0103000c, Count=3
#0 (Key=0x01010054): (reference) 0x0106000b
#1 (Key=0x01010056): (color) #ffffffff
#2 (Key=0x01010074): (reference) 0x7f020001

- this is basically just a map of the attribute to its value, plus the parent

- these maps can exist for different configurations, e.g. for other languages, screen sizes etc.

- as far as I could see, there is no inheritance between different configurations of the same style, i.e. if the above example is in "values" and there is a style with the same name in "value-en" which has just the color (key #1), then the other two values will not be inherited

- these styles are saved in resources.arsc and loaded when the Resources are initialized (or rather the AssetManager)

- they are then stored into internal structures and maps

- when a style has to be loaded, the best matching style resource is searched

- if this style has a parent, it is mixed in, plus its parents etc.

- the result is cached, but the cache will be reset when the configuration changes (e.g. because the device is rotated)

Now wouldn't be a big problem to change in Java code, but this is C++ with native structures, no reflection possible. In my opinion, the best place to manipulate is after the resources.arsc has been parsed, then manipulate the internal structures. I have no idea if that is possible, but even if it is, it will require going through all configurations for the particular style resource and change the maps behind them. Maybe a Java interface to look at the different maps would be good, but this would also require preparing the details of the configuration in a way that can be analyzed by modules. Otherwise, the maps would be kind of anonymous, so it could be mainly used to a) change a value for all of them (adding is probably not possible) and b) check/change their parent styles. But again - I have know idea if that is even possible. If it is, it will definitely not be easy. Comparing the expected use to the required effort, I'm not sure if that is worth it.

To sum up: There might be a rather easy solution which will work for some apps, but might not work for or even crash others.