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>
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>
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>
Go.init must be called once and from the main thread.
setUp is called from a non-main thread and once per each test.
Change-Id: I848a1461793463785b38141e077da5bf5e53cb4c
Reviewed-on: https://go-review.googlesource.com/6832
Reviewed-by: David Crawshaw <crawshaw@golang.org>
To exercise the code path that uses Context given to Go.init.
Change-Id: Ied1f9efff325c711275a1969c373011c59e1d08d
Reviewed-on: https://go-review.googlesource.com/5750
Reviewed-by: David Crawshaw <crawshaw@golang.org>
When passing a byte array from Java to Go, Seq.writeByteArray JNI
call encodes only the array size and the pointer to the array.
Go-side receives the (size, ptr) pair info during the subsequent
Seq.send JNI call, and copies the elements into a Go byte slice.
We must pin the array elements until Go-side completes copying
so that they are not moved or collected by Java runtime.
This change keeps track of the pinned array info in a 'pinned' linked
list, and unpin them as the Seq memory is freed. The jbyteArray
argument passed to Seq.writeByteArray is needed to release the pinned
byte array elements, but that is a "local reference". It is not
guaranteed that the reference is valid after the method returns. Thus,
we stash its global reference in the 'pinned' list and delete it later
as well.
A similar problem can occur on the byte slice returned from a Go function.
This change does not address the case yet.
Fixesgolang/go#9486
Change-Id: I1255aefbc80b21ccbe9b2bf37699faaf0c5f0bae
Reviewed-on: https://go-review.googlesource.com/2586
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This change makes gobind to generate proper Go-side proxy code to
handle interface methods that have parameters and return values.
It allows gobind to accept struct pointer types as parameters
or a return value of a method.
Fixesgolang/go#9487, golang/go#9488.
Change-Id: Id243c42ee0701d40e3871e392140368c2f8f9bc6
Reviewed-on: https://go-review.googlesource.com/2348
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The new testLongString triggers the bug without this change.
Fixesgolang/go#9251.
Change-Id: I463e2897b5b08f53801f151c7311d591546c0719
Reviewed-on: https://go-review.googlesource.com/1373
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Hyang-Ah (Hana) Kim
David Crawshaw
David Crawshaw