Make the generated SDK binding files depend on the annotation processor
jar file, so that changes in the annotation processor will cause the
bindings to regenerate.
Add Bundle to the list of SDK classes to generate JNI bindings for. The
generated bindings, like other SDK classes, use XPCOM-style nsresult
to indicate success/failure, and return values through out-parameters.
This works around a race condition observed with GENERATED_SOURCES. A
global solution might be to make GENERATED_SOURCES part of the
'export' tier; this is a smaller fix.
--HG--
rename : widget/android/bindings/mediacodec-classes.txt => widget/android/bindings/MediaCodec-classes.txt
rename : widget/android/bindings/surfacetexture-classes.txt => widget/android/bindings/SurfaceTexture-classes.txt
extra : rebase_source : 073dadd8c1b48ea32f975b2232c2bdeafe315ab4
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
AJ Kerrigan
James Willcox
Nick Alexander