asteroid
asteroid copied to clipboard
[bass] Vibration Stops Working
Describe the bug After flashing the watch, the vibration works fine, but for no more than 24 hours. After this, all vibration ceases, regardless of method.
To reproduce Steps to reproduce the behavior:
- Flash [bass] with AsteroidOS image, and pair to phone.
- Use watch normally for a day or so.
- Experience total absence of vibrations.
Expected behavior Vibrations continue to work when notifications arrive.
Screenshots Inherently unable to screenshot.
Device (please complete the following information):
- Watch Codename: bass
- AsteroidOS Builddate 20240314232113
- Version [1.1 nightly]
Additional context Loss of vibration does not appear to have any correlation with a lack of communication with the phone.
Vibration does not return after a reboot of the watch.
Vibration does not return after putting the watch into bootloader mode and then continuing.
Once vibration is lost, it does not happen if any debug / test commands are sent from Gadgetbridge.
Once vibration is lost, it does not happen if I use AsteroidOS Sync instead.
Once vibration is lost, it does not happen if I toggle the vibration option in Quick Settings on the watch.
Vibration sometimes happens if I send a 'find my watch' command from Gadgetbridge, but in some cases, it does not happen even then. The loss in the event of a 'find' command seems to loosely correlate with longer uptimes, but not always.
Vibration does return if I re-flash the watch, but only for the same short time.
This issue appeared to happen over the last few nightlies; I've only been using AOS since early March, for context.
I just wanted to highlight this one piece of information, as verified in our Matrix chat:
Once vibration is lost, it does not happen if I toggle the vibration option in Quick Settings on the watch.
In other words, once it stops working, turning vibration on via Quick Settings (which should normally cause the watch to vibrate) does not make the watch vibrate.
Unfortunately I don't have a bass
and so I can't do much to work on this. It doesn't seem to affect other watches.
I'm also suffering the same issue, but in my case rebooting the watch does bring vibration back. I've noticed that the problem seems to happen at some point when reconnecting to my phone while it's on vibration mode, although I suppose it could be coincidence. I have been able to keep vibration on for a few days, provided that I maintain phone and watch synced at all times, don't lose bluetooth connectivity and never send my phone into vibration mode.
I have my bass paired with a OnePlus 8T (kebab) running LineageOS+microG 21 (21-20240319-microG-kebab). Watch itself is on AsteroidOS 1.1-nightly 20240321233039.
Edit: So vibration stopped exactly 24 hours later despite not losing connection or any of the other things I mentioned. Not sure how I got it to run for about 3 days without vibration disabling itself. That said, I can always get vibration back by rebooting.
New owner here, my experience more or less matches @putridpete's.
Fresh flash from fully updated stock WearOS, paired with a Google Pixel 5 running latest stock OS.
I began working my way backwards through the archives, and I've been going three days with vibration still working on 1.1-nightly 20240216002300
Great, I've just flashed the same version and will test to see if I also keep vibration going. Much appreciated.
Edit: Unfortunately, twice in a row I have lost vibration after around 24 hours even in the aforementioned previous release. One thing I've noticed is that I tend to lose vibration even earlier if I lose connection repeatedly while using the AsteroidOS Sync app, by say... walking too far away several times.
Yes, I noticed this too, my joy was premature.
One thing I've noticed is that I tend to lose vibration even earlier if I lose connection repeatedly while using the AsteroidOS Sync app, by say... walking too far away several times.
That may well track, I've noticed that even when keeping phone close-ish bluetooth connectivity drops quite frequently (bet its the power saving on my phone). I'm going to try swtiching to Gadgetbridge and see if it happens still.
@putridpete I think I have steps to reproduce, using a fresh nightly flash. No phone connection or bluetooth required.
- Flash latest nightly (using asteroid-hosttools)
- Speedrun the tutorial (any way to turn that off?)
- Set an alarm for +1 minute, vibration works
- Snooze alarm
- When snoozed alarm goes off, vibration works
- Snooze alarm again, vibration breaks till reboot. Bonus bug: The snoozed alarm doesn't fire until after the reboot.
Checking the Alarm code, it looks like 6 months ago there was a commit that changed alarmDialog.snooze()
in the snooze handling to alarmDialog.close()
, but doesn't do an alarmDialog.dismiss()
the way that the other dismiss functions do.
I don't think this is the root cause, because I had this happen without using the alarms, but I'm betting it gets us closer.
In answer to your question (turning off the tutorial), yes, you can hold down the on-screen button to bypass it. Thanks for your work in reproducing this! It's a tremendous help.
I can confirm that I am able to reproduce this error before and after reflashing the latest nightly. Furthermore, I've noticed that if I set an alarm to go off in 1 minute and hit the confirm button to dismiss the alarm I lose vibration right away every single time until a reboot.
I flashed the oldest archive I could, 2023-08-23, which also reproduces the 'confirm button to dismiss breakage'.
Edit: Found the old 1.0 release, and this does not reproduce the error.
@putridpete I think I have steps to reproduce, using a fresh nightly flash. No phone connection or bluetooth required.
- Flash latest nightly (using asteroid-hosttools)
- Speedrun the tutorial (any way to turn that off?)
- Set an alarm for +1 minute, vibration works
- Snooze alarm
- When snoozed alarm goes off, vibration works
- Snooze alarm again, vibration breaks till reboot. Bonus bug: The snoozed alarm doesn't fire until after the reboot.
Checking the Alarm code, it looks like 6 months ago there was a commit that changed
alarmDialog.snooze()
in the snooze handling toalarmDialog.close()
, but doesn't do analarmDialog.dismiss()
the way that the other dismiss functions do.I don't think this is the root cause, because I had this happen without using the alarms, but I'm betting it gets us closer.
Great work on finding this!
Did you also try with Alway-on-Display disabled? That uses some of the alarm mechanics as well (it doesn't use any snoozing logic, but it may also be a potential cause).
Just tried this on catfish
and it definitely works as expected there, so it does seem to be specific to bass
. I'm not sure that adds much value, but it's an observation.
@MagneFire I already had Always-on-Display disabled when I tried to reproduce jason-kurzik's method, but I get the same result with it on or off; let's see if it's the same case for him.
Confirmed, I almost always turn Always-on off. I have not seen a difference in behavior either way.