Current output byte-for-byte of pkg binres is close,
but not exact, to output of aapt.
The current exceptions to this are as follows:
* sort order of certain attributes
* typed value of minSdkVersion
These differences do not appear to affect the encoded
manifest from working correctly. Further details on
the byte differences can be seen in TestEncode.
Fixesgolang/go#13109
Change-Id: Ibfb7731143f0e2baeeb7dd5b04aa649566606a53
Reviewed-on: https://go-review.googlesource.com/20030
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
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>
Native activity callback onInputQueueCreated does not attach
a looper to the input queue within android.c. Various examples
of first detaching looper on the web are based around use of
native_app_glue_code which does attach a looper before passing
on to user callback.
Calling detachLooper pre-5.0 results in a crash. I didn't track
down exact source for this but code that likely made it's way
into 5.0 given the time frame can be seen to show a recast of
and iter over size() of a container.
This possibly explains the lack of crashing for 5.0+ instead of
potentially referencing a null pointer pre-5.0.
Fixesgolang/go#13741
Change-Id: Ie04de9f34436a95c456a56b34f1ca7e6adc00b09
Reviewed-on: https://go-review.googlesource.com/20145
Reviewed-by: Nigel Tao <nigeltao@golang.org>
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>
Before this CL, BufferInit always causes INVALID_ENUM error because
0 (a2) is always passed to 'usage' argument of glBufferData.
This CL fixes removes a2, shifts a3 to a2, and adds parg as null
pointer explicitly.
Fixesgolang/go#14403
Change-Id: I11109c983316f5975a79f42dc51d7a180e222b91
Reviewed-on: https://go-review.googlesource.com/19703
Reviewed-by: David Crawshaw <crawshaw@golang.org>
As a follow-up to CL/19472, I am removing the unnecessary casts. It
turned out that the only call sites that will benefit from this change
are the ones added in CL/19472. Sorry for the additional CL.
Change-Id: Ib6bdffefad5b84beb57108a74ebcedc25b7ef7b3
Reviewed-on: https://go-review.googlesource.com/19653
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
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>
This fixes remaining issues that prevented use of package
to encode manifest for packaging correctly.
* Chunk headers are now encoded based on content
* Fixes for namespace and value fields
* Improved sorting based on native aapt output
Change-Id: Ic63046973a7b0431533463ed4dd2de50f1d73191
Reviewed-on: https://go-review.googlesource.com/19224
Reviewed-by: David Crawshaw <crawshaw@golang.org>
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>
To implement an interface in Java the interface type must be listed
in the class declaration. Emulate the implicit Go interface
implementations in Java by listing all possible (non-empty) interfaces.
For example, given
type (
S struct{}
I interface {
M()
}
)
func (s *S) M() {
}
in Go, the Java class S will be declared to implement the Java
interface I.
Fixes a TODO.
Change-Id: I5b0d2dd65938004ab29029f481cace4b8fb4b26f
Reviewed-on: https://go-review.googlesource.com/19417
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The TestBindAndroid test complained about diffs in the gomobile
output. Updated the tests to match, under the assumption the current
output is correct.
Change-Id: I8ee7ee91bf7993ec7b96fc90646b1ff0fc80dfb2
Reviewed-on: https://go-review.googlesource.com/19461
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
from 0.2.2 to 0.2.3
Change-Id: I906200acf9615c8cc100b7d1ad5592e899e383fe
Reviewed-on: https://go-review.googlesource.com/19409
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>
The OpenTable func now references a prepacked version of the
resources.arsc file with a number of entries removed. The current
size of this file is 62KB. This could be dropped further by
implementing utf8 in string pool during marshal, utf16 encoding exploded
the original size by approximately 20%. Another potential improvement
is to allow type entries to be packed sparsely which may provide
significant savings if not zipping.
Change-Id: Ie139c2bdb0e3c5a9212516d18cf627d75774e187
Reviewed-on: https://go-review.googlesource.com/18649
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Instead of failing.
Change-Id: I157f77aca1d02bfcdcf4f06278bcf5cc786834df
Reviewed-on: https://go-review.googlesource.com/18616
Reviewed-by: Daniel Skinner <daniel@dasa.cc>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
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>
Much like the recent change for OS X, this puts the Go paint loop in
control of drawing onto the screen.
Change-Id: I37321e4bb58869d4c7cafc51951ea64e540d536b
Reviewed-on: https://go-review.googlesource.com/15611
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Andrew's new example/flappy does a better job of demoing off these
packages, and I would like to keep our example count under contorl.
Change-Id: I77f4da78815055ab91510ce0cb97bbd7ac1bac3b
Reviewed-on: https://go-review.googlesource.com/18381
Reviewed-by: Andrew Gerrand <adg@golang.org>
This makes the following program valid:
----
package main
import (
"fmt"
"golang.org/x/mobile/event/size"
)
func foo() size.Event { return size.Event{} }
func main() {
fmt.Println(foo().Bounds())
}
----
Previously, you would get:
./main.go:12: cannot call pointer method on foo()
./main.go:12: cannot take the address of foo()
Change-Id: I2801d18a04d56d1c7496cb008531d078490ccf86
Reviewed-on: https://go-review.googlesource.com/18356
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This decodes enough information to allow validation of resource
names but not their values, though a simple method for querying
does not yet exist.
Change-Id: I32023f3de0eda390b12d5c1df6c06202ee4d0778
Reviewed-on: https://go-review.googlesource.com/18055
Reviewed-by: David Crawshaw <crawshaw@golang.org>
OpenGL ES is not installed by default on linux distributions, which
can lead to a cryptic error. Add a comment after the #include
mentioning what packages contain OpenGL ES on Ubuntu, which is
helpfully printed in the error message. For example:
$ go build golang.org/x/mobile/example/basic
# golang.org/x/mobile/gl
In file included from ../../mobile/gl/work.go:21:0:
work.h:6:117: fatal error: GLES2/gl2.h: No such file or directory
#include <GLES2/gl2.h> // install on Ubuntu with: sudo apt-get install libegl1-mesa-dev libgles2-mesa-dev libx11-dev
Change-Id: Ia7ba583cee4dfdeed408f582b29da90de9a4fab3
Reviewed-on: https://go-review.googlesource.com/18058
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Daniel Skinner
Hyang-Ah Hana Kim
Elias Naur
Nigel Tao
Hajime Hoshi
Burcu Dogan
ttyh061
David Crawshaw