to enable safe usage of settings no matter which process is getting/setting them.
Previously, different processes were accessing settings in an unsafe way and the warn methods were throwing Runtime exceptions which went largely unnoticed, but happened, especially on a fresh start of the OS.
Change-Id: Ie4134e7be2a7ca4a373790f45fbcbd09bf02ad86
When using GCM on a roaming connection, the heartbeat interval is set
to: `networkRoaming * 6000`. It should instead be
`networkRoaming * 60000` because we're converting from a number of
minutes (stored in the properties) to a number of milliseconds, like
it's done for regular mobile and wifi connections.
With version 20.1.1 the Firebase Cloud Messaging SDK started to use
the Firebase Installations SDK, which affects the FCM registration
process.
The implementation of FCM registration in microG failed to pass extra
parameters that became relevant with the introduction of the
Firebase Installations SDK to the FCM registration endpoint.
These additional parameters are passed through to the endpoint with an 'X-' prefix.
- Update all submodules, used sdk version, etc
- Settings UI rebuild
- Some GCM features and fixes
- Fix newest Cast Framework for some apps (tested with "ZDF Mediathek")
Fixes#224, #223, #145
- 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).