This patch adds th state machine for supporting the Gonk sensors
daemon in Gecko. The daemon gets started when the first sensor is
enabled. Sensors can be enabled and disabled at will. The daemon
will send events about detected sensors and sensor events. Gecko's
state machine receives themand forwards them as DOM events.
The old support for device sensors is still present for devices without
sensorsd. A future patch will remove this code.
This patch adds the interface for the Gonk sensors daemon. There
are only two major interfaces: connect and disconnect. The sensors
daemon is started before connecting and stopped after a disconnect.
Connections are race-free: we first set up a listen socket and let
Gecko listen for connections. Then the daemon gets started with the
socket's address as parameter. When the daemon connects to the
socket, Gecko will continue the startup and signal success to the
caller.
The sensor daemon's poll service reads events from the device's
sensors. This patch adds Gecko support for this service. Gecko
receives information about existing sensors and can subscribe to
sensor events. Events will be delivered for each enabled sensor.
A system daemon can contain several services. One of them is the registry
service that manages all other services. This patch adds support for this
service in the Gonk sensors daemon.
This patch adds helpers for using the Gonk sensors daemon. The types
and functions allow for packing and unpacking messages of the daemon's
IPC protocol.
Something defines HEADER_SIZE when including the PDU headers from
hal/gonk. This break the HEADER_SIZE constant in |DaemonSocketPDU|.
This patch adds the prefix PDU_ to all PDU constants.
All the methods in CDMProxy except CDMProxy::OnExpirationChange() that use
mKeys null check mKeys before using it because it can go away during shutdown
before the IPC message to call the methods have had a chance to run.
We should do the null check in CDMProxy::OnExpirationChange() too.
We have very few directories where we have SOURCES declared that are not
part of a library or program in some way. In fact, there is only one
where it is legitimate because we only use the object file
(build/unix/elfhack/inject). Others are the result of moz.build control
flow (see e.g. netwerk/standalone), and we end up building more objects
than we need to.
There are other cases where we need objects without actually linking
them anywhere, but there are other sources in the same directory, and a
corresponding Linkable is emitted. And in fact, the only case I knew
about (media/libvpx), doesn't use such objects since bug 1151175.
Please see the Kinto.js PR for the storage adapter changes:
https://github.com/Kinto/kinto.js/pull/303
Additions and changes to the Firefox storage adapter tests have been made
accordingly.
This reads from "assets/distribution/**" in the APK and writes to
"distribution/**" in the data directory. That output is the same, but
the input used to read from "distribution/**", which is not really
supported by modern build tooling (Gradle), which doesn't allow to
write files directly into the APK root.
I manually tested this without issue. I see no way to add meaningful
tests to our current Robocop test suite; the long term testing
approach is to develop a new test for this functionality and only run
it against the "distribution" build type that was added in Bug
1163080. However, that's a larger project than I have time for now.
--HG--
extra : commitid : JnQ0skxiHW4
extra : rebase_source : 56bdfd947334bd03035046cb24f6bebfbce32d12
extra : histedit_source : aabcffd7434755a4978971a8da238253b15948b6
This simply packs the assets/ subdirectory of the distribution
directory into the assets/ directory of the Android APK using existing
mechanisms. It also removes the older method of manually pushing
files into dist/bin/distribution, from where they would be packaged
into the APK under distribution/.
--HG--
extra : commitid : BLgM6ZCm9AY
extra : rebase_source : 572d1ff35a02505f452fee67130b48c8df4499b5
extra : histedit_source : 0b8f087bc6d70fa42401f4a2476898139bdf606c
A few notes: the test is live, so I've marked it @Ignore, so that it
doesn't run during |mach gradle test|. There's some value in mocking
the service endpoint, but this is how I verify that the server works,
so it has more value right now as a live test than a mocked test. In
the future, that probably won't be true.
There are issues running the test locally because Robolectric doesn't
provide all the cipher suites we use in GlobalConstants: in
particular, the GCM suites aren't supported. This may improve as
Robolectric matures, or we may add a work-around in the code (like at
http://androidxref.com/4.4.4_r1/xref/libcore/support/src/test/java/libcore/java/security/StandardNames.java#68),
or we may add a test-specific flag. For now, I'm not going to address
it directly.
Finally, I put the code in mobile/android/services, simply because the
less that goes into base, the better our build times will be.
--HG--
extra : commitid : Gw8uCqVViMC
extra : rebase_source : 7d35b78cb776fbd3892a2a95190a61846e0a3291
extra : amend_source : dfa8168eaca0a44b05a71fe6fdf4952964460d79
This seems more consistent with what Android UI callbacks do. This commit also
means all callees must be adapted to use the background thread if needed.
--HG--
extra : commitid : AlGQZ8biFZn
I'm slightly concerned we're providing too much configuration information in
the debugging statements.
--HG--
extra : commitid : 6JfBA5lVkZ4
extra : rebase_source : 6cf1befef3aba37031e7fc3306b446e87114b601
During shutdown, we may find ourselves attempting to release and shutdown a probe while the PerformanceStats service is already shutdown. In this case, since the probe is already shutdown, we can simply ignore the error.
--HG--
extra : transplant_source : %BBT%84%26.%AD%7B%23%1C%BC%3F%85%F9%18%A3%D8%84%EC%02%BE
