Instead of specifying a class name per line, the new format uses the
.ini format, with each section name specifying the class, and each
property name specifying a member of the class. WrapForJNI options can
be specified with each class or member. Comments can be specified with
';' or '#'. For example,
# Generate bindings for Bundle using default options:
[android.os.Bundle]
# Generate bindings for Bundle using class options:
[android.os.Bundle = exceptionMode:nsresult]
# Generate bindings for Bundle using method options:
[android.os.Bundle]
putInt = stubName:PutInteger
# Generate bindings for Bundle using class options with method override:
# (note that all options are overriden at the same time.)
[android.os.Bundle = exceptionMode:nsresult]
# putInt will have stubName "PutInteger", and exceptionMode of "abort"
putInt = stubName:PutInteger
# putChar will have stubName "PutCharacter", and exceptionMode of "nsresult"
putChar = stubName:PutCharacter, exceptionMode:nsresult
# Overloded methods can be specified using its signature
[android.os.Bundle]
# Skip the copy constructor
<init>(Landroid/os/Bundle;)V = skip:true
# Generic member types can be specified
[android.view.KeyEvent = skip:true]
# Skip everything except fields
<field> = skip:false
# Skip everything except putInt and putChar
[android.os.Bundle = skip:true]
putInt = skip:false
putChar =
# Avoid conflicts in native bindings
[android.os.Bundle]
# Bundle(PersistableBundle) native binding can conflict with Bundle(ClassLoader)
<init>(Landroid/os/PersistableBundle;)V = stubName:NewFromPersistableBundle
# Generate a getter instead of a literal for certain runtime constants
[android.os.Build$VERSION = skip:true]
SDK_INT = noLiteral:true
Currently, auto-generated Java bindings are in the mozilla::widget
namespace, and that potentially conflicts with code under
widget/android. Moving the bindings to mozilla::java avoids conflicts
and makes it more clear that we're using Java bindings.
Currently, auto-generated Java bindings are in the mozilla::widget
namespace, and that potentially conflicts with code under
widget/android. Moving the bindings to mozilla::java avoids conflicts
and makes it more clear that we're using Java bindings.
Java allows a class field to have the same name as a superclass field,
but when we generate bindings for them, they'll end up with the same C++
name and cause an error. This patch makes the SDK processor filter out
any superclass fields that are hidden by a subclass field with the same
name.
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++.
In certain configurations, in particular when installing the Android SDK
using HomeBrew, one sees a configuration with symlinks like:
[brian@brian-macbook git]$ ls -l /usr/local/Cellar/android-sdk/23.0.2/
total 72
...
lrwxr-xr-x 1 brian admin 38 Nov 14 16:39 platforms -> ../../../var/lib/android-sdk/platforms
...
drwxr-xr-x 26 brian admin 884 Nov 14 17:43 tools
In this case, we have
ANDROID_SDK=/usr/local/Cellar/android-sdk/23.0.2/platforms/android-21.
It is an anti-pattern to use ANDORID_SDK/.. to find other paths in the
tree. This pattern is used in at least two places:
1) When we try to find
/usr/local/Cellar/android-sdk/23.0.2/platforms/android-21/../../tools,
we end up in the /usr/local/var/lib subtree. This patch works around
that by exporting and using ANDROID_TOOLS; ANDROID_TOOLS itself is
extracted using path matching, rather than following .. through the
filesystem.
2) We also need to use ANDROID_SDK_ROOT rather than
ANDROID_SDK/../.. through-out.
--HG--
extra : rebase_source : 5e0323a94f2b80550f17a624e16f338cdeec406d
Jim Chen
James Cheng
Nathan Froyd
Carsten "Tomcat" Book
James Willcox
Nick Alexander