The builder doesn't have javap nor the Android fonts installed.
Change-Id: Ia3965be967482aa76b0c8c83b951deb30ebe5645
Reviewed-on: https://go-review.googlesource.com/c/mobile/+/167057
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Some x/mobile tests are designed to run from a host with a device
or emulator attached. Some fail if they run directly from a device,
which is the case when GOOS=android.
Fix the tests by skipping them or adjusting them to work on GOOS=android.
Remove gomobile environment naïve variable expansion for $HOME; on
Android devices HOME=/ so every path separator is replaced with
$HOME.
Fixesgolang/go#30482
Change-Id: I553e708226922f6284163f0b7d7b1011a9502e34
Reviewed-on: https://go-review.googlesource.com/c/164799
Run-TryBot: Elias Naur <mail@eliasnaur.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Go documentation style for boolean funcs is to say:
// Foo reports whether ...
func Foo() bool
rather than "returns true if" or "returns whether".
Change-Id: I5d01c45a8867b47462ed142a49ad51bf0a319ce1
Reviewed-on: https://go-review.googlesource.com/c/151957
Reviewed-by: Elias Naur <elias.naur@gmail.com>
The OpenGL C function glTexImage2D has the following signature:
void glTexImage2D(GLenum target,
GLint level,
GLint internalFormat,
GLsizei width,
GLsizei height,
GLint border,
GLenum format,
GLenum type,
const GLvoid * data);
However, the corresponding Context.TexImage2D method in package gl
does not include the internalFormat parameter, and use the format
argument instead. That's ok for many texture formats; for example,
RGBA textures have both format and internalFormat set to GL_RGBA.
But not always. In particular, OpenGL ES 3 allows the use of sRGB
encoded textures by specifying GL_SRGB8_ALPHA8 as internalFormat,
but keeping GL_RGBA as format.
Add the internalFormat to the Context package. This is unfortunately
a breaking change, but adding a new function ("glTexImage2D2"?) to
Context is too ugly for a parameter that should have been there all
along. (Adding a new method to the Context interface is technically
also a breaking change, but I don't expect that there are any
external implementers of the interface).
Change-Id: I12a45a34f604e51cb1be26aed906025ccfac533a
Reviewed-on: https://go-review.googlesource.com/133155
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>
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>
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 test broke a long time ago when the underlying API changed.
It seems too useful to remove outright, so disable it until someone
cares enough to update it.
Updates golang/go#19046.
Change-Id: Iec49be30fbc2e3ffd6fa73e584b15a481751049f
Reviewed-on: https://go-review.googlesource.com/37321
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Use Context.getApplicationInfo().nativeLibraryDir to locate
libopenal.so. That path is always correct, even on newer devices.
Found while testing external NDK use on Windows.
Manually tested; there are no existing OpenAL tests or examples.
Change-Id: Ie204a7d7139566f85c9121126722ad597f9d6b19
Reviewed-on: https://go-review.googlesource.com/35175
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Since nothing about this high-level player will stay the same after
the audio work core types are finalized, there is no good point in
keeping the naive implementation around.
Removing also the audio example.
Updates golang/go#9551.
Change-Id: I5a7666c77e043aeacf44356e20e8d90822fd78e7
Reviewed-on: https://go-review.googlesource.com/27671
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: Jaana Burcu Dogan <jbd@google.com>
The error message from cgo will print the line, which now
includes the instruction as a comment.
Change-Id: I208365b5b1e4da0bd6df89882586fe438f7391b4
Reviewed-on: https://go-review.googlesource.com/25384
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 underlying implementation was not enabling the sensors on a
particular sender even though the Enable signature accepts different
instances of Sender to enable.
Consider the following program:
type A struct{}
func (a A) Send(ev interface{}) {}
type B struct{}
func (b B) Send(ev interface{}) {}
sensor.Enable(A{}, sensor.Gyroscope, time.Millisecond)
sensor.Enable(B{}, sensor.Accelerometer, time.Millisecond)
is going to compile but only A will be notified when there are new
gyroscope and accelerometer events.
In order to improve the misleading APIs, this CL introduces a
Notify function that users can register a Sender implementation to
listen the changes. If set nil, the sensor package will keep
reading the events but will won't notify.
sensor.Notify(A{})
sensor.Enable(sensor.Gyroscope, time.Millisecond)
sensor.Enable(sensor.Accelerometer, time.Millisecond)
Change-Id: I25e43349e4ae682930baa2d32430f46f24b588b7
Reviewed-on: https://go-review.googlesource.com/15650
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Naked returns must be used for self-documentary reasons. In this
unexported package, it is not useful to name return values.
The change has been contributed on a previous CL but I don't know
what happened, it should have been lost on a bad merge.
Change-Id: I6cb9c3a58ad397aeb646f3e57e482628fe31ca31
Reviewed-on: https://go-review.googlesource.com/15658
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
readEvents never return an error, readSignal should not have an
error field.
Change-Id: I9566a6905ee678599fdad18f85ae55d1fdc16cc1
Reviewed-on: https://go-review.googlesource.com/15550
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Several notices, notes and questions have become obsolete when
CL/15438 is merged. Removing the TODOs pointing to the bug explained
in CL/15438's description.
Change-Id: I8a94507a6d0aa507a58be451336eba36dd383d64
Reviewed-on: https://go-review.googlesource.com/15551
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The init signal's job could be done at the top of the proxying
goroutine.
Change-Id: Icb907946a679d3eca6bec5e12adeb2bedc0908f0
Reviewed-on: https://go-review.googlesource.com/15490
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Only the loopers allocated with ALooper_acquire are releasable. We are
depending on the looper associated to the thread which will be
automatically released when the thread is being terminated.
Trying to re-release a looper makes the app crash with segfault.
Change-Id: Ib80549de01f5f44143752c13a82b6b4a2ab5610e
Reviewed-on: https://go-review.googlesource.com/15491
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The sensor package had a deadlock case if it started to poll the
events but all sensors have been disabled on the underlying ALooper.
Consider the following program:
app.Main(func(a app.App) {
sensor.Enable(a, sensor.Gyroscope, time.Millisecond)
go func() {
time.Sleep(5 * time.Second)
sensor.Disable(sensor.Gyroscope)
time.Sleep(2 * time.Second)
sensor.Enable(a, sensor.Gyroscope, time.Millisecond)
}()
for e := range a.Events() {
case sensor.Event:
//...
}
The initial Enable will enable the gyroscope and start polling events
from the ALooper. After 5 seconds, the gyroscope will be disabled.
ALooper_pollAll(-1, NULL, &events, NULL)
will block indefinately because there are no events will be
available until another sensor is enabled.
After 2 seconds, we will attempt to enable the gyroscope again. But,
the underlying thread will be blocked at pollAll and won't be able
to make the sensor enabling call on the same thread.
In order to overcome this deadlock case, this thread introduces a
hard timeout limit during polling. If timeout occurs, the looper
thread will be unblocked and select{} statement will be able to
handle {enable,disable,close}Signal cases.
Fixesgolang/go#12501.
Change-Id: I35efa2e29057ca37f8ac0f38be8dc59c9b8262b3
Reviewed-on: https://go-review.googlesource.com/15438
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
All OpenGL functions are now methods on a Context interface. The
gl.Context matches the one loaded into thread-local storage in C.
For mobile apps, the context is owned by an app.App. For now, it is
provided through the events channel on a lifecycle event. Long-term,
it should probably be available by a method on app.App, but this is
inherently racey with our current use of a channel to deliver events.
Shiny-based programs will have a gl.Context associated with a each
shiny.Window. The expectation is each Window will have different
contexts, allowing them to draw separately.
Change-Id: Ie09986fb74e493129f2ea542a151c95c6fa29812
Reviewed-on: https://go-review.googlesource.com/13431
Reviewed-by: Nigel Tao <nigeltao@golang.org>
It is now the user's job to track the lifetime of a glutil.Image
relative to a (currently implicit, soon to be explicit) GL context.
This is an attempt to move glutil.Image closer to the model for
buffers and textures in shiny. Long-term, I would like to adopt that
model, and this is a step in that direction. It also makes the
introduction of *gl.Context possible, so this is a pre-req for
cl/13431.
Change-Id: I8e6855211b3e67c97d5831c5c4e443e857c83d50
Reviewed-on: https://go-review.googlesource.com/14795
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Replace the direct access to JavaVM* and the global android Context
instance with a function responsible for running attached correctly
to the JVM. This saves having to replicate the logic for attaching an
OS thread to the JVM. While here, check for any unhandled Java
exceptions.
This supersedes cl/11812.
Change-Id: Ic9291fe64083d2bd983c4f8e309941b9c47d60c2
Reviewed-on: https://go-review.googlesource.com/14162
Reviewed-by: Nigel Tao <nigeltao@golang.org>
The manager type is not required, because the APIs don't allow
more than one event sources as they used to. In this CL, I am
flattening out the underlying implementations by removing the
manager type.
Change-Id: I3b606ac160b9cecd85cb657e3df1d7d789604764
Reviewed-on: https://go-review.googlesource.com/14293
Reviewed-by: Nigel Tao <nigeltao@golang.org>
The former Reader inspired APIs were designed to timeout if no events
occur after an excessive amount of time. As we switch to the app
event based model, timing out is not required. We can block on
pollAll forever until new events arrive.
Change-Id: I086fc908ebfe6ae9bd96ce9199636ad0242bbec5
Reviewed-on: https://go-review.googlesource.com/14223
Reviewed-by: Nigel Tao <nigeltao@golang.org>
The CL provides accelerometer events only, upcoming CLs will add
support for gyroscope and magnetometer.
Change-Id: Ib5629ca7c49c9dfc8ca533fe7acde371efc102b2
Reviewed-on: https://go-review.googlesource.com/14036
Reviewed-by: Nigel Tao <nigeltao@golang.org>
We are also limiting the number of sensor managers to one.
The application provide sensor events to third-party packages
by consuming them in the main.
An application will be able to consume the sensor events similar
to the other events.
package main
func main() {
app.Main(func(a app.App) {
// enables the accelerometer
sensor.Enable(a, sensor.Accelerometer, 100*time.Millisecond)
var sz size.Event
for e := range a.Events() {
switch e := app.Filter(e).(type) {
case sensor.Event:
log.Println(e)
}
}
})
}
Change-Id: Iaad1c59f8d2322c7620df62ed9b9283c91746fa8
Reviewed-on: https://go-review.googlesource.com/13983
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Also remove an unnecessary constant type conversion.
Change-Id: Iff466553fac450bd531785f4fb4e2be97a991a52
Reviewed-on: https://go-review.googlesource.com/13715
Reviewed-by: Burcu Dogan <jbd@google.com>
Hoping to learn more so I can debug or replicate the darwin/amd64
builder failure, which is not creating a GL context.
Change-Id: I9f2fe54fbd9a072c65cd37c3b711554d4c71171f
Reviewed-on: https://go-review.googlesource.com/13693
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Elias Naur
Tobias Klauser
Elias Naur
Jean-André Santoni
Péter Szilágyi
Jaana Burcu Dogan
Hana Kim
Andrew Gerrand
David Crawshaw
Angelo Bulfone
Nigel Tao