Update the code generator and related classes in annotation processor to
use the new WrapForJNI flags. Also add some more sanity checking to make
sure the flags are used correctly.
Currently, when we generate JNI wrapper for an inner class, the
resulting C++ class will not actually be a nested class of the enclosing
class. As a result, the class can be confusing to use. For example,
wrapping Java class GeckoThread.State results in two unrelated C++
classes, GeckoThread and State, and it'd be confusing to use State by
itself.
This patch adds support for inner classes. We start by scanning only for
top-level classes, and when processing each top-level class, we
recursively scan for inner classes through
JarClassIterator.getInnerClasses() and CodeGenerator.generateClasses().
For each Java inner classes, the resulting C++ class will be a nested
class. For example, wrapping GeckoThread.State will produce
widget::GeckoThread and widget::GeckoThread::State.
The API version detection functionality was broken in SDKProcessor
because we were passing in "Lpackage/Class;" as the class name rather
than just "package/Class". Also, some classes have a weird situation
where some methods were moved around in later API versions. For example,
some put* and get* methods in Bundle were moved to BaseBundle in API 21.
If we only checked BaseBundle.put*, we would think they are API 21+
only. The workaround is to check both the top-level class and the
declaring class for a member, and choose the lower API level as the
minimal API level for that member.
This patch also fixes bugs in including the right class members.
For SDKProcessor we want to include all public members of a class,
including inherited members, because the private/protected members are
not part of the public API. For AnnotationProcessor, we want to include
all the members declared in that class, including private and
protected members, because we may want to access private/protected
members of our own Java classes from C++.
This patch adds AndroidBridge::HandleUncaughtException calls to generated JNI wrappers. Also, the JNI annotation now accepts the noThrow flag to indicate that the JNI caller wishes to handle Exceptions manually.
