This CL contains an Android-specific Manager implementation.
On Android, we create a new ALooper for each Manager instance and
all CGO calls are proxified to an OS-thread-locked goroutine.
Change-Id: I33272cd4369d0b7850f97e840fe4bbe5aee78ec0
Reviewed-on: https://go-review.googlesource.com/8249
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Manager ops are not promised to be thread-safe.
Change-Id: Ib28b80d758234a7a19287c457c57099e36d73f9b
Reviewed-on: https://go-review.googlesource.com/8248
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Sensors package will contain APIs to read data from a wide variety
of movement, position and other physical signals.
This CL contains the initial APIs that are targeting event-based
sensors. Some of the concerns that influenced the APIs are:
- Target game developers. Latency is critical, allow output rates
up to ~10 samples per second.
- It’s rarely possible to predetermine the minimally viable sample
rate requirement of the app. - Allow users to set an upper bound rate
to avoid garbage and preserve battery life.
- Allow multiple instances of accelerometer, gyroscope, magnetometer
and altimeter sensors to be started. Optimize the share of the
underlying resources as long as it is not a bottleneck for the
sample rate.
- Prefer blocking APIs. An automatic
poll-timeout could be useful if we’re far behind the sample rate.
But, sensor initialization and waking-up significantly take longer
and there is no easy way to determine a sensor is in either one of
these states.
- Provide timestamps for each event to determine the actual rate of
the sensor data.
- Allow user to return multiple events from each call. Buffering the
events at the cost of additional latency is sometimes more
neglectable than the overhead of a function call that polls the
events one by one. Allow user to determine how many items they want
to buffer. The typical latency of a read a single event is 56 usec.
Reading 8-16 events at once has a relatively lower bound per event.
For high precision throughput, the opportunity to minimize a
function call overhead could be useful.
- Allow users to check the sensor availability on the device.
Change-Id: I9582c8f025d9f922d9635e247d60817f95bdacb9
Reviewed-on: https://go-review.googlesource.com/8174
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
