The root cause of this problem is that starting from firmware 1.0.6.27 the
bluetooth name was changed to "Amazfit Cor" from "Amazfit Band"
This resulted in advanced features not working, including firmware flashing.
Based on the profile version which is 0x2000700 for both the bug reporter on a Mi Band 1 and for me on a Mi Band 1s
this either expects packets with length 20 (old firmwares) or 16 for HR enabled bands and 18 for non-HR enabled bands (new firmwares)
We check for profile version >=0x02000000 which is guessed, that needs confirmation for older firmwares and untested ones
Fixes#915
TODO:
- also reconstruct json for Pebble background js fake replies
- find a better location for settings
- interatively display candidates when looking up location
- grey out setting on non-cm/los devices
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
When receive SMS message, instead of generating multiple notifications
by PDU size, after this change, there will be only one notification for
each sender.
This is a regression since Gadgetbridge 0.22.0
Potentially fixes the following:
- #868
- #876
- #884
NOTE:
Java has no unisgned, java has no unsigned, java has no unsigned.
Java has no unisgned, java has no unsigned, java has no unsigned.
Java has no unisgned, java has no unsigned, java has no unsigned.
It seems WeChat always mark its notifications as LocalOnly. The reason
may be to avoid double notifications when using Android Wear watches,
since WeChat has a standalone Android Wear app.
Do not ignore WeChat notifications even if they're marked as LocalOnly.
Details: when we ask to fetch activity samples from date:time:tz+dst, the band,
under certain conditions, will send us back date:time:tz (without the dst offset)
We're fine with that, so we start fetching. When it's done, we take the last sample's
timestamp (still without dst offset), convert it to a unix timestamp, create a Calendar
using current tz and apply the unix timestamp. Then we send that timestamp again to the
band in order to fetch activity samples from then, but we again add the dst offset to the tz,
so send as date:time:tz+dst without changing the timestamp. That way, we may end up at the
timestamp we began with, fetching the same activity data again and not progressing.
We first need to thorougly understand how the devices behave, before we can reenable and fix
this.
(there are other places where something like this has to be done, probably also in the other direction)
related to #869
(cherry picked from commit a58e3f66ce)
