- Extend AbstractSettingsActivityV2
- Replace all checkbox preferences with switch preferences
- Add app:useSimpleSummaryProvider to all preferences that were in getPreferenceKeysWithSummary
- Add null checks on all prefs to fix crashes in nested preference screens
- Replace listeners with lambdas to reduce code indentation
- Set input type to number where relevant
This class introduces some of the common logic across preference
screens, handling nested PreferenceScreens, as well as the back button
and action bar title setting.
* Check for bluetooth permissions in DiscoveryActivity
* At startup we now pop up a dialog explaining why we want *any* permissions
* Fixing ControlCenterv2 permissions requests for Android S and later (requesting background location stopped *any* dialog appearing)
* Fixing all errors in DiscoveryActivity from Android Studio by catching errors
* Move permission requests around to ensure that we only call RequestMultiplePermissions from onCreate
* Only show dialog if we have permissions to request
* Fix "LifecycleOwners must call register before they are STARTED" on some Android devices: https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/3192/files#issuecomment-967267
Allow for support classes to send a write request response to the
device, fi requested. The standard actually expects this to happen, but
Gadgetbridge did not originally support it, so there are concerns that
enabling this globally will cause issues for devices that do not expect
the response.
See also: https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/2831#issuecomment-941568
- Remove notification on unneeded characteristics for Zepp OS devices
- Reset MTU before initializing device, since the support class is
reused when reconnecting, and keeping the previous high MTU before
renegotiating again can make the initialization fail sometimes
(band will never reply)
- If any of the chunked characteristics is null during initialization,
mark the device as waiting for reconnect, which will make it retry the
connection later with a backoff delay.
HuamiSupport handles configurations with performInitialize, which may
trigger a device reinitialization if called while the device is already
initializing.
Handle fitness goals in Huami2021Support, which should be one of the
last settings still missing.
Since we now handle chunked acks as of 74dac3f5c, these may happen
during device initialization. We must not use performInitialized, or
initializeDevice will be called twice, since the device will still not
be in INITIALIZING state.
Now that the target SDK was changed to 31, the `no.nordicsemi.android:dfu`
library needs to be updated, as the current version dies on Android 12+.
However, the fixed version (1.12.0) also fixed MTU handling: The previous
versions ignored the MTU settings completely for legacy DFU.
<https://github.com/NordicSemiconductor/Android-DFU-Library/pull/260>
And while our `PineTimeJFSupport` code always tried to set MTU to 517, it was
ignored. Which was good because PineTime does not support larger MTUs. So that
we need to set the correct low MTU now the library really applies it.
Note that the current version of the DFU library cannot be used right now, it
does not even compile because of androidx dependency mismatch.
Fixes#3203
- rename service identifiers for clarity
- define BLE scan filter in the coordinator (even though GB does not use those currently)
- rename `DownloadedFitFile` to `GarminFitFile`
- bump DB schema version to 49
- use `BLETypeConversions`, added the missing functions there (+ unit tests for all)
- change Java package of Protobuf definitions so that they are not discarded by Proguard
-- +add subpackages to the Proguard rules so we can subdivide the classes
+ disable device-specific settings for Vivomove (no settings yet)
- communication protocols
- device support implementation
- download FIT file storage
Features:
- basic connectivity: time sync, battery status, HW/FW version info
- real-time activity tracking
- fitness data sync
- find the device, find the phone
- factory reset
Features implemented but not working:
- notifications: fully implemented, seem to communicate correctly, but not shown on watch
Features implemented partially (not expected to work now):
- weather information (and in future possibly weather alerts)
- music info
- firmware update: only the initial file upload implemented, not used
Things to improve/change:
- Device name hardcoded in `VivomoveHrCoordinator.getSupportedType`, service UUIDs not available
- Download FIT file storage: Should be store (and offer the user to export?) the FIT data forever?
- Obviously, various code improvements, cleanup, etc.
Extract handling of packet types with large code blocks.
Incidentally fixes "intent" packets launching a full calendar sync if
intents are disabled in GB settings.
More robost toJSON that deals with unicode and null
Log messages when converting words to images so we can debug when words are being converted that shouldn't be
- Make ChartsHost independent from ChartsActivity
- Rename ChartsActivity to ActivityChartsActivity
- Rename AbstractChartFragment to AbstractActivityChartFragment
- Pull common charts logic to parent classes:
- From ActivityChartsActivity to AbstractChartsActivity
- From AbstractActivityChartFragment to AbstractChartsFragment
It is 2023, it should work, if not it can be turned off.
For newer devices with big firmwares and apps (like Mi Band 7), people just wonder how slow Gadgetbridge installs stuff...
Previously we used an integer (in meters) but when using
Google Maps navigation, Google Maps picks units based on locale *and*
the distance - it might report "100m" or "20km". Then we carefully undo
all that work, and for PineTime we just as "m" so you may well have "20000m"
or more displayed, which is not ideal.
I imagine at some point that will change, but we probably want to
be able to handle that in the OSMAnd side of Gadgetbridge so all watches
that implement navigation will benefit (and won't duplicate code).
Add extra 'ETA' field to NavigationInfoSpec
Allow Local Notifications from Google Maps to be parsed into NavigationInfoSpec by GoogleMapsNotificationHandler
Moved notification handling after blacklist check as per https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/3136#issuecomment-920095
Ensure we don't create a nav message for 'Location Shared with you' messages.
Recognise 'ft' as a distance unit and convert accordingly
Google Maps navigation: Adding new recognised icons, and removing warnings/errors from file
The expiry time should be 6h (60 * 60 * 6), but has been set to 6 minutes (60 * 6) unintentionally in 3 places.
This change sets the expiry to the correct value throughout the file.
Signed-off-by: kieranc001 <kieranc001@noreply.codeberg.org>
Updates WeatherSpec to v3 to add fields for UV index and precipitation probability
Co-authored-by: Enrico Brambilla <enricobilla@noreply.codeberg.org>
Co-committed-by: Enrico Brambilla <enricobilla@noreply.codeberg.org>
Every call to Volley.newRequestQueue() creates a new global thread pool,
which isn't automatically cleaned up once the request completes.
With this commit we create a RequestQueue around on first use, and reuse
it for subsequent requests.
This also touches parts of the app not only used for bangle.js.
E.g. pending intents gets new flags from SDK 23 inclusive.
Bluetooth permissions are updated to work on SDK 31.
Permission handling is updated to the new way for doing it with
introduction of a new function. This is called for newer sdk versions.
bump Bangle.js flavor targetSdkVersion to 31
update comments re SDK 31
set the 'exported=true' I introduced to false instead - except for three places
add uses-permission for handling bluetooth in order to work on api >30
add if-blocks adding FLAG_IMMUTABLE to PendingIntents on api >30
add link to bluetooth documentation
Add comment to banglejs manifest. Add requirement annotation to ControlCenterv
bump compileSdkVersion to 31
add "OpenAppSettings" permission popup while working out individual permission popups on android 13
if SDK < 31 do permissions one by one, else send user to app info page to switch permissions manually
working solution, but needs cleaning
do some cleaning, not done though
remove some logging
remove import Log
tweak and remove toasts in new permissions handling
Change conditions `> Build.VERSION_CODES.Q` to `>= Build.VERSION_CODES.R` matching the style used everywhere else
Revert "Change conditions `> Build.VERSION_CODES.Q` to `>= Build.VERSION_CODES.R` matching the style used everywhere else"
This reverts commit 2929629ff43fbb685eb3d15e42459f321f68fa11.
Revert "add if-blocks adding FLAG_IMMUTABLE to PendingIntents on api >30"
This reverts commit ed8e1df7bb8b71fee745fbf9d10747d47c8f6cb8.
Pending intents gets `PendingIntent.FLAG_IMMUTABLE` if `(Build.VERSION.SDK_INT >= Build.VERSION_CODES.R)`.
Bangle.js: undo `@RequiresApi` code R
... to remove error in Android Studio where declared required api was
higher then minSDK version.
Use FLAG_MUTABLE for reply to test notification
This should fix Gadgetbridge crashing when replying to the test
notification from the debug activity. As reported here:
https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/2924#issuecomment-917282
Change to use FLAG_IMMUTABLE/_MUTABLE from SDK 23
... as suggested by Android Studio. This is supposed to make the app
more secure by not allowing certain changes to pending intents where
they are not expected. If I understood correctly.
Add PendingIntentUtils class to manage mutability
Introduce a reusable abstract logic for repeated fetch operations.
Add fetch operations for the following:
- Stress (manual and automatic)
- SpO2 (normal and sleep)
- Heart rate (manual and resting)
This affects available features (eg. Alexa). Defaults to the previous
value of "unknown" for now, and no UI. Alexa requires a region where it
is available, such as Germany ("de").
Currently, huami only attempts to fetch activities once.
Since sports activity fetching creates an Operation twice per every fetch, we
need to pass around fetchCount variable to keep track of how many fetches has
occured.
Tested on my Amazfit GTR 4.
Signed-off-by: Oleg Vasilev <me@svin.in>
Mostly copied from the Buds Pro as those earbuds have a similar feature set and mostly the same protocol.
Working:
- Pairing
- Earbud and case battery level
- Finding lost device
- Settings:
- Noise control:
- ANC/ambient/off
- With one earbud
- Voice detect and timeouts
- Ambient sound during calls
- Touch options:
- Touch lock
- Switch noise control, voice assistant, Spotify and volume actions
- Double tap edge
- Equalizer
- Sound balance
- Seamless earbud connection
Can be improved:
- ~~ANC level and ambient sound volume do nothing, and don't seem to be supported on this model as there is no toggle for either in the official app.~~ (fixed: 26a9d274ae)
- Ambient sound customization has more options than on previous models, but I can't implement it properly as I can't really hear any difference between the options (my buds might be the issue though).
- ~~The touch lock toggle is once again inverted, like on the [Buds2](d2c4990c48)~~ (fixed: 21db5390c1).
Untested:
- Settings:
- In-ear detection for calls
- Ambient sound customization
- Game mode
This PR also makes some visual changes to the settings of various Galaxy Buds models.
I'd also like to be added to the wiki's allow list. I want to add the Buds2 and Buds2 Pro to the list of supported devices.
---
And sorry for creating this many pull requests. This is mostly due to Codeberg breaking the reference to the branch.
Co-authored-by: Narek <narek.email@gmail.com>
Reviewed-on: https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/3049
Reviewed-by: José Rebelo <joserebelo@noreply.codeberg.org>
Reviewed-by: Andreas Shimokawa <ashimokawa@noreply.codeberg.org>
Co-authored-by: narektor <narektor@noreply.codeberg.org>
Co-committed-by: narektor <narektor@noreply.codeberg.org>
This tries to use bearing and number of satellites if available. ~~Bangle.js watch currently sets course=NaN in it's implementation of the GPS event handler, so to be of use this needs a small change there as well: [https://github.com/espruino/BangleApps/pull/2504](https://github.com/espruino/BangleApps/pull/2504)~~ Change has been merged.
Please advise on needed changes or oversights, thanks :)
Co-authored-by: Martin Boonk <martin@boonk.info>
Reviewed-on: https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/3026
Co-authored-by: halemmerich <halemmerich@noreply.codeberg.org>
Co-committed-by: halemmerich <halemmerich@noreply.codeberg.org>
Disable manual heart rate measurement - the current implementation in Gadgetbridge seems not really compatible with Bangle.js. There's no way to turn the HRM off when the window is closed, and HRM samples from *any* device would appear to be shown - not just the one that HRM info was requested on
This is done by just comparing the names with already existing devices.
This is only a temporary solution until the discovery of the service
UUID works properly
Removed logging in the DeviceCoordinator, fixed the time setting (day
was off by 1), consolodated many characteristic transactions to one
buidler and queue, and added Find My Device, by just initiating a call.
Moved to AbstractDeviceSupport so each device support class can override them if required. This change helps to keep the code base clean by not requiring every (Device)Support class to implement these methods even when they don't need them.
Switch to only saving 0xCE as sample data, mark additional known data
Remove unused updateSample from testing
Add 0xDD handling
Fix byte comparisons
Add SpO2 parsing, still unused. Cleanup
Clean remaining anomalies
Fix order sign blunder filtering out all data
Remove unproductive/improper debugging prints
The original truncation code caused the null termination of the string
to be dropped, leading to several weird issues on the watch, including
empty notification bodies and firmware crashes.
Since the PR #2961 aswell as #2976, i pushed the changes to this pr.
Original text:
With this PR, the gadgetbridge app sends the current locationd data, obtained from the gps or network provider, to a connected banglejs device as an "gps" event.
The bangle device can use this data instead of the internal gps data. Therefor saving battery energy, since the gps chip is one of the biggest energy consumers.
Furthermore it enables the banglejs device to use the location data, based on the network with which the phone is currently connected. This would be usefull if there is no gps signal.
Updates:
I added a network provider so that it is possible to use the network location. I also overload the start method of GBLocationManager so that it is now possible to select which provider should be used to get the data (currently GPS or Network) and to set a interval to determine how often the update should be run.
For the banglejs device i added a switch to enable the sending of gps data. I also added a setting, to set the interval on how often the gps data is being updated. This allows to throttle the updates of the gps data and therefore saving energy of the smartphone batterie.
To further save energy, the app now requestes the current status of the gps from the banglejs and only sends data, if the gps of the banglejs is turned on.
In the PR #2976 I also moved the settings to the device settings of the banglejs and i moved the logic to the onLocationChanged method of the GBLocationManager.
Co-authored-by: Lukas <lukas.edi@gmx.net>
Reviewed-on: https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/2992
Co-authored-by: LukasEdl <lukasedl@noreply.codeberg.org>
Co-committed-by: LukasEdl <lukasedl@noreply.codeberg.org>
This works by adding the ability to pause the sending of data from the Bluetooth LE queue. While BtLEQueue is modified, unless setPaused(true) is called it behaves exactly as before so shouldn't cause any issues.
- get rid of pre-lollipop BLE discovery (nowadays we support only lollipop and above) and related preference
- get rid of the sequenced BT-then-BLE-scan that wasn't working reliably anyway and was causing a recursion
- add a caching layer for already processed devices (the same device is found multiple times during discovery)
- add a caching layer for device name in GBDeviceCandidate (many coordinators will ask for it, and it's a very expensive operation)
Mostly copied from the Buds Pro as those earbuds have a similar feature set and mostly the same protocol.
Co-authored-by: narektor <narektor@noreply.codeberg.org>
Co-committed-by: narektor <narektor@noreply.codeberg.org>
