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>
This allows gomobile bind to stop copying seq.h to the destination.
Change-Id: I4a23613fe0407500ad483ae9d8f6bb823d82f082
Reviewed-on: https://go-review.googlesource.com/12300
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>
Package app contains some logic that we want to share with
gobind-based libraries. So move it to a new internal package
that both can import.
Long term the log changes should be in the standard library,
but the Go tree is currently frozen.
Fixesgolang/go#11630.
Change-Id: I9ff622fc499bf255bce18df23cb68b03f667947f
Reviewed-on: https://go-review.googlesource.com/11981
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Before this change, func Hello() of mypkg package generated a function
GoMypkg_Hello to distinguish the prefix from the function name.
It seems the use of '_' is very rare in Objective-C though.
After this change, it generates GoMypkgHello.
Change-Id: Ic7aa2b667363a447a5ff3500262502d3137d6853
Reviewed-on: https://go-review.googlesource.com/11893
Reviewed-by: Damien Neil <dneil@google.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 existing implementation generates uncompilable objc code for
functions returning two results.
Change-Id: I13f7329596d8fa6103c4b7827c26c5461e16a925
Reviewed-on: https://go-review.googlesource.com/11364
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Translate error type to NSError.
Interface type is not supported yet.
Change-Id: I54abba2360cff41ef8ca08063b0120e7edd65a47
Reviewed-on: https://go-review.googlesource.com/10793
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
With https://go-review.googlesource.com/10638, the reference counting
of Go objects can be simplified. Everytime a Go object is passed into
Objective-C side, a new proxy object with GoSeqRef is created.
Deallocation of a GoSeqRef decrements the reference counter of the
corresponding Go object.
Test the Go object is collected.
Note: It's possible to reduce the number of GoSeqRef
allocations by maintaining a map of weak references to the existing
GoSeqRef, but for now, we allocate a new GoSeqRef instance.
Change-Id: I57a5a4b249c5800d9eba95d128a2cdf74bbef566
Reviewed-on: https://go-review.googlesource.com/10639
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Damien Neil <dneil@google.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>
test.bash is a simple script that builds the c-shared library from
test_main.go, compiles SeqTest.m and the objective-c bindings of testpkg
(testpkg/objc_testpkg/GoTestpkg.*), and runs the output. Eventually this
will be replaced with coed that runs gomobile bind & xcodebuild.
The code under testpkg/go_testpkg and testpkg/objc_testpkg is the output
of gobind (now manually-generated). I am adding it to repo now in order
to get the testpkg/objc_tstpkg reviewed. Eventually, this will be
removed from the repo.
Change-Id: I8d6af3732337992af922cb4615a63f385e19d489
Reviewed-on: https://go-review.googlesource.com/9826
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>
duplicate code from bind/java/seq_android.c to use for obj-c/go binding.
Change-Id: Iefd5d4171cca3a30c5d56f9b37647463e6fd0c5a
Reviewed-on: https://go-review.googlesource.com/9409
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This change deletes unnecessary files - they are auto-generated by
the gomobile bind command.
Change-Id: I490664dfcf52683dd8d2ea821d0b7e458bc06671
Reviewed-on: https://go-review.googlesource.com/8925
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is to enable more flexible encoding/decoding of Go string.
For Java, we use UTF16 to be compatible with java string.
For other languages, we will want other way to represent a string.
Change-Id: Iccd53e2eea18d37636c3c619d06cb473facef0cd
Reviewed-on: https://go-review.googlesource.com/8628
Reviewed-by: David Crawshaw <crawshaw@golang.org>
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>
Tested on darwin/amd64 with
go build golang.org/x/mobile/...
Change-Id: Iec31ccb318913cea5acc7dcec1c6a858bf8654de
Reviewed-on: https://go-review.googlesource.com/5770
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
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>
The State can be used in the Start callback (and lazily-initialized
packages) instead of JavaInit. This stores a reference to the
android.context.Context for the (future) keyboard package and for
setting TMPDIR.
Second attempt at https://golang.org/cl/4400.
Change-Id: I673997b26ab25ce5140cb31950593d8c6dbd9c51
Reviewed-on: https://go-review.googlesource.com/5555
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
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>