Drawables should not be shared. Therefore, don't set them directly as a resource replacement. Use DrawableLoader instead.
bump version for 2.1.0 development branch
Trigger handleLoadPackage() earlier

Currently, handleLoadPackage() is triggered from LoadedApk.makeApplication().
However, this is later in the application process lifecycle than it should
be. A module which wants to hook something in the early stages of the
process will not be able to do so. Also the resources for the package used
to be loaded before the hook was triggered.

This commit moves the trigger to ActivityThread.handleBindApplication(). I
have tested that this function is called at the beginning of every
application process, also for secondary processes, services, receivers
etc. This happens shortly after the fork, but late enough to get almost
all necessary information about the new process. The only missing part is
the classloader, however it could be retrieved after calling
getPackageInfoNoCheck(). I checked how this harms the initialization and
think it's ok to call it earlier.

The special case for the system_server is triggered from ServerThread.run
as handleBindApplication() isn't called for it. The former trigger
happened way later. This also means that no system services are available
with the new location. As most apps will mainly just set up their hooks at
this time, that should be fine. We could add additional hook points later
(e.g. for when the system is ready, but before starting the applications).
On the other hand, any module can do this for itself.

This also adds ApplicationInfo, Configuration and CompatibilityInfo fields
for the callback parameter. These are no deep copies, but references.
Might be useful to be able to change something there before the
application is initialized.
Use ClassLoader.getSystemClassLoader() as BOOTCLASSLOADER and use it for
the "android" package
add process name to LoadPackageParam, remove config and compat again

I tried to change the config at that time - it resulted in constant
reloads. Better do it in updateConfiguration() as AppSettings already
does.

Instead, pass the process name to the callback. The same package might
have two or more processes and the callback will be called for all of
them. The process name might help to target the correct one.

It's also possible that multiple packages are in the same process. This
case is now also handled. The same callback is used. With the classloader,
modules should be able to hook functions as usual. If they need to do
something only once per thread, they can check isFirstApplication. There
is an even more edge case when an app explicitely creates the context for
another packages and could potentially execute the code in its own context
(with its own uid etc). It would be no big deal to add support for this as
well, but I think this edge is very small in wildlife.
only rename debug.log from Zygote to avoid that the file is renamed away under the running system
notify developers that they should use DrawableLoader
change the way package names are determined for resources

Don't use the PackageParser anymore, instead save the name when the APK is
loaded. As a (wanted) side-effect, one more edge case is supported for
triggering hookLoadPackage(). Fixes #36.
fix package name not being available for resources, see #36
fix type and add warnings that some methods should not be use by modules
Provide an implementation of SharedPreferences

This assures that we always have the same behaviour. Especially, we can
be sure that there won't be write access.

The methods in AndroidAppHelper are deprecated with this as modules can
simply create a new instance of our class and call the reload() method
when required. This is better OO than calling a static method with the
object and there is no reason to prevent direct access to the method.
Use SparseArrays in XResources as recommended by Lint
bump version to 2.1 already as we are getting closer to the release