Adjust SYSTEMSERVERCLASSPATH for HTC devices

They make use of a HtcDeviceInfoManager class from /system/framework/ub.jar
in the ActivityManagerService.  This works fine on odex'ed ROMs because
the class is precompiled. But with Xposed, the odex file can't be used
as-is and has to be recompiled before. This would be done later by the
PackageManagerService, but then it's too late.

As a solution, add ub.jar to the SYSTEMSERVERCLASSPATH if it exists.
In the end, it's exactly that: A class which is used by the system server.

Adjust SYSTEMSERVERCLASSPATH for HTC devices

They make use of a HtcDeviceInfoManager class from /system/framework/ub.jar
in the ActivityManagerService.  This works fine on odex'ed ROMs because
the class is precompiled. But with Xposed, the odex file can't be used
as-is and has to be recompiled before. This would be done later by the
PackageManagerService, but then it's too late.

As a solution, add ub.jar to the SYSTEMSERVERCLASSPATH if it exists.
In the end, it's exactly that: A class which is used by the system server.

Adjust SYSTEMSERVERCLASSPATH for HTC devices

They make use of a HtcDeviceInfoManager class from /system/framework/ub.jar
in the ActivityManagerService.  This works fine on odex'ed ROMs because
the class is precompiled. But with Xposed, the odex file can't be used
as-is and has to be recompiled before. This would be done later by the
PackageManagerService, but then it's too late.

As a solution, add ub.jar to the SYSTEMSERVERCLASSPATH if it exists.
In the end, it's exactly that: A class which is used by the system server.

Fix invokeOriginalMethod()

In most cases, invokeOriginalMethodNative() is called from
handleHookedMethod() with the already resolved original method.

However, it's also allowed to call it via invokeOriginalMethod().
In that case, it's possible that the method is actually the hooked one.
Make sure to resolve it to the original one if the second parameter is
zero. The ART variant will be changed to set it to 1 before calling
handleHookedMethod().

Handle different variants of AndroidRuntime::start()

In Android 5.1.1_r19, Google introduced an additonal parameter for this
method. We need to detect which one the ROM uses and call it.

This assumes that the mangled name is consistent across all ROMs and
that the object instance is implicitely handled as first parameter
to the method. On Android 5.0, we assume that this change is not
merged. If required, the dynamic way could simply be enabled for this
version as well.

Fixes rovo89#71.