durka/HallMonitor

display notifications on lockscreen

Closed this issue · 9 comments

display notifications on lockscreen

Writing an accessibility service looks like a pain, and error-prone since you have to keep track of notifications as they come in. Let's take the plunge and require 10.2/4.3 for the NoticationListenerService features.

Agreed! Makes it much easier.

Note that you have to enable the notification listener, outside the app, by going to Settings -> Security -> Notifications. Not sure if this can be automated or not. But the notification listener seems to be receiving events (new "notifications" branch).

Turns out you can automate it, a little bit -- about as much as you can with granting device admin permissions. Phew, this app is a pain to install the first time (and every time, for us developers): device admin, root, notifications.

Anyway, it works. Every time DefaultActivity comes up, it grabs all the active notifications and stuffs their icons in a GridView.

It needs a little cleaning up. It does update if the icons change while DefaultActivity is not visible (screen off or phone unlocked) but not if it is visible. This can be fixed using the onNotification(Posted|Removed) methods in the service. Also, it doesn't show the number of emails or texts or whatever that are pending, but that might be just fine anyway.

Also, are you getting a new behavior where when you install the app, the pref_enable box is checked, but it's not really true, and you have to disable/enable it twice before it really "takes"? Before, every time I installed the app it would disable itself, and I would only have to click the checkbox (and grant device admin) once.

OK, cool - yep, we do seem to need a huge load of permissions to make this work! I'll have a look but sounds really good.

Interesting about the pref_enabled thing - that was behaviour I got sometimes after relaunching the app so I did so some tweaking around that bit, but for me it was now working fine. I'll have a look...

...OK, I've just hard reset back to Master so I can start clean again (well I say that, but eGit didn't seem to want to play ball so in the end I just deleted the project and started again from the master branch!), and I don't get that problem with the pref enabled. If I uninstall and then install clean it comes up unchecked. I do notice though that if I redeploy whilst the app is running it comes up as checked - that however does seem to be because the service is actually still running. Are you seeing something different? (i.e. do we need to investigate further?)

I did however have one minor issue on the master branch, which was that it didn't like the buttonBarStyle and buttonBarButtonStyle entries in values/styles.xml and values-v11/styles.xml. Not sure what they are used for, but everything worked fine when I just commented them out.

Huh, so, for me almost every time when I redeploy -- if I've made modifications -- it comes up checked, but the service isn't running (or it doesn't work, if it is). And it doesn't come back on the first time I uncheck/check the box, either. You can tell because the device-admin-status toasts don't happen. I have to cycle it twice before I get prompted to approve the device admin, and then it starts working.

OK, so sounds like it's just an issue when redeploying. I always either stop the service, or completely uninstall before I redeploy which is probably why I don't see the issue. Looking at it, I'm guessing it's an admin privileges issue. Maybe on a redeploy it preserves the service state (i.e. the service continues to run), but you lose admin privilege (so nothing happens when you close the cover). Could add an extra check in ConfigurationFragment.onResume to check for admin privilege and make sure that the check box is unchecked if we don't have it.

I'm a bit busy today but I might get a chance to have a look at that later.

PS Been running with the latest build on the mediacontrols branch all weekend and it's been working perfectly :0)

Hmm... OK, tried doing the admin check, but it made no difference - it still comes up with everything checked on a redeploy, and I'm not really sure why. It's a bit annoying, but so long as you uninstall before redeploying it all works fine, so that might just be the best bet.

I'm gonna have a look at what's possible for the alarm bit next.