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;
Related
I created a background service on android and I have two buttons which appear on the top of the screen all the time. I want to use these two buttons like scroll down and scroll up. But these two buttons should work on any kind of applications like Instagram, Facebook, Twitter and so. So, it means it should work in all applications that use scrolling.
I search a week on internet but I could not find any solutions.
This is not possible, sorry. Something like this would require your Service to have access to the Views of the applications and this would be a huge security breach, because you could read values from them and so on.
You could achieve this with a custom button code broadcast (so basically your buttons would act as physical buttons on the device) but this would most probably require you to have system-level permissions and some level of cooperation with the OEMs.
Android Activity class has a method called dispatchKeyEvent(), which could let you simulate the key input (with some limitations) but this is not present in the Service class.
Sadly this is not something you can do in Android. Typically you should not be able to touch views with a background service, the point of a background service is that you do some work in it (for example upload files to your web server or get some data). You CAN send a signal from a service once you're finished doing work to tell an app that something needs to happen, however the app needs to be specifically coded to respond to this broadcasted event.
If you wanted to do this with an app that you have developed, that can be achieved by using the onReceive method of say a BroadcastReceiver, however you cannot specifically define the behaviour of other apps as this would represent a security breach in Android.
I want to start chromecast routing automatically and not when the user presses the button. Does anyone know how i can simulate in any way that the user pressed the media route button? I have looked through the different classes and not found anything.
I am aware that this is not how Google intends developers to use it, and my application is only functioning as a proof of concept.
If anyone knows another way to achieve the same thing (The casting starts when the app starts, if the user has enabled it in the options menu) - let me know!
You can follow the same steps as usual (get a hold of MediaRouter instance, set a selector, register a callback, etc) but then you need to keep a list of discovered routes in your application (as they are discovered by MediaRouter; you will get a call back via onRouteAdded(()). You need to do the bookkeeping as well (via onRouteRemoved() callback). Now that you have a list of routes, you can programmatically decide which one is the one you want to use and again do as usual (same stuff that you would do when you get a callback via onRouteSelected()) except that you need to call MediaRouter.selectRoute(your_selected_route) yourself to tell the framework about it. For the first part, you can take a look at this sample.
So what I discovered was that I couldn't make a check for routes in the beginning of the program because the MediaRouter hadn't discovered them yet. (I.e the call to getRoutes returned only the default route...) In my program, it was enough to start a thread that sleeps for three seconds and then calls selects any available route:
if(mMediaRouter.getRoutes().size() >= 1) {
mMediaRouter.selectRoute(mMediaRouter.getRoutes().get(1));
}
If I needed a more persistent solution, I'd do as Ali Naddaf suggested.
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?
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.
Is there a way to register a receiver for a app running in the background for when a user presses a key. Kind of like "ACTION_USER_PRESENT" but if any keys were pressed on the screen.
MORE DETAIL: My app is running as a service in the background. User opens the phone and presses keys, like they searching for something online on their driod. Can I capture those key presses in the background?
To detect whether a user is using the device you could also use the information whether the screen is on or off as an approximation (making the assumption that the screen timeout is set). This blog entry shows how to capture the screen on and off events (I haven't done it myself though).
In the Android HCI Extractor ( http://code.google.com/p/android-hci-extractor/ ) we traverse the GUI and install some event filters (by using listeners) in the app top view.
Maybe if you can reach a top level view from which listen the events you could listen to all the events for this view. Let's try ;-)
This tool is an open-source prototype you can find here: http://code.google.com/p/android-hci-extractor/
It is very easy to integrate and use. In the tutorials you can see that only a few lines of code are needed: http://www.catedrasaes.org/trac/wiki/MIM
I hope it helps you!!