Open barbeau opened 8 years ago
I asked the user if they had this issue in v1.x of OBA, and this was their response:
My bat [best] guess is that it has something to do with marshmallow notification enhancements, I think I had the issue oj [in] the prior version of one bus away
So sounds like this might not be an issue specific to the v2.0 update.
IIRC following the fix for https://github.com/OneBusAway/onebusaway-android/issues/290 @cagryInside and I both tested notifications, and we both were able to get them to fire after a phone restart - so everything still seemed to work fine.
@cagryInside If you have Android 6.0.1 on your Nexus, could you please see if you can reproduce this?
@cagryInside If you have Android 6.0.1 on your Nexus, could you please see if you can reproduce this?
@barbeau I have 6.0.1 on my Nexus 6. I could not reproduce this problem. After restarting my phone, I was able to see the notification without opening the app.
I'm guessing this might be a case of https://github.com/OneBusAway/onebusaway-android/issues/333, where the agency had a data change that invalidated the trip_ids for this users reminders.
User says this seems different from #333, which he's encountered before. He said he does have a PIN on his device, and Good installed. Not sure yet if this is related.
I tried testing reminders in Tampa, and it seems that some duplicate trip_ids are showing up – I saw this specifically for UATC (Stop #6497) and Route 18 in Tampa - OBA Android actually alerted me twice for one reminder: http://tampa.onebusaway.org/where/standard/stop.action?id=Hillsborough+Area+Regional+Transit_6497&route=Hillsborough+Area+Regional+Transit_18
I pasted a sample response here: https://gist.github.com/barbeau/e7fc9c6802561b48aa2b82230faa9b36
You can see that trip_id “Hillsborough Area Regional Transit_152338” shows up twice in the response, for element 0 and 1.
I assume this would this affect Puget Sound too. I’m wondering if in this user's case his reminders are set for trip_ids that aren’t showing up in the feed (maybe being replaced by a duplicate?).
This could be a similar issue to #562 - we accidentally broken stop shortcuts on at least some devices due to the refactoring Activities from the com.joulespersecond.seattlebusbot
package to the org.onebusaway.android.ui
package, and the Intents stored with the shortcuts couldn't find the old activities in the old package.
The TADService
and AlarmReceiver
were also refactored like this - it's possible we need to include a dummy com.joulespersecond.seattlebusbot.AlarmReceiver
in the old package that would redirect all events to the new TADService
.
We'd also need to include the old (Edit - thinking more, this shouldn't be needed - this Intent is generated by the Android platform)com.joulespersecond.seattlebusbot.BootstrapService
to handle boot events as well.
Here are the old v1.7.9 manifest entries:
<permission
android:name="com.joulespersecond.seattlebusbot.permission.TRIP_SERVICE"
android:label="@string/trip_service_perm_label"
android:description="@string/trip_service_perm_description"
android:protectionLevel="normal" />
<application...>
<service
android:name=".TripService"
android:permission="com.joulespersecond.seattlebusbot.permission.TRIP_SERVICE">
<intent-filter>
<action android:name="com.joulespersecond.seattlebusbot.AlarmReceiver" />
<action android:name="com.joulespersecond.seattlebusbot.BootstrapService" />
</intent-filter>
</service>
<receiver android:name=".AlarmReceiver">
<intent-filter>
<!-- Should match constants for actions defined in TripService -->
<action android:name="com.joulespersecond.seattlebusbot.action.SCHEDULE" />
<action android:name="com.joulespersecond.seattlebusbot.action.POLL" />
</intent-filter>
</receiver>
<receiver android:name=".BootstrapService">
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
<action android:name="android.intent.action.TIMEZONE_CHANGED" />
</intent-filter>
</receiver>
</application>
Looks like the refactor is the cause - I'm able to reproduce by installing v1.7.9
, setting a reminder, and the installing master
branch. Reminder only triggers after OBA app v2.0.13
(master
branch) is started. I didn't have to restart my phone to reproduce it.
I'm re-opening, as I've gotten a few similar feedback messages from users recently:
App Version: 2.1.1 Model: LGLS675 OS Version: 5.1.1 / 22 Google Play Services App: 9.4.52 (234-127739847) Google Play Services Library: 9080000 Region/API: Tampa Bay (selected automatically) Loc: gps , 0 second(s) ago
If I set reminder times it doesn't show up until well after the reminder time for example when I set it for 15 minute reminder it doesn't show up until the bus is 5 minutes away and that is no good at all
...and:
Reminders not working
App Version: 2.1.1 Model: SM-N920V OS Version: 6.0.1 / 23 Google Play Services App: 9.4.52 (440-127739847) Google Play Services Library: 9080000 Region/API: Puget Sound (selected automatically) Loc: gps, 1 second(s) ago
I got more information from the above Puget Sound user - this sounds like it could be intertwined with a data issue:
The reminders never work in the morning or night. Its been 2 weeks now. The bus times shown are wrong. Some are arriving early and some late. Its difficult to report time problems because the app removes the bus after it assumes its arrived. Right now im standing at the stop 75414 and 3 buses that have supposed to have arrived, never did
However, the user also says:
Even when the bus arrival shows on the app, it doesnt trigger the reminder...Its everyday 6.07am (PST) bus 372 and 3.26pm (PST) bus 372
Reported by another user:
App Version: 2.1.2 Model: XT1053 OS Version: 5.1 / 22 Google Play Services App: 9.4.52 (236-127739847) Google Play Services Library: 9080000 Region/API: Puget Sound (selected manually) Loc: network , 16 second(s) ago An arrival reminder (route 60, stop 21080) "stalled" (got stuck at 5mins when the bus was actually closer) and when I checked the route in the app again, the reminder was no longer attached to the route. Reminders getting stuck is a bug I have seen a lot.
I haven't heard any more reports of this, so I'm going to close this issue for now. It may be related to data changes (#333). I'll re-open if I get more reports.
Re-opening, reported by another user:
App Version: 2.1.9 Model: SM-N920P OS Version: 7.0 / 24 Google Play Services App: 11.0.55 (440-156917137) Google Play Services Library: 9452000 Region/API: Puget Sound (selected manually) Loc: gps 47.62228475,-122.32619085 7.585, 1 second(s) ago
The alarm feature seems problematic. I have our set daily for 10 min before my bus, and it will usually go off 9 min before, and often later (once recently 4 min before). It seems like it may be related to the phone screen being off - I often get the alarm right when I pick up my phone. Thank you.
Closing, as this sounds like it's an instance of the "pole problem", with delays jumping near the beginning of a trip after a layover:
This route at the time I take it doesn't seem to be late too often, but it's also close to the start of one end of the route, so maybe layover times is a factor
Re-opening, feedback from rider today:
It worked when I left it open and watched it go past the 10 minute mark, but then I set a 5 minute times and closed it. No notification. It was still in my reminders with three minutes to go. I just got on the bus as I was typing this. It definitely did not go off. Hope this helps. App Version: 2.1.9 Model: SM-J327T OS Version: 7.0 / 24 Google Play Services App: 11.3.02 (436-161239932) Google Play Services Library: 9452000 Region/API: San Diego (selected automatically)
Reported by another user:
Thanks for such a useful app! I've noticed that after the upgrade to Android 8.1 (maybe since 8.0 but I can't tell for sure) the reminders are affected by the phone going in doze mode, basically the notifications don't happen until I wake the phone up, that makes the notifications less usable as they come way after the time they were supposed to show up.
App Version: 2.2.5 Model: Nexus 5X OS Version: 8.1.0 / 27 Google Play Services App: 11.9.51 (440-177350961) Google Play Services Library: 9452000
This is likely related to the "Doze" mode: https://developer.android.com/training/monitoring-device-state/doze-standby.html
In the above document it says:
Doze is particularly likely to affect activities that AlarmManager alarms and timers manage, because alarms in Android 5.1 (API level 22) or lower do not fire when the system is in Doze.
To help with scheduling alarms, Android 6.0 (API level 23) introduces two new AlarmManager methods: setAndAllowWhileIdle() and setExactAndAllowWhileIdle(). With these methods, you can set alarms that will fire even if the device is in Doze.
Note: Neither setAndAllowWhileIdle() nor setExactAndAllowWhileIdle() can fire alarms more than once per 9 minutes, per app.
So, in TripService.pollTrip()
we should change alarm.set()
to alarm.setAndAllowWhileIdle()
.
Good explanation of Doze mode and behaviors on various API levels w/ diagram at: https://plus.google.com/+AndroidDevelopers/posts/GdNrQciPwqo
Re-opening - it looks like we should have used setExactAndAllowWhileIdle()
instead of setAndAllowWhileIdle()
.
AlarmManager.setExactAndAllowWhileIdle()
docs say:
If you don't need exact scheduling of the alarm but still need to execute while idle, consider using setAndAllowWhileIdle(int, long, PendingIntent).
We want exact scheduling, so we should have used setExactAndAllowWhileIdle()
in TripService.pollTrip()
.
Re-opening, I'm getting similar reports from users again. I'll post a few comments below:
App Version: 2.4.4 Model: LM-G820 OS Version: 9 / 28 Google Play Services App: 17.1.22 (100400-245988633) Google Play Services Library: 12451000 Region/API: Puget Sound (selected automatically) Loc: gps, 1 second(s) ago
The bus reminder needs a lot of work. I have it set for 10 minutes. Today it reminded me at 1 minute. It's rare that it actually gives me the 10 minutes I have it set for.
The reminders aren't working. They don't pop up as a notification unless you access the app. But even after doing that the reminders don't update. The reminders used to work fine, but just randomly one day it stopped working and it is still currently not working right.
App Version: 2.4.4 Model: SM-G965U OS Version: 9 / 28 Google Play Services App: 17.1.22 (100400-245988633) Google Play Services Library: 12451000 Region/API: Puget Sound (selected manually) Loc: gps, 0 second(s) ago
I believe this may be caused by Android prompting the user to optimize apps for battery usage, and then OneBusAway is stuck not being able to do anything in the background.
To test for this, users can manually whitelist the app as described here: https://developer.android.com/training/monitoring-device-state/doze-standby#support_for_other_use_cases
On a Samsung Galaxy S8+with Android 9 the above manual instructions don't quite match the UI, so here are instructions I sent a user to test:
In your Android system menu, could you please try going to "Apps->OneBusAway" and make sure "Allow background activity" is enabled, and then tap on "Optimize battery usage", change the option to "All" to show all apps, and then find OneBusAway in the list and make sure that the switch for OneBusAway is turned off?
Then please try reminders for a day or so to see if they start working again. If it still doesn't work, then try deleting and recreating your reminders and see if that helps.
The above list provides some options for intents we could fire when setting up reminders to explictly prompt the user to whitelist the app. We could also check isIgnoringBatteryOptimizations()
on app startup and if false and the user has saved reminders we could then prompt them to whitelist the app (because the user could always accidentally remove the app from whitelist after the reminder is set up).
Summary:
Reported by a user via email:
Steps to reproduce:
Unknown (I haven't tried to reproduce yet), but I'm assuming:
Expected behavior:
Reminder triggers based on when it was set
Observed behavior:
Reminder doesn't trigger
Device and Android version: