Alarmio icon indicating copy to clipboard operation
Alarmio copied to clipboard

Background Notification Options

Open fennifith opened this issue 6 years ago • 5 comments

Android 10 and above has different behavior for launching activities when the app is in the background; as covered in great detail in issue #100, the current SYSTEM_ALERT_WINDOW permission is only a workaround for what the system expects apps like this to do. According to the android docs, an alternate behavior for urgent notifications is to create a time-sensitive notification that will show in fullscreen when the phone is off, but not interrupt any ongoing activities on the device (if the user happens to be very involved in a game of Candy Crush, I guess).

To be honest, I don't like this behavior, and as a user I want Alarmio to be able to launch its own activities; interrupting an existing task on the device should be an obvious result of setting an alarm. However, I suppose the Android gods have spoken and decided to limit the functionality that apps can have - providing an option for the user to choose between this and the SYSTEM_ALERT_WINDOW hack is probably the best we can do.

I'm not sure what consequences this has for Alarmio's ringtone/vibration settings; proposed solutions involve creating the notification from a foreground service - the Android docs specify that interacting with a notification will launch the associated activity, but it isn't clear whether this notification also makes a sound/vibration or not. It's possible that the behavior for playing sound files / internet radios / etc will need to be moved into a Service along with the notification; this could then be bound to the AlarmActivity when/if it is launched.

Something that I'm more wary of is the amount of steps that an alarm needs to go through in order to be noticed by a user, between the app being started by AlarmManager and the activity actually launching. Currently, that number is one - a BroadcastReceiver is started, then AlarmActivity opens. This changes that; the BroadcastReceiver needs to start a service, which needs to send a notification, which then might open AlarmActivity if it's having a good day.

Regardless, this is a pretty low priority for me; I think most of our users have older Android versions that will not be affected by this (myself included), and there isn't any imminent breakage due to the SYSTEM_ALERT_WINDOW permission being added as a workaround. Android Go devices don't have this permission, so we may start seeing issues from these users, but I have yet to actually find anyone who has one.

fennifith avatar Mar 31 '20 23:03 fennifith

I am on Android 10 (H8324 52.1.A.0.618). When testing on commit c31de6e1b60da8c02bfc66108a8408996437302c, I can reliably reproduce the alarm not triggering, showing the log line:

W ActivityTaskManager: Background activity start [callingPackage: me.jfenn.alarmio; callingUid: 10261; isCallingUidForeground: false; isCallingUidPersistentSystemProcess: false; realCallingUid: 10261; isRealCallingUidForeground: false; isRealCallingUidPersistentSystemProcess: false; originatingPendingIntent: null; isBgStartWhitelisted: false; intent: Intent { flg=0x10000000 cmp=me.jfenn.alarmio/.activities.AlarmActivity (has extras) }; callerApp: ProcessRecord{49d5ba9 5229:me.jfenn.alarmio/u0a261}]

Nonetheless, each morning my alarm wakes up my phone (and me) just fine.

I have a nagging feeling it might be related to #89 , but haven't tested rolling that back yet. I haven't tested adding the SYSTEM_ALERT_WINDOW permission as a workaround yet, either. I'm adding it to my TODO list, but not I'm sure when I'll get to it ;)

raboof avatar Apr 01 '20 07:04 raboof

@raboof In all testing so far, adding SYSTEM_ALERT_WINDOW does in fact fix this; I doubt anything related to #89 has gone wrong here - though I would greatly appreciate some more confirmation of that :)

Testing after c65aa0f (in an emulator) everything I'm throwing at it seems to be working fine, but it'd be nice knowing that this fixes the problem on an actual physical device.

fennifith avatar Apr 01 '20 15:04 fennifith

I doubt anything related to #89 has gone wrong here

I will reluctantly stop feeling guilty ;)

though I would greatly appreciate some more confirmation of that :)

Will try to make some time soon - but please don't wait for me :)

raboof avatar Apr 01 '20 15:04 raboof

The issue occurs only when the app is removed from recent apps. and the SYSTEM_ALERT_WINDOW is not given.

ajayyy avatar Apr 01 '20 20:04 ajayyy

I would greatly appreciate some more confirmation of that

I gave it a try and I can't get it to fail on 0632a3e93f6b1ce436922f07dfb4a4bbe43c9d11 (but not on c31de6e1b60da8c02bfc66108a8408996437302c either), even when removing it from the recent apps. I haven't explicitly granted or revoked SYSTEM_ALERT_WINDOW, but since I'm installing with ./gradlew installOssDebug I suspect this permission is enabled.

raboof avatar Apr 01 '20 20:04 raboof