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>
David Crawshaw
Hyang-Ah Hana Kim
Meir FischerandDavid Crawshaw
Daniel SkinnerandDavid Crawshaw
Elias NaurandHyang-Ah Hana Kim