Running the benchmark is very slow so I don't do it often. As
could be expected, the benchmark driver didn't compile anymore.
Change-Id: I59475042b7fca63328a96d769e77b8a7a6bbbb06
Reviewed-on: https://go-review.googlesource.com/110056
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
On Android, the JNI jobject type doesn't always contain a pointer.
Treating a non-pointer as a pointer can crash the runtime. Use
the more appropriate type uintptr instead.
Change-Id: I2b2049918d60226c4d23d6df0b10e68248d54bc2
Reviewed-on: https://go-review.googlesource.com/110256
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
With CL 107957, the appropriate way to check that the gomobile
binary is up to date is by using go list -f {{.Stale}}. Use that
instead of go install -x -n.
Fixesgolang/go#24389
Change-Id: I93a4428b048f0be9463c61928673886445dce3ed
Reviewed-on: https://go-review.googlesource.com/108055
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Sun Shine <mizommz89@gmail.com>
Gradle plugin failed on Mac due to -i flag trying to update /usr/local/go
Since go 1.10, The old advice to add the -i flag for speed,
as in go build -i or go test -i, is no longer necessary:
builds run just as fast without -i.
Fixesgolang/go#25076
Change-Id: Ibddab3ff5961e06c8558f2a83af8a6964d622f40
Reviewed-on: https://go-review.googlesource.com/109144
Reviewed-by: Elias Naur <elias.naur@gmail.com>
A previous CL switched gobind to use the "source" importer so go
files using cgo can be type checked. However, CGO_ENABLED=1 also
have to be passed in for such files not be ignored.
Also add -tags ios to the gomobile test output missing from CL
99777.
Fixesgolang/go#24941
Change-Id: I868469af3061b82ab592899e365a8a90a0333e58
Reviewed-on: https://go-review.googlesource.com/108336
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
CL 99316 changed gobind to be platform independent, so
standalone bindings could be generated without having the
Android and Xcode SDKs installed. However, bindings that does
depend on GOOS for its exported API, in particular go source
files that use Cgo now only works if the exported API is
extracted to platform independent files.
By switching to use the source importer, importer.For("source", nil),
gobind can type check the bound packages even in the presence of
Cgo.
The source importer in Go 1.9 and 1.10 has problems with relative
imports and imports from testdata directories (issues 23092 and 24392),
but works from Go 1.10.1 on.
Fixesgolang/go#24856
Change-Id: Icb18dce15325b7d4e58cabc1181051bc6269fc1f
Reviewed-on: https://go-review.googlesource.com/99777
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
When passing a refnum across the language barrier there is a small
window where a proxy object itself can be garbage collected, its
reference count go to 0 and the object be gone when the refnum
is dereferenced on the other side.
In Go the proxy object is pinned with runtime.KeepAlive. This CL
implements the same mechanism in Java by passing the proxy object to
native code, ensuring the Java GC can't reclaim it during the call.
Change-Id: I23824439012eb00f90d729f59d4846999f24f01f
Reviewed-on: https://go-review.googlesource.com/107095
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Android runs a finalizer watchdog that tracks the running time of
finalizers and throws an exception if any runs too long. Our
finalizers do very little work and as such are not affected by the
timeout. However, there has been reports, for example:
https://stackoverflow.com/questions/24021609/how-to-handle-java-util-concurrent-timeoutexception-android-os-binderproxy-fin
that the watchdog does not take into account periods where the device
goes to sleep in the middle of a finalizer run. So if a given app runs
in the background, the Java GC starts a finalizer and the device goes
to sleep before it returns, an exception will crash the app if the sleep
period extends the watchdog timeout.
The problem might be fixed on some newer version of Android, but the
problem is reported for as late as Android 6.
The suggested workaround is to use PhantomReferences and run a
background thread that take dead references off a ReferenceQueue and
perform cleanup.
This CL builds on the previous CL and splits up the Ref class so Refs
only reference counts Java objects, while a new class GoRef tracks Go
references. The Go references are wrapped in PhantomReferences that in
turn appear on a GoRefQueue to be cleaned up by a background (daemon)
Thread.
Change-Id: I04e3296b851999c612d3baf6a593cc044c2c5bdd
Reviewed-on: https://go-review.googlesource.com/106876
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Today, the Seq.Ref class has two purposes. For Java references,
Ref contains the refnum, a reference to the Java object and a
reference count. For Go references, Ref contains the refnum and
its finalizer makes sure to decrement the reference count on the Go
side.
The next CL will replace the use of finalizers with an explicit
ReferenceQueue of Go references, and the Ref class will no longer
be used for Go refences. To prepare for that, this CL pulls up the
construction of Go referencing Ref instances into the Seq.trackGoRef
function.
Change-Id: I9eefe238cd3fd1b661b2af11d331a2f61e31303b
Reviewed-on: https://go-review.googlesource.com/106875
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Before this change, binding unsupported basic types such as
uint failed with an error. Instead, add them to the list of
ignored types so that no error is generated and a comment is
generated explaining why the offending function, constant or
variable was skipped.
Unsigned integers are probably easy to support in ObjC, but
leave them unsupported for now.
While here, improve the printing of the ignored types in the
explaining comments.
Fixesgolang/go#24762
Change-Id: I0d9ab471b2245728270f6ee588f554d4a105d500
Reviewed-on: https://go-review.googlesource.com/105377
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Bindings are independent of any particular GOOS/GOARCH pair and
as such the gomobile bind command doesn't set GOOS nor GOARCH when
running gobind. However, the ios tag was still added to the list
of tags to pass to gobind for -target=ios.
Move the ios tag to when actually building the bound packages,
mirroring gomobile build.
Add TestBindIOS and update TestBindAndroid.
Updates golang/go#24644
Change-Id: I007829c26036427a3376bba11a1ccb86e7338848
Reviewed-on: https://go-review.googlesource.com/104458
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Delay loading of the getRune method ID to the first GoNativeActivity
is created. That way, importing golang.org/x/mobile/app will not
crash, even for gomobile bind programs that don't include (or use)
GoNativeActivity.
Fixesgolang/go#24490
Change-Id: I4bf90e067700451f7c026e53165b6614366d7a94
Reviewed-on: https://go-review.googlesource.com/104395
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
For some reason, the changes to the build tags that was supposed to
go in with CL 102915 didn't make it.
Fixesgolang/go#24644
Change-Id: I106b3c71fef1088dd1eea193323c13d81e5985fa
Reviewed-on: https://go-review.googlesource.com/104355
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Forgot to update tests on macOS after CL 102915.
Change-Id: I902fd1046434d133129a0cd82bc28c3f7ee47816
Reviewed-on: https://go-review.googlesource.com/104455
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
While we're here, add 386 to the list of supported architectures
on iOS.
To support gomobile build for amd64 and 386, use the "ios" tag to
distinguish between iOS and macOS builds.
Change-Id: Ie09a432794bd8d9853950115349f8d3b57cf43f5
Reviewed-on: https://go-review.googlesource.com/102915
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Now package names for Android is generated based on the given package
path's base name, And the package name generation fails when the base
name consists of only digits (e.g. github.com/hajimehoshi/ebiten/examples/2048).
This CL fixes this problem by allowing only-number base name.
Fixes#24511
Change-Id: I6108c46823d0b2ee08869b306922f62351fb1510
Reviewed-on: https://go-review.googlesource.com/102576
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Instead of using os.Getenv("GOPATH"), use go env GOPATH to determine
the effective GOPATH.
Fixesgolang/go#21658
Change-Id: I03f897969e30fc3256d171aa7b32c101a9342a1a
Reviewed-on: https://go-review.googlesource.com/101117
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
When running gomobile bind, make sure gobind exists. If not, instruct
the user to run gomobile init which will go install gobind.
Change-Id: I2d064ba58874fd5581c17417124561f3d1fb6b83
Reviewed-on: https://go-review.googlesource.com/101055
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Issue golang/go#24058 demonstrates a Go package that fails to build with
gomobile but builds successfully with a manually using the standalone NDK
toolchain. I haven't been able to figure out a set of CPPFLAGS/LDFLAGS
that fixes the build for 24058 so instead rework gomobile to use
standalone NDK toolchains.
Standalone toolchains fixes the 24058 build and is the official way
to build Android programs. So gomobile should be less affected by
future changes in the NDK toolchain internals.
Create the standalone toolchains with gomobile init.
With the new Go 1.10 build cache, the prebuild work by the gomobile
init command is useless. Use the opportunity to simplify init to
only creating NDK toolchains and, optionally, building OpenAL for
Android. With that, it is no longer necessary to use gomobile init
to build iOS apps and frameworks.
Fixesgolang/go#24058
Change-Id: I4692fcaa927e7076a6387d080ebc1726905afd72
Reviewed-on: https://go-review.googlesource.com/99875
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
gomobile checks "golang.org/x/mobile/..." packages are included in
the build product using nm.
If "golang/x/mobile/..." package is placed under vendor directory,
this check fails and it is treated as a build failure.
Fixesgolang/go#22152
Change-Id: Ie0e05c3e0340b3608de5c68bb3f852d4ef7cdeb1
Reviewed-on: https://go-review.googlesource.com/102095
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Move the benchmark support package to the testdata directory, just
like the other test packages.
Change-Id: Idc35ca973a7da78e8c8bb640ba60cfb947fbed5b
Reviewed-on: https://go-review.googlesource.com/101896
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
If ever the gobind tool switches to a source importer (see CL
99777), make sure import paths are without trailing slashes are
handled correctly.
Change-Id: Ib3ce15f8dcd53dce09a5bb183e4013a5deba39b4
Reviewed-on: https://go-review.googlesource.com/99776
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The reverse bindings allow access to Java and ObjC APIs by importing
Java/... and Objc/... package from Go. The gobind tool automatically
create the bindings for the API referenced from the packages.
The reverse example takes that ability too far, however. It creates
a circular dependency from the Android databinding layout files to
exported Go types while those same Go types access the Java classes
generated by databinding. It works almost by accident, but not for
newer Gradle versions.
The circular dependencies are bad, but the underlying circular references
created by using the reverse bindings this way are worse. I haven't found
a satisfactory was to avoid retaining references to Go objects from Java
and back without carefully and manually breaking cycles at appropriate
times. One might succeed in ObjC where breaking reference cycles are
already necessary, but not in Java.
The reverse example is a nice technical feat, but promises more than
it can deliver. Delete it.
Fixesgolang/go#19862Fixesgolang/go#18210
Change-Id: Ie6abd2a0ebd4c4ce36339d1294898e15f22f83bd
Reviewed-on: https://go-review.googlesource.com/101155
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Gobind now outputs Java sources to the java/ subdirectory. Update the
gradle plugin to match. Only projects using reverse bindings are
affected.
Change-Id: Id7f893d3c67a9ab63336c4e031c9196a0b6dad2c
Reviewed-on: https://go-review.googlesource.com/99775
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The gobind and gomobile bind tools have historically overlapped:
gobind outputs generated bindings, and gomobile bind will generate
bindings before building them. However, the gobind bindings were
never used for building and thus allowed to not be complete.
To simplify version control, debugging, instrumentation and build
system flexibility, this CL upgrades the gobind tool to be the
canonical binding generator and change gomobile bind to use gobind
instead of its own generator code.
This greatly simplifies gomobile bind, but also paves the way to skip
gomobile bind entirely. For example:
$ gobind -outdir=$GOPATH golang.org/x/mobile/example/bind/hello
$ GOOS=android GOARCH=arm64 CC=<ndk-toolchain>/bin/clang go build -buildmode=c-shared -o libgobind.so gobind
$ ls libgobind.*
libgobind.h libgobind.so
The same applies to iOS, although the go build command line is more
involved.
By skipping gomobile it is possible to freely customize the Android
or iOS SDK level or any other flags not supported by gomobile bind.
By checking in the generated source code, the cost of supporting
gomobile in a custom build system is also decreased.
Change-Id: I59c14a77d625ac1377c23b3213672e0d83a48c85
Reviewed-on: https://go-review.googlesource.com/99316
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The gobind command is about to get more powerful and able to generate
complete and standalone bindings. Platform specific build tags based
on GOOS or GOARCH are now meaningless to generate bindings from, so
remove them from the test packages.
The tags mattered to the reverse bound packages, since the go tool can't
build them without the Go wrappers for the imported Java packages.
Before this CL, the `android` tag was used to fool the go tool since
the host GOOS is unlikely to be android.
A fix is to check in the generated Go wrappers, but since the
packages are for testing we don't want that. Instead, move the test
packages to the testdata directory so the go tool ignores them.
Change-Id: I57178e930a400f690ebd7a65758bed894eeb10b0
Reviewed-on: https://go-review.googlesource.com/99315
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The default ObjC prefix and Java package have been the empty string
for a while, but the gomobile bind -help text wasn't updated.
Change-Id: I8acb265ae7385121fae4c2cc314220d97575d20c
Reviewed-on: https://go-review.googlesource.com/99317
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
In the spirit of CL 99955, fix all non-standard generated code
headers and re-run the generators. Some generated files needed
git gofmt afterwards, but that problem is left for now.
Change-Id: I6b3131fb1753dc427d05af03107031120755cab0
Reviewed-on: https://go-review.googlesource.com/99975
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The output takes up many lines and obscures other test output from
go test -v.
Change-Id: I0896717db3ce287f9e4b4263451475c19758b0e3
Reviewed-on: https://go-review.googlesource.com/99778
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The extra build can't be required, because it is not run for the
build of the first GOARCH later in the loop. Tests run fine
without it.
Change-Id: Ida27e31ace2417192cce06c2efc93fa0d357012e
Reviewed-on: https://go-review.googlesource.com/98975
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
A check for the NDK was missing from the pre-install of the standard
library for each Android GOARCH. If the NDK wasn't set, the go install
invocation would silently use the host GOARCH and GOOS and only fail if
no host gcc was found for runtime/cgo.
Discovered while setting up gomobile on a clean Windows machine.
With the go 1.10 cache go installing the standard library might be
pointless, but let's wait a little before removing it.
Change-Id: I880eed32aad23fda10ae92bd35be2ce9b03ddb86
Reviewed-on: https://go-review.googlesource.com/96636
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Remove the android support library dependency.
The Android build system assumes at least one resource, so
add a dummy string.
Change-Id: I7223b75709f1aa5907e6d04bc656eea5503bb640
Reviewed-on: https://go-review.googlesource.com/94195
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
When there is no prior gradle cache (i.e .gradle/ directory isn't created yet) in your Android project and a gradle build command is executed (e.g ./gradlew build), the *.so files generated by the gobind android plugin is not packaged into the apk.
Successive builds work fine though.
This issue doesn't happen when using Android plugin version 2.x, but does using version 3.x.
The gomobile bind task, libTask, is only finalizing the java compile task which allows it to run in parallel with javaCompile. That is probably too late, so instead, make libTask a dependency of the compile task to make sure the output of gomobile bind (in particular, the *so libraries) are included in the final build product.
Fixesgolang/go#23766
Change-Id: I62727bfa0ffd54d8158c3a2aa3d7303867fcbabc
Reviewed-on: https://go-review.googlesource.com/94835
Reviewed-by: Elias Naur <elias.naur@gmail.com>
The test in CL 87656 exposed the problem that an ObjC class C in
header C.h can't implement an interface I in I.h if I.h itself includes
C.h, resulting in an include cycle. Avoid the problem for now by
restricting the set of declared interfaces to the current package and
its imports. This is too strict, but simple and avoids any include
cycles.
Fixes the bind/objc SeqTest on iOS.
Change-Id: I2ff964593cb9e56994c42b68cc49eebe2f549217
Reviewed-on: https://go-review.googlesource.com/88818
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Since the xcrun binary exists in macOS from the beginning, it can not be used to check that Xcode is available.
The xcodebuild command does not return an error if Xcode is available.
Reference https://go-review.googlesource.com/c/mobile/+/35852
Change-Id: Ibb6324a2d801eab47b3544c50ee1cdbc36b608bc
Reviewed-on: https://go-review.googlesource.com/88755
Reviewed-by: Elias Naur <elias.naur@gmail.com>
