This fix compilation problem using AOSP source tree since it does
not handle (yet?) Graddle generated files.
Ignore also Android Studio generated files.
Signed-off-by: Julien Bolard <jbolard@genymobile.com>
- Do vtm-jni loading ourself to load correct architecture, fixes#95, related to #97
- Do not falsely announce unsupported mips architecture
- Cleanup ContextWrapping
- Add dummies for GeoData and PlaceDetection APIs
- Restart GCM when package is restarted, related to #100
- Add two Google signatures to acceptable apps. Likely to increae this further
- Fix small change in GCM unregistering
- Modify intent delivery for GCM, related to #75 and #84
- Lint fixes
- Update Travis CI config
- Update build tools
- Update sublibs
- Add proper PlacePicker, fixes#65
- Add selfcheck
- Improvements to MCS connection, related #31#54
- Do not crash when permission to GPS is not granted
- Various smaller fixes
The output stream handler thread might not be alive, this occurs
reproducibly when connecting fails and a tear down is initiated.
Messages shouldn't be sent when the output handler thread is not alive
(triggers an expection which is catched but logged), this check avoids
this unless some special race condition occurs. Dropping the messages
shouldn't hurt (they were dropped anyway).
This terminates the input stream when an error occurred and does not
wait for the handler thread in the McsService to send the interrupt
signal.
This hopefully fixes a situation that I had where tear down messages
were created in a busy loop because of repeatedly reading -1 from the
input (I don't know how it got into the situation as the log was filled
with the messages from the tear down).
This stores the timestamp of the last ack message that has been
received. The connection is considered to be dead if the last ack
message has been received more than twice the configured interval ago.
This changes how the alarms for heartbeat pings are scheduled. Instead
of a repeating, inexact alarm that may be delayed (at least up to 15
minutes), either an exact alarm (below Android 4.4) or an interval is used
which ensures that the alarm fires between half the configured interval
and the configured interval. This interval allows the OS to optimize
alarms a bit. For Android 6.0 further adjustments are probably
necessary.
