The DeviceCommunicationService calls `#setAutoReconnect` on new device
supports before it calls the connect method. Since this method did not
get relayed to the connection-specific support classes, Xiaomi devices
using a BLE connection did not automatically reconnect because the
`mAutoReconnect` field in `AbstractBTLEDeviceSupport` never got set.
Earlier Xiaomi devices would send either 0 or 100 for the requested
volume to indicate whether the app should increase or decrease the
phone's volume. Newer devices send the volume to change to, based on the
known current volume. We therefore need to check whether the device
increased or decreased the volume based on the current volume ourselves
in order to determine which event we want to fire.
The Xiaomi Smart Band 8 Pro shows widgets in a two by three grid.
Previously, opening the widget configuration for such a device from the
device-specific preferences would crash Gadgetbridge because the layouts
in such a grid was not supported.
This commit adds definitions for layouts in a 2x3 grid to the
WidgetLayout enum, adds a definition for a full screen widget to the
WidgetType enum, defines rendering definitions for the new layouts to
WidgetScreenDetailsActivity, and defines translations for the new
layouts and type to XiaomiWidgetManager.
The Redmi Watch 4 reports both an unsupported widget type and layout
style:
- The firmware supports a screen layout for a single full screens
widget, which is defined by layout ID 128;
- A full screen widget is a single 2x2 part, which is not supported.
This commit adds support for both the new layout and the new widget
type.
Furthermore, this commit refactors the XiaomiWidgetManager. Previously,
the supported layouts were determined by the types of parts supported by
the device. However, the supported layouts are reported by the device
through a bitfield in the widget capabilities message of which the purpose
was unknown, which is now used to determine the supported layouts.
The new preference to toggle the auto-reply behavior is not
prefixed with the device name, as I guess it could be useful
also for other bluetooth headphones
This adds a new dashboard-type view to Gadgetbridge. The new dashboard activity displays several widgets with aggregated statistics from multiple devices. New preferences are added to allow configuration of the dashboard and its widgets. A new bottom navigation bar is added to switch between the Dashboard and Devices views.
Some issues that prompted this feature and provided inspiration for the implementation:
- https://codeberg.org/Freeyourgadget/Gadgetbridge/issues/301 (More Intuitive User Interface)
- https://codeberg.org/Freeyourgadget/Gadgetbridge/issues/3074 (Ability to merge historical data from several devices)
Reviewed-on: https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/3478
Reviewed-by: José Rebelo <joserebelo@noreply.codeberg.org>
Co-authored-by: Arjan Schrijver <a_gadgetbridge@anymore.nl>
Co-committed-by: Arjan Schrijver <a_gadgetbridge@anymore.nl>
As noted in #3676, having a lot of bluetooth classic devices might make
the connection take some time, which would only send all the updates at
the end.
Send the updates right away for each device.
* this match stock application Huawei Health
* devices show proper applications icons if it exist in firmware,
when type set to Wechat only wechat icon used
* sender name was not shown with wechat type
Introduce the concept of primary and secondary weathers:
* Primary weather keeps the same behavior as previously across all weather providers, so it's non-breaking. This location is not necessarily the current location, just the primary weather location set by the user.
* The GenericWeatherReceiver now has a new extra WeatherSecondaryJson, that receives a json list with secondary weather locations.
It's guaranteed that the primary weather always exists, so the list of WeatherSpecs provided to devices is never empty. Update all support classes accordingly.
NotificationListener now stores the handle ID in wearableAction.handle rather than hard-coding the calculation
Should fix ZeppOS too which was copy&paste from Bangle.js
This patch adds support for current weather, and next 6 days' weather. Condition mapping added to align with the available icons on the watch.
It also transmits the hourly condition and temperature for the coming 24 hours as part of the update.
Tested on CMF Nothing Watch Pro firmware 11.0.0.50 with weather data cooming from Breezy Weather (using Accuweather)
For current day:
- Weather symbol shows
- Name of current location shows (long names scroll)
- Current temperature shows
- Written condition shows (e.g. "Cloudy")
- Min/max temperatures show
- Air quality indicator shows
For upcoming days:
- Weather symbol shows
- Min/max temperatures show
- Name of day shows (patch doesn't touch this)
Nothing CMF Watch Pro: Use putShort() for air quality indicator; fix max location length
- Using putShort() as suggested from code review - tested to give same result
- Reduced max location length to 16 bytes, as 32 was not working
Nothing CMF Watch Pro: Better handle limited data from weather providers
- Check max length of daily and hourly datasets
- Populate with dummy data if insufficient data available
- Use null as the weather condition in any situation where no data available
Nothing CMF Watch Pro: If hourly weather data is missing, use current data
This should create a better fallback behaviour if a weather source is lacking hour-by-hour data.
Assuming the current data will apply in the next hour is less messy than showing placeholder (inaccurate) figures.
Nothing CMF Watch Pro: Allow location names of up to 30 characters, improve string processing
A lof of devices will simply work anyway even if already paired in
Android bluetooth settings. Discover them by default, but warn the user
if the device is not known to pair correctly if already paired in Android
settings. Allows this warning to be disabled to known working devices.
Bangle.js:file handling LOG.warn -> info
Bangle.js: sync file can't escape device directory
Naïve solution. I wanted to use `Path.normalize()` but Android Studio
said it could not be used from the static context. This does not attempt
to normalize the path, but just remove the special names `..\` and `.\`.
Bangle.js:simpler hindering of escaping device dir
These two values were swapped, meaning a double press of play/pause was needed to change state.
This also fixes the wrong play/pause button state showing during playback.
Tested on firmware 11.0.0.50
... might not be necessary. Since I got the fetching to work with
intervals on the the Bangle.js side it's been stable.
Didn't manage to make packet counting work yet.
Bangle.js: WIP add supportsActivityTracks
Bangle.js: testing flow of info
Bangle.js:WIP receive and store csv from Bangle.js
Bangle.js:store and transmit ID of last synced log
bangle.js:activity tracks, act on completed fetch
... of the recorder csv file.
Bangle.js: Activity tracks, now in database
... but not all data is persisted correctly I think. It's presented as
'Unknown activity'.
Bangle.js:Activity tracks, try to add gps info
I haven't tested with recordings where I have gps values, so far only
empty values. With empty values I currently get "This activity does not
contain GPX tracks" when trying to use the GPXExporter.
Bangle.js: Activity tracks, now adds GPS points
... to the activity to be shown when on the "Sport Activity Detail"
screen.
This should improve activity parsing across all devices, as we now take
the header into account, which indicates what groups are actually
present.
Thanks to @opcode for figuring out the header structure and providing
the ImHex patterns for the activity data.
Activity data fetching on Huami devices was filled with duplicated code,
and the handleActivityFetchFinish was called from multiple places where
it did not make sense. This made us signal to the band that activity
fetch was finished when it sometimes was not, causing some race
condititions that would make activity fetch fail or get stuck.
This refactor defines a clear "processBufferedData" that is called
upstream, signaling to the fetch operation that we have received all
data and the buffer can be processed. All handling of metadata and ack
messages is also delegated to the upstream class.
Wake lock with around 10 second timeout is a quick and dirty solution,
however as the time sync should happen once per several days the 10
second wake time should not be an issue.
Ensure TimeChangeReceiver alarm is scheduled when enabling
datetime_synconconnect and registering TimeChangeReceiver broadcast
receiver.
It is important to re-schedule the alarm after registering broadcast
receiver, because:
1. if broadcast receiver was unregistered while previous alarm arrived,
there is no alarm scheduled;
2. re-scheduling the alarm resets the periodic time sync timer when
first device is connected (which is desired).
It is important to re-schedule the alarm when datetime_synconconnect
gets enabled, because there might be no alarm scheduled.
Call onSetTime() when enabling datetime_synconconnect.
Sync time every 43 hours, 53 minutes and 23 seconds.
Interval is a bit smaller than 2 days.
Interval is a prime (in seconds) so time of sync will slide over time.
If next DST change is less than 48 hours in future, wait for it.
