v43: Make resource hooks compatible with Xperia 4.3 ROMs
Add support for LG 4.4 ROMs
Add support for Meizu ROMs
v44: Simple switch to turn off resource hooking

Useful if a ROM has a theming engine which is not (yet) supported by
Xposed. Will break some modules, but at least some others will work. The
most obvious breakage (module implements IXposedHookInitPackageResources,
which isn't called) is prevented by checking for this situation and not
loading the class at all.
v45: Log ROM details on Zygote startup
Log method signatures if hooking resources fails
v46: Fix logging of method signatures

If a method couldn't be found, that's a NoSuchMethodError, not an
Exception. So better catch Throwable. Also adjust our methods to throw
Throwables.
Remove AndroidAppHelper.getActivityThread_mPackages()

It isn't used anywhere by the framework nor by the 200+ modules uploaded
to the repository. Plus it uses a field which has been removed in new
Android versions.
Get ActivityThread.mActiveResources via reflection

It doesn't exist on newer Android versions and therefore creates a
DexOpt/VFY warning.
Avoid conflict with LG G2 icon theming engine
Compatibility with CM11's new theming engine

CyanogenMod has introduced a new theming engine in
https://github.com/CyanogenMod/android_frameworks_base/commit/34d6168d14928060c527c4f7410a4b977719cdf5
based on Sony's contributions to AOSP (which are merged already, so they
will be part of the next Android version) and their own development.
v47
Hook all getTopLevelResources() methods

There are many different ROM versions and theming engines which have
different versions of getTopLevelResources(). I'm tired of explicitely
coding all the different possibilities, so let's hook all of them.

Instead of constructing a ResourcesKey from the parameters manually, we
just take the one which is created by Android during the call to
getTopLevelResources(). At the moment, this is the only place where such
objects are created, but even if that changes, the implementation should
be able to deal with it.

In SDK18 and below, there were two different getTopLevelResources()
methods, one calling the other. The inner one will win and return the
replaced XResources object to the outer one.
Remove obsolete logging

The issues caught with this shouldn't occur anymore with the previous
commit.
Simplify calls to handleInitPackageResources()

The old code had a little bug anyway (null vs. "") and I have never seen
that the package name wasn't available. If such a situation occurs, that
should be fixed instead of delaying the initialization. Also this can be
called for resDir == null, otherwise the ResourcesKey would throw an NPE.
Replace TypedArray by changing the object type

This brings a massive performance improvement to layout inflations, which
call the function to create or get these objects very often.

Examples for reduce of overhead for a small layout hierarchy:
Emulator, three sublayouts hooked   51% -> 22%
Emulator, nothing hooked            43% -> 13%
Nexus 5,  three sublayouts hooked   72% -> 25%
Nexus 5,  nothing hooked            43% -> 16%

These figures can look completely different for bigger layout with more
effort to actually create the view, but the trend is clear.

Requires binary version 52.

Don't try such things at home (in a module)!
Add debugging method to dump object
Dirty clone Resources to XResources

The native method is able to clone any object (even if it doesn't
implement Cloneable). The new object can be allocated with enough memory
for a subclass of the original class. All the original fields are cloned,
and any additional fields are zeroed out (so they should be set
explicitely). This makes use of the fact that inherited fields have the
same memory layout in the subclass and additional fields are stored on top
of (= after) the inherited ones.

We use this to create the XResources object without having to worry about
ROM-specific fields or constructors.

Requires binary version 54.
A little more refactoring of XResources creation
Add a cache for resource replacement status

Store whether there are replacements for a certain group of IDs to speed
up getReplacement() significantly. The group is calculated from the most
significant bits of the ID, which should usually avoid false positives.
If the cache says that there are no replacements, then there are
definitely none and the more expensive lookup in the SparseArray can be
skipped. Otherwise, there *might* be replacements. The lookup still
happens as before and might return null. Therefore, false positives in the
cache won't cause bad behavior, just longer runtimes (but only very little
more than the runtime without this commit for every single resource).