Is there a way to detect some general keyboard events made by other apps? I understand that the specific keyboard events(e.g. key "b" pressed) should not be exposed due to security reason. But are general events like keyboard show/hide broadcast in any way? I did some search but did not find it available.
Keyboard show/hide is not an event you can listen for, not even in your own app (there are some hacky workarounds within your app, but it seems like you want to do this externally). I don't believe keyboard events are broadcast in any way. They may be delivered to the current Activity window in focus (and to its Views), but I have seen nothing to suggest that they are broadcast across the system.
Related
I am searching for a way to implement a custom unlocking screen for Android. There seem to be lots of questions about that but no real way to do that, am I right?
Solutions I found are about creating an activity that is invoked by some mechanism, that have to disable or bypass the home key and other keys and so on.
The simplest way in my imagination should be giving android an activity and say hey if you lock the screen and the user wants to wake it up, call this and wait for it to respond if unlocking is ok or not.
Handling stays within the system, that activity does not have to receive any key events, the system does not respond to home key in this situation...
Is there a chance?
I'm trying to develop an app that, according to some pattern pressed on the keyboard (like swipe, but not that complex), it will do some action. For example, if the user presses two keys at once, it will do some action. This has to be a service, because my won't have a gui. It will just do the actions. I read that it's not possible, as it would create a security hole, so I'm open to suggestions on how I can tackle this problem. I've thought of this way:
1. Create an accessibility service and get the key events (easy for hard keyboard, but I don't know about the soft keyboard.)
Could you give me any other ideas, or help me on how to get soft key events in an accessibility service?
Thanks!
I'm having trouble making what I thought would be smaller app. Primary focus is having activity on top of incoming call screen, with custom controls which would give user custom control ability (blocking, selecting etc...). However after hours (days) of googling and search here on SO I have found quite a few non working examples.
I develop on Android 2.3.3 and would like to have that platform as minimal support but if moving to 4.x platform would take the pain away I would be able to switch.
I have tried many approaches but only one that seems to be working for now is to addView() to WindowManager with custom LayoutParams using TYPE_SYSTEM_OVERLAY or TYPE_SYSTEM_ERROR. Problem is not having any touch/key inputs as stated on this page.
I'm having BroadcastReceiver that is activated for PHONE_STATE broadcast, and on receiving broadcast I start new intent. Trouble is phone screen call activity kicks in and shows up, straight to the top.
Can I force my activity on top of incoming call activity? How?
Can I prevent broadcast further? I guess theoretically on 4.1+ for which PHONE_STATE is ordered broadcast I could but I'm skeptical; and how would I achieve same thing on 2.3.3 where PHONE_STATE is non ordered broadcast?
Can I somehow disable, hide incoming call activity?
If I have no choice but to use TYPE_SYSTEM_[OVERLAY|ERROR|...] how am I to handle user input (touch, click) ?
Thanks.
I have a floating view created in service, and I need to dispatch key events when I touch this view.
I have found out that view.dispatchKeyEvent() needs context of foreground activity, and key event dispatching only works when activity is foreground.
When you close/pause the activity and touch the view - nothing happens, even no NPE in LogCat.
Is there any way to use this method outside of main activity?
This may be a bit too little too late but I found a solution. (Assuming the OP still wants to trigger OS back button from a floating view or service.)
It seems like it is possible to tell Android to press the back button, if you're a registered Accessibility Service. (Once your component is registered with Android, user must explicitly enable it in System Settings. So if this is simply a niche feature for your app rather than a critical function, it may be an overkill.)
Once you're done registering .etc. accordingly, your background service may tell the Accessibility Service to perform the back button, which can be done by calling
performGlobalAction( GLOBAL_ACTION_BACK )
from the Accessibility Service.
You do need API Level 16 or above for this to work.
I haven't got around to test this, but according to docs, this should work.
Tried and works on a number of recent devices. (Kitkat, Marshmellow and Nouget)
I found the app Back Button (No root) on play store which seem to employ this technique to draw soft buttons for back, home .etc. (which works on LG Nexus 5X and Samsung Galaxy Tab A 2016)
HTH
If I right understand (you did not post any source you have), you need to have floating view over all over apps receives key events, outside your app.
There is some projects shows this ability. (forum-thread androidFloatingImage-repo)
Try to use this floating views example to create each other, or use exactly the same. I think, using something i wrote above you can use callback on key event correctly. Hope it helps;
The primary purpose of my app is to change a smart phone into a sort of smart pager (there is an associated web app, but that's not the purpose of the Android app). I use the Notification system built in to Android to handle alerting the user that they have received a page.
My problem is that the clients want:
The notification ringer to ring forever until acknowledged (easily accomplished with FLAG_INSISTENT)
An easy way to silence the ringer with 1 push of a button. It is really not always feasible due to the nature of their work to press the power button, slide to unlock, and drag down the notification bar. I need to replicate the behavior of a pager.
I need to find a way to satisfy the 2nd requirement. It looks like I can hook into keypresses if I've got an activity running, but of course, when a notification is received, the screen will probably be off. I am looking into this currently, but I was wondering if anyone had some guidance in the meantime.
Does anyone have ideas on how I could accomplish this goal? Are there alternative ways to listen for key presses, or some creative combination of flags that could get me there?
Techniques that would normally be frowned on for Market apps are completely on the table, since the phones are owned by my employer and will only be used by other employees. I just want to avoid using private or deprecated APIs to make switching phone models easier for the developer who eventually inherits this project.
Thank you to everyone for reading!
Does anyone have ideas on how I could accomplish this goal?
You'd have to hold a WakeLock, specifically a FULL_WAKE_LOCK, in order to respond to button presses. This means that battery life will be sucktastic, unless you put some time limit on that (e.g., hold the WakeLock for a minute or two, but otherwise assume the user's not near the device, so don't keep it awake).
You would also need to try to interrupt the keyguard with KeyguardManager. I have not done this so I do not know all of the details. Your "watch for the magic button" logic would have to be in the activity that appears on top of the keyguard.
Also, bear in mind that not all Android devices have physical buttons -- in fact, I would not be the least bit surprised if the whole physical button metaphor goes "poof" with Ice Cream Sandwich later this year. Hence, the button in question really should be an on-screen Button for future-proofing.