This also improves firmware/RES probing to distinguish Mi Band 2/3 firmware files and Mi Band 3/Bip RES files.
Notes:
- Firmware flashing should might but is untested
- This basicall runs off the Amazfit Bip code which will probably incorrect (Mi Band 3 is proabably something between the Bip and the Mi Band 2)
Wind information are stored and put in the reconstructed OWM response.
A long standing bug (having the "name" field inside "main" instead of at
the root level of the json) has been fixed
Lineage OS receiver and if possible weather notification app receiver will
be added in further commits.
See #482
This removes misuse of testNewFunctionality() and support fetching GPS data and debug logs
Fetching debug logs (Amazfit Bip/Cor) is now accessible in the debug activity
Fetching GPS data can be done by swiping in the list activity.
TODO: actually refresh list when fetching data is done :P
Also fix some android studio warnings on the go...
No longer save an instance of ParcelableWeather2, rely on our WeatherSpec instead which now has all forecast data and save reconstructed owm weather json in Weather
Pebble: Add support for dynamic Pebble background colors
- Add a couple additional icon types
- Add Lighthouse (currently unused)
- Add Transit (public transportation app)
- Tweak the colors on existing icon types
- Implement logic to grab primary (vibrant) color from app logo
- The color will be used when displaying a notification for an app
that does not have any configs bound to it.
- Alter NotificationType to support a color (named pebbleColor)
- Alter the Pebble notification poster to listen to the color from
the notification
- Alter the DeviceCommunicationService to allow for color passthrough.
- Add logic to convert HEX or Integer representations of RGB888 colors
to Pebble RGB222 format.
- make the package name retrieved lowercase.
Fixes: #815
- Add a large number of notification icons missing from current version
- Update colors for existing icons to match Pebble colors exactly
- Add hooks for new icons
Linked issue: N/A
Scan and connection, battery level, firmware version, date and time sync
(along with some other currently hardcoded settings), notification
support, alarm support, and some more.
As requested in #736, this adds an entry in the settings menu that allows to blacklist certain calendars.
To avoid confusion, all the former blacklist methods and fields have been renamed to apps_blacklist. The new entries are called calendars_blacklist.
Importing the settings has not been tested with the current changes.
Closes#736
Future improvements TODO: The new setting lives in the Pebble section, i believe in the future the blackslist functionality should be centralized and put in the sidebar.
Support is almost on Mi Band 2 level.
What does not work yet:
- flashing firmware files
- taking or rejecting phone calls
- syncing GPS tracks
- sending weather
- notification only include title, not a body
- unknown notification's text is not forwarded to the watch at all (same on Mi Band 2 #754)
Add actions to the filter (this should help with #536)
Add "copy" constructors to MusicSpec and MusicStateSpec, and use those when receiving an updated intent, this way partial updates do not disrupt the local information.
Iterate over incoming extra keys, explicitly check the incoming type and use only known type. This could help with #533
Possible problem: this code iterates over every key of the incoming bundle.
- cleaned up the DeviceService.connect() variants
- discovery: pass the device candidate around instead of the mac address
Attempts to fix#512, #514, #518
Most of the code is generic, so it could be implemented by other devices.
I dont know what happens if multiple messages arrive in the same notification.
So, this is experimental.
- enable/disable weather app from the watchapp list
- convert weather data to a format that can be displayed by the system app
TODO: send the weather data periodically
Don't take this serious. It will make the "massage device" vibrate when a phone call arrives.
It is inspired by the famous lawsuit[1] which has nothing to do with the Vibratissimo device maker.
After reading this I picked up the cheapest ble massage device just to see if we could support it.
And yes, we can.
[1] http://arstechnica.com/wp-content/uploads/2016/09/vibratorsuit.pdf
Use KitKat (19) as target sdk since robolectric 3.1.2/sqlite4java
does not understand "WITHOUT ROWID" tables.
Also, add constants for user's gender and document some things.
- Also send duration if "duration" extra is present
- If "playing" and "postion" extras are present send a music state update
treat previous state and current state as equal if position delta is <=2 seconds
(Neccessary for some players which update every second - the pebble however counts by itself)
This commit contains the infrastructure needed for the
NotificationHandler to send music state information to the device. That
is, it introduces a call onSetMusicState(MusicStateSpec stateSpec), that
in turn sets up an intent to the service, which will then call the
encodeSetMusicState() function of the device. encodeSetMusicState is
available for pebble only. There are empty stubs for other devices.
- for now, use a custom version of greendao with the fix 39ac07be550c5f5b6fd265c8870f58015c95e908
- use a superclass for activity sample classes that provides value normalization using SampleProvider
- dynamically toggle hr sleep support when preference changes
- check hr support dynaically after device info is available to avoid false error message
This avoids a lot of problems because java
- does not know unsigned values
- jvm and dalvic do not internally support byte and short
- sqlite does not know them either
Currently we get the heart rate when synchronizing activity data
(i.e. not live) and we write it to the activity database so that we
can show a nice graph. The value is currently always 0 though,
because we can't enable recording hr, yet.
Created a new device-independent class ActivityUser to hold the data
Moved the constants from the miband constant class to the ActivityUser class
Removed the miband-specific in favor of common-prefixed preferences (with upgrade support for legacy values)
Changed the way the gender is stored to an integer value
Removed the hardcoded default values for user data in favor of static fields of the ActivityUser class
Add weather info for TimeStylePebble.
Add further fields to the ParcelableWeather class.
Add reverse mapping to ParcelableWeather to get back the original OpenWeatherMap API condition codes.
- Implement the PebbleProtocol side (2.x and 3.x)
- Add Preferences for canned replies
This can be tested by enabling untested features in Pebble Settings
It lets you see and select the replies set up in "Canned Repies" on the Pebble
You will get a "NOT IMPLENTED" message on your Pebble.
THIS DOES NOT ACTUALLY DO ANYTHING USEFUL YET.
- created and provided by DeviceHelper
- passed from UI to service
- without UI, service uses DeviceHelper directly
=> Cleaner and less duplicated code
The notfification APIs now use NotificationSpec as their only parameter, which
contains all information (required and optional ones).
We no longer have separate methods and actions for SMS/EMAIL/GENERIC anymore.
The type of notification is important now, not how we received them technically.
Previously, the DeviceCommunicationService was invoked directly,
via
Intent intent = new Intent(foo, bar);
intent.setExtra(EXTRA_BAZ, baz);
startService(...);
and this was scattered throughout GadgetBridge.
Now there is a "frontend" available, so that you can call
the service more easily, like
GBApplication.deviceService().connect();
For a start, this client interface (DeviceService) actually
implements the same interface (EventHandler) as the receiving side
(DeviceSupport). This may change in the future.
This will also make testing much easier, because we can use
this client interface to invoke the test service as well.
- model package contains mostly shared interfaces (UI+service), not named GB*
- impl package contains implementations of those interfaces, named GB*
the impl classes should not be used by the service (not completely done)
- the service classes should mostly use classes inside the service and deviceevents
packages (tbd)
Every device now has two packages:
- devices/[device name] for UI related functionality
- service[device name] for lowlevel communication