2 ms·

> I consider giving apps the ability to draw overlays without any kind of permission in a supposedly sandboxed environment a design flaw, for example. FWIW, Ge

> I consider giving apps the ability to draw overlays without any kind of permission in a supposedly sandboxed environment a design flaw, for example. FWIW, Gentle Alarm doesn’t do that :D It’s not quite clear why giving the permission helps, but without it, the alarm doesn’t go off when the screen is off (it still does if the screen is on and the app in the background).

jeroenhd 4y ago
I think it does, but not in the way you expect it. For the longest time this API was the only reliable way to get anything onto the lock screen of some Android phones. If it didn't use this API, you would need to unlock your phone before you could get to the snooze/dismiss buttons. I can easily see the dev calling into the API to initialise the alarm dialogue before actually playing the sound (after all, who wants an alarm they can't turn off?) and the API call that used to go through without issue now throwing an exception, killing the wakeup process dead in its tracks. I haven't reversed the APK, or course, but it's a very likely scenario. I don't think this is how the API is intended to be used, but you can find plenty of stackoverflow answers like https://stackoverflow.com/questions/35327328/android-overlay-textview-on-lockscreen https://stackoverflow.com/questions/35327328/android-overlay... that (ab)use the window API. This one: https://stackoverflow.com/questions/46860993/window-over-other-apps-lock-screen-only-with-user-permission-in-api26 https://stackoverflow.com/questions/46860993/window-over-oth... shows the API change, throwing exceptions on API level 26 (Android 8) that didn't get thrown before. On modern devices, these old workarounds are usually no longer necessary. There's a separate API which is easier to use for interacting with the lock screen now and the permissions to take over the lock screen have been made harsher. For a maintained app this would mean fewer compatibility hacks, less weird lingering visual artifacts in edge cases and a better alarm. Sadly, with the dev ending their operation, the alarm is probably stuck calling old APIs with limited support now that Android security is tightening. Such a change broke clipboard sync in KDE Connect, for example, except it didn't leave a compatibility workaround for old apps. I'm in favour of better privacy and security but restricting previously unrestricted APIs is a painful process. I've gone so far as to root my phone to provide the necessary permissions but I don't think I'll be able to do that forever...
- Semaphor 4y ago
  Oh, that explanation makes perfect sense, thank you for the background information :)

jeroenhd 4y ago

I think it does, but not in the way you expect it. For the longest time this API was the only reliable way to get anything onto the lock screen of some Android phones. If it didn't use this API, you would need to unlock your phone before you could get to the snooze/dismiss buttons. I can easily see the dev calling into the API to initialise the alarm dialogue before actually playing the sound (after all, who wants an alarm they can't turn off?) and the API call that used to go through without issue now throwing an exception, killing the wakeup process dead in its tracks. I haven't reversed the APK, or course, but it's a very likely scenario. I don't think this is how the API is intended to be used, but you can find plenty of stackoverflow answers like https://stackoverflow.com/questions/35327328/android-overlay-textview-on-lockscreen https://stackoverflow.com/questions/35327328/android-overlay... that (ab)use the window API. This one: https://stackoverflow.com/questions/46860993/window-over-other-apps-lock-screen-only-with-user-permission-in-api26 https://stackoverflow.com/questions/46860993/window-over-oth... shows the API change, throwing exceptions on API level 26 (Android 8) that didn't get thrown before. On modern devices, these old workarounds are usually no longer necessary. There's a separate API which is easier to use for interacting with the lock screen now and the permissions to take over the lock screen have been made harsher. For a maintained app this would mean fewer compatibility hacks, less weird lingering visual artifacts in edge cases and a better alarm. Sadly, with the dev ending their operation, the alarm is probably stuck calling old APIs with limited support now that Android security is tightening. Such a change broke clipboard sync in KDE Connect, for example, except it didn't leave a compatibility workaround for old apps. I'm in favour of better privacy and security but restricting previously unrestricted APIs is a painful process. I've gone so far as to root my phone to provide the necessary permissions but I don't think I'll be able to do that forever...

Semaphor 4y ago
Oh, that explanation makes perfect sense, thank you for the background information :)