Also, upgrade the android plugin version used for java/seq_test
from 1.2.3 to 1.5.0
For golang/go#9603
Change-Id: I7b465ff0e607319a08150c4405675832d91edc1e
Reviewed-on: https://go-review.googlesource.com/20411
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Currently there is a Go test package for each platform, iOS and
Android. This CL merges them into a single, shared package. Apart
from the reduced code duplication, the merger stops the tests
diverging further. Most importantly, one shared package clarifies
that the intent of gobind is that the same Go package can be
reused across platforms.
This CL only merges the obvious test duplicates. The rest have been
copied from the ObjC package into the Android test under different
names.
While we're here, demote the long string test to the basictypes
bind test; the test never had a runtime part.
Change-Id: I7838b16999968fae7b012016a5b5f6bb80f94023
Reviewed-on: https://go-review.googlesource.com/20300
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Add a XCTestCase based ObjC driver, SeqTest.m, to run the benchmarks
package on iOS.
While we're here, replace "Java" with "Foreign" in test names to
reflect that benchmarks run on both platforms now.
Change-Id: I38a38f3093b4b97961107b5ea66f03cff8e395c3
Reviewed-on: https://go-review.googlesource.com/20259
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
LOG_FATAL already throws an exception on iOS. Make it abort() on
Android, so that any fatal error will hopefully end up with a useful
log instead of an easily missed message in logcat.
Also, remove return statements after LOG_FATAL on both platforms.
They're unnecessary and confusing and they weren't used consistently
anyway.
Change-Id: I2a8e2e0ac064e95f52ca130de17265c9741cefe4
Reviewed-on: https://go-review.googlesource.com/20257
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Converting a Go string to a string suitable use a specialized function,
UTF16Encode, that can encode the string directly to a malloc'ed buffer. That
way, only two copies are made when strings are passed from Go to Java; once
for UTF-8 to UTF-16 encoding and once for the creation of the Java String.
This CL implements the same optimization in the other direction, with a
UTF-16 to UTF-8 decoder implemented in C. Unfortunately, while calling into a
Go decoder also saves the extra copy, the Cgo overhead makes the calls much
slower for short strings.
To alleviate the risk of introducing decoding bugs, I've added the tests from
the encoding/utf16 package to SeqTest.
As a sideeffect, both Java and ObjC now always copy strings, regardless of
the argument mode. The cpy argument can therefore be removed from the string
conversion functions. Furthermore, the modeRetained and modeReturned modes
can be collapsed into just one.
While we're here, delete a leftover function from seq/strings.go that
wasn't removed when the old seq buffers went away.
Benchmarks, as compared with benchstat over 5 runs:
name old time/op new time/op delta
JavaStringShort 11.4µs ±13% 11.6µs ± 4% ~ (p=0.859 n=10+5)
JavaStringShortDirect 19.5µs ± 9% 20.3µs ± 2% +3.68% (p=0.019 n=9+5)
JavaStringLong 103µs ± 8% 24µs ± 4% -77.13% (p=0.001 n=9+5)
JavaStringLongDirect 113µs ± 9% 32µs ± 7% -71.63% (p=0.001 n=9+5)
JavaStringShortUnicode 11.1µs ±16% 10.7µs ± 5% ~ (p=0.190 n=9+5)
JavaStringShortUnicodeDirect 19.6µs ± 7% 20.2µs ± 1% +2.78% (p=0.029 n=9+5)
JavaStringLongUnicode 97.1µs ± 9% 28.0µs ± 5% -71.17% (p=0.001 n=9+5)
JavaStringLongUnicodeDirect 105µs ±10% 34µs ± 5% -67.23% (p=0.002 n=8+5)
JavaStringRetShort 14.2µs ± 2% 13.9µs ± 1% -2.15% (p=0.006 n=8+5)
JavaStringRetShortDirect 20.8µs ± 2% 20.4µs ± 2% ~ (p=0.065 n=8+5)
JavaStringRetLong 42.2µs ± 9% 42.4µs ± 3% ~ (p=0.190 n=9+5)
JavaStringRetLongDirect 51.2µs ±21% 50.8µs ± 8% ~ (p=0.518 n=9+5)
GoStringShort 23.4µs ± 7% 22.5µs ± 3% -3.55% (p=0.019 n=9+5)
GoStringLong 51.9µs ± 9% 53.1µs ± 3% ~ (p=0.240 n=9+5)
GoStringShortUnicode 24.2µs ± 6% 22.8µs ± 1% -5.54% (p=0.002 n=9+5)
GoStringLongUnicode 58.6µs ± 8% 57.6µs ± 3% ~ (p=0.518 n=9+5)
GoStringRetShort 27.6µs ± 1% 23.2µs ± 2% -15.87% (p=0.003 n=7+5)
GoStringRetLong 129µs ±12% 33µs ± 2% -74.03% (p=0.001 n=10+5)
Change-Id: Icb9481981493ffca8defed9fb80a9433d6048937
Reviewed-on: https://go-review.googlesource.com/20250
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The seq serialization machinery is a historic artifact from when Go
mobile code had to run in a separate process. Now that Go code is running
in-process, replace the explicit serialization with direct calls and pass
arguments on the stack.
The benefits are a much smaller bind runtime, much less garbage (and, in
Java, fewer objects with finalizers), less argument copying, and faster
cross-language calls.
The cost is a more complex generator, because some of the work from the
bind runtime is moved to generated code. Generated code now handles
conversion between Go and Java/ObjC types, multiple return values and memory
management of byte slice and string arguments.
To overcome the lack of calling C code between Go packages, all bound
packages now end up in the same (fake) package, "gomobile_bind", instead of
separate packages (go_<pkgname>). To avoid name clashes, the package name is
added as a prefix to generated functions and types.
Also, don't copy byte arrays passed to Go, saving call time and
allowing read([]byte)-style interfaces to foreign callers (#12113).
Finally, add support for nil interfaces and struct pointers to objc.
This is a large CL, but most of the changes stem from changing testdata.
The full benchcmp output on the CL/20095 benchmarks on my Nexus 5 is
reproduced below. Note that the savings for the JavaSlice* benchmarks are
skewed because byte slices are no longer copied before passing them to Go.
benchmark old ns/op new ns/op delta
BenchmarkJavaEmpty 26.0 19.0 -26.92%
BenchmarkJavaEmptyDirect 23.0 22.0 -4.35%
BenchmarkJavaNoargs 7685 2339 -69.56%
BenchmarkJavaNoargsDirect 17405 8041 -53.80%
BenchmarkJavaOnearg 26887 2366 -91.20%
BenchmarkJavaOneargDirect 34266 7910 -76.92%
BenchmarkJavaOneret 38325 2245 -94.14%
BenchmarkJavaOneretDirect 46265 7708 -83.34%
BenchmarkJavaManyargs 41720 2535 -93.92%
BenchmarkJavaManyargsDirect 51026 8373 -83.59%
BenchmarkJavaRefjava 38139 21260 -44.26%
BenchmarkJavaRefjavaDirect 42706 28150 -34.08%
BenchmarkJavaRefgo 34403 6843 -80.11%
BenchmarkJavaRefgoDirect 40193 16582 -58.74%
BenchmarkJavaStringShort 32366 9323 -71.20%
BenchmarkJavaStringShortDirect 41973 19118 -54.45%
BenchmarkJavaStringLong 127879 94420 -26.16%
BenchmarkJavaStringLongDirect 133776 114760 -14.21%
BenchmarkJavaStringShortUnicode 32562 9221 -71.68%
BenchmarkJavaStringShortUnicodeDirect 41464 19094 -53.95%
BenchmarkJavaStringLongUnicode 131015 89401 -31.76%
BenchmarkJavaStringLongUnicodeDirect 134130 90786 -32.31%
BenchmarkJavaSliceShort 42462 7538 -82.25%
BenchmarkJavaSliceShortDirect 52940 17017 -67.86%
BenchmarkJavaSliceLong 138391 8466 -93.88%
BenchmarkJavaSliceLongDirect 205804 15666 -92.39%
BenchmarkGoEmpty 3.00 3.00 +0.00%
BenchmarkGoEmptyDirect 3.00 3.00 +0.00%
BenchmarkGoNoarg 40342 13716 -66.00%
BenchmarkGoNoargDirect 46691 13569 -70.94%
BenchmarkGoOnearg 43529 13757 -68.40%
BenchmarkGoOneargDirect 44867 14078 -68.62%
BenchmarkGoOneret 45456 13559 -70.17%
BenchmarkGoOneretDirect 44694 13442 -69.92%
BenchmarkGoRefjava 55111 28071 -49.06%
BenchmarkGoRefjavaDirect 60883 26872 -55.86%
BenchmarkGoRefgo 57038 29223 -48.77%
BenchmarkGoRefgoDirect 56153 27812 -50.47%
BenchmarkGoManyargs 67967 17398 -74.40%
BenchmarkGoManyargsDirect 60617 16998 -71.96%
BenchmarkGoStringShort 57538 22600 -60.72%
BenchmarkGoStringShortDirect 52627 22704 -56.86%
BenchmarkGoStringLong 128485 52530 -59.12%
BenchmarkGoStringLongDirect 138377 52079 -62.36%
BenchmarkGoStringShortUnicode 57062 22994 -59.70%
BenchmarkGoStringShortUnicodeDirect 62563 22938 -63.34%
BenchmarkGoStringLongUnicode 139913 55553 -60.29%
BenchmarkGoStringLongUnicodeDirect 150863 57791 -61.69%
BenchmarkGoSliceShort 59279 20215 -65.90%
BenchmarkGoSliceShortDirect 60160 21136 -64.87%
BenchmarkGoSliceLong 411225 301870 -26.59%
BenchmarkGoSliceLongDirect 399029 298915 -25.09%
Fixesgolang/go#12619Fixesgolang/go#12113Fixesgolang/go#13033
Change-Id: I2b45e9e98a1248e3c23a5137f775f7364908bec7
Reviewed-on: https://go-review.googlesource.com/19821
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Address comment from CL/20095.
Change-Id: I2b3b3230106ad27128440609472003c69bd97825
Reviewed-on: https://go-review.googlesource.com/20173
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Since the normal Go benchmark machinery cannot readily be used for
Android apps, a new test, TestJavaSeqBench, is added that builds and
runs the new benchmarkpkg package along with its support Java class
SeqBench. Benchmarkpkg mimics Go benchmarking, in particular it
produces benchcmp compatible output.
Excerpts of the output from a Nexus 5:
BenchmarkJavaEmpty 65536000 26 ns/op
BenchmarkJavaNoargs 256000 7685 ns/op
BenchmarkJavaNoargsDirect 64000 17405 ns/op
BenchmarkJavaOnearg 64000 26887 ns/op
BenchmarkJavaOneret 32000 38325 ns/op
BenchmarkJavaManyargs 32000 41720 ns/op
BenchmarkJavaRefjava 32000 38139 ns/op
BenchmarkJavaRefgo 32000 34403 ns/op
BenchmarkJavaStringShort 32000 32366 ns/op
BenchmarkJavaStringLong 8000 127879 ns/op
BenchmarkJavaSliceShort 32000 42462 ns/op
BenchmarkJavaSliceLong 8000 138391 ns/op
BenchmarkGoEmpty 524288000 3 ns/op
BenchmarkGoNoarg 32000 40342 ns/op
BenchmarkGoOnearg 32000 43529 ns/op
BenchmarkGoOneret 32000 45456 ns/op
BenchmarkGoRefjava 32000 55111 ns/op
BenchmarkGoRefgo 32000 57038 ns/op
BenchmarkGoManyargs 16000 67967 ns/op
BenchmarkGoStringShort 32000 57538 ns/op
BenchmarkGoStringLong 8000 128485 ns/op
BenchmarkGoSliceShort 32000 59279 ns/op
BenchmarkGoSliceLong 4000 411225 ns/op
Benchmarks prefixed with "BenchmarkJava" are for calls from Java into
Go. Benchmarks prefixed with "BenchmarksGo" are the other way around.
Note that all Go benchmarks run against a Java interface implementation
while the Java benchmarks calls Go functions directly. In other words,
every Go call serializes an implicit Java reference, explaining the
higher call times. The JavaRefgo and JavaRefjava tests attempt to
quantify the overhead equivalent for Java.
The "Direct" suffix are for variants that runs the benchmarks from a
new thread or goroutine. For Go it makes little difference, but there
is a noticable speedup when calling Go from Java when there is already
a JNI call context earlier in the stack.
The benchmarks are for Android only for now, but the benchmarkpkg
has been added to the common golang.org/x/mobile/bind package in
anticipation of future iOS support.
Change-Id: I3c948dc710b65bc348e7635416324095060a5beb
Reviewed-on: https://go-review.googlesource.com/20095
Reviewed-by: David Crawshaw <crawshaw@golang.org>
RefMap tracks its number of live Ref instances in the 'live' member.
However, when a reference was removed and later added, 'live' wasn't
updated accordingly. Fix and add a test.
Change-Id: I806e17ea0319d76db4d07b5f8d9107b146ee80db
Reviewed-on: https://go-review.googlesource.com/19975
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
On some Android devices (my HTC One S running Android 4.1.1),
SeqTest failed the testAssets test because the LoadJNI hack to
locate a valid context fails.
Instead, make testAssets set up a valid context acquired from
InstrumentTestCase.
Change-Id: If6e11173dbacff45eb6cb0f409f56cbd88186e30
Reviewed-on: https://go-review.googlesource.com/19896
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Avoid taking a good name (seq) away from users.
Fixesgolang/go#14168
Change-Id: I88e90cb74b479e348c642a1caa27096ed4a6d68e
Reviewed-on: https://go-review.googlesource.com/19601
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The existing implementation has memory leaks on two local variables
that are not deleted after use. Android app will crash after this issue.
add UnitTest for this issue.
Fixesgolang/go#14346
Change-Id: Ic233d15556ac97b35e00e13279a572c48a03049f
Reviewed-on: https://go-review.googlesource.com/19532
Reviewed-by: Elias Naur <elias.naur@gmail.com>
The Seq Java class has a special case for null references. Expand
the special case to Go so that null references from Java are properly
translated to nil.
Fixesgolang/go#14228
Change-Id: I915d1f843c9db299d6910480f6d10dae0121a3b4
Reviewed-on: https://go-review.googlesource.com/19460
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Java methods from Go are run on a thread pool managed on the Java side,
to avoid the complexities of getting Go threads to play along with the
Android JVM. However, for call stacks that contain a Java->Go->Java
chain, this behaviour confuses Java code sensitive to specific threads
if the Go->Java call is executed on an arbitrary thread from the pool.
For example, most Android UI changes must happen on the single UI
thread.
Replace the thread pool with direct calls to mimic ObjC<->Go and
Java->Go calls. Threads not already attached to the JVM are attached.
Introduce a thread local variable to detach such threads at thread exit.
Change-Id: I8cb65803c9278666ae77a0c7a65dc2d9c7e739e1
Reviewed-on: https://go-review.googlesource.com/19334
Reviewed-by: David Crawshaw <crawshaw@golang.org>
An inspection of the RefTracker inc and dec methods suggests
that a particular Java Stub instance is included in the javaObjs
map if and only if its reference count, refcnt, is larger than zero.
A newly created reference created by RefTracker.createRef has zero
refcnt but was also inserted in the javaObjs map, violating the invariant.
Fix that by not inserting new references in javaObjs. Without the fix
a Stub instance that were never passed to Go would leak, along with
any other instances it referenced, transitively.
This fixes a Java reference tracking problem, I have not verified if
the same problem applies to the Go and ObjC sides of the Seq machinery.
Change-Id: I3ede90d5258630bc837fe61bba850df222d09a26
Reviewed-on: https://go-review.googlesource.com/19261
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This allows reuse of the code in custom gomobile bind tools.
Change-Id: I4e013ca871d0fa64983e7efb5e1e9dad8ac723c0
Reviewed-on: https://go-review.googlesource.com/18581
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Fixes the bug in 64bit platforms.
Change-Id: I499995d69db03d136dcb2ca7f930ba1e309c8b6d
Reviewed-on: https://go-review.googlesource.com/19070
Reviewed-by: David Crawshaw <crawshaw@golang.org>
not harmful, but this consistency may simplify cgo handling
in some custom build systems
Change-Id: Id4692986725b3737c23cdeb9ce1a1fa2bc9f7dad
Reviewed-on: https://go-review.googlesource.com/18615
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This removes the last dependency on an Android class in the running
gobind code. (Tests still need some work before they will run on the
desktop.)
Change-Id: I49bfb545d4587c6f430c0938fa1ca4d513b56d77
Reviewed-on: https://go-review.googlesource.com/17252
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The aim of the RefTracker is to "... pin Java objects so
they don't get GCed while the only reference to them is
held by Go code." But in the case of null objects there is
nothing to GC. Therefore we do return a single Ref which
contains a null object, but we ignore the logic that is used
to pin for GC purposes.
Change-Id: If3771ec0180d09485963c3297abccb39a1a8d9ab
Reviewed-on: https://go-review.googlesource.com/13647
Reviewed-by: David Crawshaw <crawshaw@golang.org>
seq.Transact is called when Go calls a method of a foreign object
that implements a Go interface. Currently, we assume that the foreign
object has an instance method that can conduct the message routing,
so the object id and the method code is sufficient for transact.
Passing the interface descriptor (e.g. go.testpkg.I) however allows
the bind internal to use non-instance methods to implement the routing.
Change-Id: I1f61a04f919fbd09117ea332d678cd50e4861e46
Reviewed-on: https://go-review.googlesource.com/12685
Reviewed-by: David Crawshaw <crawshaw@golang.org>
mem_ensure is to ensure the remaining space in buffer
is large enough to hold extra size bytes. We've been passing
the target capacity instead of the number of extra bytes we
need.
Change-Id: Ic6f6ddb4ad22cbcdbc44eb4a58e6a415ae771fb2
Reviewed-on: https://go-review.googlesource.com/12578
Reviewed-by: David Crawshaw <crawshaw@golang.org>
non-varargs call of varargs method with inexact argument type for last
parameter
Change-Id: I7623951c365b8cf899a17ee784c8d4f3b4bdb198
Reviewed-on: https://go-review.googlesource.com/12528
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is done by moving app.Context to internal/mobileinit,
introducing mobileinit.SetCurrentContext and,
making bind/java depend on it.
TODO: check gomobile bind's proguard rule - context lookup
was implemented through reflection on android.app.AppGlobals class.
Change-Id: Ieb6ad503eeef8c2c1c5836a21c667938c5a701a2
Reviewed-on: https://go-review.googlesource.com/12279
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The goal here is to remove several inconsistencies between
-target=android and -target=ios support, along with making the flow
of the command follow the path you might expect given a certain set
of flags, and preparing for `gomobile bind` support of ios. In
particular, building non-main packages now works with both targets
and the initialization of global build state is clearer.
The reorg also is designed around an nm trick I thought of
yesterday to do better package import scanning without a slow
all-file scan. This will give better detection of x/mobile/app and
x/mobile/exp/audio/al packages. There's a TODO about it, and I'll do
it in a future CL.
Tested with:
go test golang.org/x/mobile/cmd/gomobile
gomobile init
gomobile bind golang.org/x/mobile/asset
go test golang.org/x/mobile/bind/java
gomobile build -target=ios golang.org/x/mobile/example/basic
gomobile build -target=ios golang.org/x/mobile/gl
gomobile build -target=android golang.org/x/mobile/gl
gomobile build -target=android golang.org/x/mobile/example/basic
(Along with manual testing of basic on an android device.)
That might make a pretty good _test.go.
Change-Id: I41230008c3c15db25a11c33b9eaca4abada9f411
Reviewed-on: https://go-review.googlesource.com/12051
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Android support has advanced to the point where this logging statement
adds very little information.
Change-Id: I3c8c9d60be8c0b52a519f9e44711bd211b5bfe67
Reviewed-on: https://go-review.googlesource.com/11990
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Historically, the app package implemented Go runtime initialization.
This was convoluted, so the package was used both by all-Go apps
(currently based on Android's NativeActivity) and bind-based apps.
With Go 1.5 we have -buildmode=c-shared, which does a lot of the work
of the old app package. That code was removed a while back, but both
all-Go and gobind-based apps still used package app. The intermingled
initialization processes led to some strange states.
This CL separates gobind-based apps completely from the app package.
As part of that users are now expected to use System.loadLibrary
themselves. (A future CL may want to make the loadLibrary call part
of the .aar generated by gomobile bind.)
Delete the libhello example, which has been replaced by gomobile bind,
which could do with its own example at some point. Also delete the
libhellojni example, which now has nothing to do with the x/mobile
repository.
Change-Id: I444397f246dbafe81e5c53532eb482c197d26f70
Reviewed-on: https://go-review.googlesource.com/11654
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The gobind framework is supposed to use reference counting to
keep track of objects (e.g. pointer to a Go struct, interface
values) crossing the language boundary. This change fixes two bugs:
1) no reference counting on Java object: Previously, the lifetime
of a Java object was manages in the following way.
a. The Java object is pinned in an internal map (javaObjs) when it's
constructed.
b. When Go receives the reference to the Java object, it creates a
proxy object and sets a finalizer on it. The finalizer signals Java
to unpin the Java object (remove from the javaObjs map).
c. The javaObjs map is also used to identify the Java object when
Go asks to invoke a method on it later.
When the same Java object is sent to Java more than once, and the
finalizer (b) runs after the first use, the second use of the Java
object can cause the crash described in golang/go#10933.
This change fixes the bug by reference counting the Java object.
Java side pins the Java object and increments the refcount whenever it
sees the object sent to Go (in Seq.writeRef). When the Go proxy
object's finalizer runs, the refcount is decremented. When the refcount
becomes 0, the object gets unpined.
2) race in Go object lifetime management: Pinning on a Go object
has been done when the Go object is sent to Java but the Go object
is not in the pinned object map yet. (bind/seq.WriteGoRef).
Unpinning the object occurs when Java finds there are no proxy objects
on its side. For this, Java maintains a reference count map (goObjs).
When the refcount becomes zero, Java notifies Go so the object is
unpinned. Here is a race case:
a. Java has a proxy object for a Go object.
b. Go is preparing for sending the same Go object. seq.WriteGoRef
notices the corresponding entry in the pinned object map already,
and returns. The remaining work for sending the object continues.
c. The proxy object in Java finalizes and triggers deletion of the
object from the pinned object map.
d. The remaining work for (b) completes and Java creates a new proxy
object. When a method is called for the Go object, the Go object is
already removed from the object map on Go side and maybe already GC'd.
This change fixes it by converting the pinned object map to reference
counter map maintained in Go. The counter increments for each
seq.WriteGoRef call. The finalizer of the proxy object in Java causes
a decrement of the counter.
Fixesgolang/go#10933.
Renables the skipped testJavaRefGC.
Change-Id: I0992e002b1050b6183689e5ab821e058adbb420f
Reviewed-on: https://go-review.googlesource.com/10638
Reviewed-by: David Crawshaw <crawshaw@golang.org>
After CL 10296 the workaround from CL 9783 is no longer necessary.
Revert the workaround but keep the global reference, just in case.
Change-Id: I3fdd580e4122c36508beb9d328739b910dbbe2e2
Reviewed-on: https://go-review.googlesource.com/10483
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This ensures that the java bindings are ready before any calls are
made by user code. As a bonus, the JNIEnv* is from the Seq class so I
believe no tricks are required to find the right class loader.
Fixesgolang/go#10903.
Change-Id: I33b3b39cef6cc2da36e271de882ba8d26610ea34
Reviewed-on: https://go-review.googlesource.com/10296
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Also fixes a parameter name handling problem when processing a
function signature that omits parameter names.
Fixesgolang/go#10788.
Change-Id: I65273d330bbf3a836ec9e4ffb691927970d795d8
Reviewed-on: https://go-review.googlesource.com/9926
Reviewed-by: Alan Donovan <adonovan@google.com>
The previous way (JNIEnv's FindClass with "[B") does not work
in Android-L for some reason.
Change-Id: I5cccb7bbf651df981a923ecade863302521d5c5c
Reviewed-on: https://go-review.googlesource.com/9783
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Config provides a way to concurrently access Width and Height.
Register provides a way for packages to run code on app state change
without plumbing changes all the way to the process main function.
This is motivated by gl/glutil.Image which needs to rebuild its
textures on start/stop and can be deeply nested.
(See golang.org/cl/9707 for the followup.)
Tested manually on android and darwin/amd64. Doing this kind makes it
clear any CL modifying this code needs a lot of manual testing right
now, so some kind of trybot support is something I'm going to
prioritise.
Fixesgolang/go#10686Fixesgolang/go#10461Fixesgolang/go#10442Fixesgolang/go#10226
Updates golang/go#10327
Change-Id: I2882ebf3995b6ed857cda823e94fbb17c54b43a8
Reviewed-on: https://go-review.googlesource.com/9708
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The global constructor added for -buildmode=c-shared takes care
of a lot of the messier steps that were being done here.
Change-Id: I00525765855b2ad0fcecb0639d6a7ee3feea9ed9
Reviewed-on: https://go-review.googlesource.com/9648
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
