| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
- SdkController/SdkControllerLib: move files in Apps' .../lib
- SdkController/SdkControllerSensor + MultiTouch: remove.
- SdkController/SdkControllerApp: move to upper folder,
we don't need the subfolders anymore.
Besides the removal/move of the file, there's no
code change in the app itself.
Change-Id: Ib35428d7b10fd6eb849c7ec343fe5a23bf60ed97
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Landscape layout for sensor activity.
- Fixes some comments from change Ia4ae2e71.
- Limit update rate to 50 Hz, default to 20.
- Fixed typo in temperature sensor name which
prevented it from being recognized.
- Replaced the String.format for sending emulator
string data by StringBuilder.append(float).
On an ADP2 device this reduces the time from
an average 9-15 ms to 1-2 ms.
Change-Id: Iad5fe3fada23dbdf4bc7cc162fb2daeaf8a113f5
|
| |
|
|
| |
Change-Id: I2ce4006cfc30d2de956d246f1d5059d4032fc32c
|
| |
|
|
|
|
|
|
|
| |
This adds a sample rate field in the sensor
activity. The sensor handler uses that to limit
the updates sent to the emulator -- simply discard
updates that come in too fast.
Change-Id: Ia4ae2e71eda4ed844ddc9b8b0657df2306e03674
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One issue in SdkController now is that for every single sensor
update we compute 2 string.formats, which take about forever
(around 2-4 ms each on a GN.) One is used for the UI display
so we don't need to do it when updating the sensor, instead
we can keep track of the sensor values and defer the UI string
format at display time.
This also adds code to measure timings in the sensor update
loop. It's disabled by default.
In a next CL I will replace the string.format(%g) by something
else. Using Float.toString and a StringBuilder should be
a tad more efficient since we don't need Locale-dependant
formatting (and arguably should NOT have any in fact).
Change-Id: If9e01e88c76bcd9e433df0f40c7ab28d697655e7
|
| |
|
|
|
|
|
|
|
| |
Also refactor some common code from the SensorActivity
into the BaseBindingActivity.
Also rework the handler-to-UI update mechanism.
Change-Id: I0a38b16ae2b2b4adb802298793cefa51b1a73104
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SdkController Lib:
- separate new EmulatorConnection() from the actual connection.
This makes it easier to construct the object first and then
start the connection from a thread. Otherwise the
onEmulatorBindResult() callback might be called before the
main thread gets the EmulatorConnection reference.
SdkController App:
- Main activity: Display some usage help on the screen.
- Sensor handler: Fix the blocking queue used to send the
sensor events to the emulator. Also display a status
and report any connection errors.
Change-Id: Iea0f9e79256ebd5ecfef573d33efce306a0a5722
|
| |
|
|
|
|
| |
This should explain what's going on.
Change-Id: I328abd139c297dad41dd8cbbdaca8e6c977e30c4
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In SdkControllerLib:
- Add an "onEmulatorBindResult" callback to the emulator
listener that indicates the result of the bind operation.
This makes it easier to create the EmulatorConnection
from within a thread and capture the success/error when
it happens.
In the apps:
- Changed to use the new onEmulatorBindResult.
- Changed the app names to make them easier to indentify
in the home launcher.
- Added the missing onPause in the legacy sensors app to
close the emulator connection (otherwise trying to restart
it fails because the port is still bound by the paused
instance)
- In fact really the legacy activities should be in
singleInstance mode.
Change-Id: Ie194a75f9babebe74c899ea9327b3e4dcfe39f41
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This implement sensor control using the service.
The service has a number of "handlers" (e.g.
multitouch or sensors).
The sensor handler is automatically started by the service.
The multitouch handler OTOH will just be waiting till the
controlling activity connects to it.
Change-Id: Ic5f92063916efba2c4f503d2607b58bbbe4e0ccf
|
|
|
This is just a basic app that has a background
service and an activity to start/stop the service.
The service has a binder interface (so that the
activities can control the service) and a listener
(so that the service can report to activities.)
The service automatically starts with the app and
there's a toggle for the user to turn it off/on.
The activity also reports errors from the service, if any.
There's a notification when the service is running.
which brings back to the control activity.
Change-Id: I67d37e3d905eb328f4d1f7d13fb118f4c7077b74
|
