I just started creating apps, and now I want to know how to build something that
helps me to start an app, by execercising a volume down/up press during the sleepmode of my phone.
I think that it will need an OnReceive Method or something that works like a onclicklistener but i cant figure it out.
Greetings
In a normal way its not possible to catch your volume down/up receiver when your phone is locked(straight-forward). However here in this discussion they are trying to control volume when phone is locked via some other way - LINK
However you can launch your application when the phone is unlocked by using volume down/up event or combination using the receiver logic. You can register for "android.intent.action.MEDIA_BUTTON" to receive the broadcastreceiver.
I am trying to build an app with the ability for it to be shown over Lock Screen when the physical Power button is pressed say 2 times in quick succession or long pressed.
So far I have figured out that I need a-
1) SERVICE- I need a Service that should intercept the Power buttons pressing 2 times / long press- whether the device is locked or not
2) RECEIVER- User Broadcast Receiver to capture the broadcast intent from service and launch my main activity.
A lot of questions on SO are similar but none of them address how to do this because-
The Service cannot have methods to detect Key Events & as a result need to find some other way to figure out when Power key is being pressed. The suggested alternate is to use SCREEN ON and SCREEN OFF intents. But using them causes a problem if the service is running in background and the Screen is woken by some other app, eg an incoming call.
I have seen few apps which use Power button to start apps or activity.
1) Press It- https://play.google.com/store/apps/details?id=com.incrediapp.press.it.macro.creator.time.saver&hl=en
2) Power Button Flashlight- https://play.google.com/store/apps/details?id=com.brink.powerbuttonflashlight&hl=en
Any ideas on how to start an app/activity over the press of Power buttons?
And then show it over the lock screen.
Short answer: You can't! The system wasn't build that way.
How ever many times when someone says: "You can't" he actually mean you can't without hacking it...
So here is an idea for a hack for you:
As you mentioned, services can't listen for key events, but Activity can. So activity is your answer.
Start your activity when the screens goes off, and kill it when it comes back. Also make it transparent just in case you get out of sync and you don't want to be spotted.
Now you got an easier problem to solve, how to trigger the power button from inside your activity.
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.
For this question I'm going to quote another user who got no response to their question:
I've written an Andoid app that uses the hardware Volume buttons for another purpose.
It works fine if the app is running and visible, but when I turn the
screen off or let it time out, the button clicks don't get into my
handlers.
Does anyone know if there is a way to detect these button clicks when
the screen is off?
Source: AV695's question
I'm working on an app myself that makes use of the volume buttons, but as this user also noted, the normal behavior of checking buttons with onKeyPress stops working once the screen is off. This is because the Activity gets paused on screen off.
Is there a way to keep the activity running while the screen is off, or check for the usage of the volume buttons when the screen is off? I tried using a Service for this before but it's impossible to check for the volume keys like that as noted by Commonsware.
I doubt that this is supported (without resorting to a battery-draining wakelock) at either the platform, kernel, or underlying radio firmware levels without modifications to the last to bring volume presses during sleep to the attention of the kernel.
Within the realm of reasonable system-ROM modifications, a more reasonable one might be to modify an existing open source ROM for the device to insert some custom platform level code into the handling of the power button usually used to wake up the device preparatory to unlocking it - that at least we know does get the attention of the kernel. That code could then inform the user by sound or vibration if there are unacknowledged notifications.
You could optionally wait briefly, check device orientation, or look for another key press to avoid doing this in an annoying way when the user is holding the device outside their pocket and trying to unlock it.
Or you could not use the volume key and just set a timer to wake up every 15 minutes and vibrate if there are unacknowledged notifications, avoiding the need to fumble in ones pockets.
You mention it's a custom request: if implies it's one off or low-volume, another option to consider would be that a few vendors have "bluetooth watches" out with an SDK that lets you push notifications from an android device.
If you can capture the notification when it's generated, you could push it to the user's wrist, and then let the phone go back to sleep.
You cannot intercept the key while your application is in background, but instead of listening to the KeyPress itself. You can register a ContentObserver, as described in this question.
As Chris Stratton mentioned, the only way to keep your App alive is by using battery-draining wake locks.
However, since I found myself in the same situation, I came up with another solution. Unfortunately, you'll need a rooted device as well as the Xposed framework.
With Xposed, which replaces the zygot process so you can hook yourself into any constructor and method of the system, you will be able to catch the raw KeyEvents before the system handles them.
This is done in PhoneWindowManager.interceptKeyBeforeQueueing(). By using a XC_MethodHook, you can use beforeHookedMethod() on the afore mentioned method to catch every hardware button event, even if the device is in deep sleep.
After catching events you are interested in, you can create a temporary wake lock to do your things but don't forget to release the wake lock after you finished your work.
A good example of how to accomplish this is the Xposed Torch Module.
If you, however, rely on a non rooted system, the bad news is that it's simply not possible without draining the battery...
I was also trying to implement volume button press detection in my app and I left that part to be developed later once the core part is done. I was able to detect volume key press while screen is on even when phone is locked, from a background service.
Background Video Recorder 2 (BVR2) (and possible BVR1 also, I did not try) is one of the apps that can detect volume key press even when screen is off. While trying to implement volume key detection while screen is off in my app, I installed BVR2, hoping to find how it works. To my surprise it gave my app the ablity to detect volume keys even when screen is off. My app had a ContentObserver to monitor volume changes, but was not working when screen is off. When BVR2 is active my app also could detect volume key press when screen is off. Still digging.
But BVR2 has its own trigger action, that is to record video, an action you may not want to occur just for the sake of you application detecting volume key presses.
Another app is QuickClick. This app can give your app what it lacks, the power to detect volume key presses even when screen is off, without extra unwanted actions. Just install QuickClick and do not configure any action. Create a ContentObserver to monitor for stream volume changes and you are ready. You app will now be able to detect volume key presses even when screen is off.
Please note that my app runs as a background service.
Both of the apps mentioned above are meant for other uses, but uses volume key detection to perform action. I am in no way connected to any of the apps mentioned.
If these apps, and possibly dozens others, can detect volume key press, it can be done. I request experts to find out how to do it, so that we can implement in our app without relying on another app.
If you find this answer useful, please up-vote.
I am not sure if it is as simple as this but check this android blog:
Allowing applications to play nice(r) with each other: Handling remote control buttons
It explains the usage of a broadcast receiver that receives the up/down volume controls and other music controls.
In summary you should use registerMediaButtonEventReceiver
All,
I have searched for an answer to this, but I'm not getting anything exact... It's my first time writing an Android app, so please be gentle :)
I'm pretty bummed about the minimal headset support in Android - unlike e.g. iPhone, it only natively seems to support a single button, so no volume control on headset compatibility. Additionally, if I'm listening to music and a call comes in, the OS pauses the music automatically, but the headset button still functions ONLY as a media button - I can't use it to answer/end the call. If I answer the call via the screen and press the headset button, the music starts again, but the call continues...
I'd like to create a 'middleman' app that can pick up that the headset button has been pressed (via Keyevent.KEYCODE_HEADSETHOOK) and can then determine whether to perform the default ACTION_MEDIA_BUTTON action (toggle play/pause in my chosen media player) or, if there is an incoming call, pause the music and answer the phone (and then, when pressed again, end the call and restart the media player). Perhaps even check for ACTION_MULTIPLE on the headset button to assign different options (ACTION_MEDIA_NEXT, ACTION_MEDIA_PREVIOUS etc.). Perhaps also be able to determine whether different buttons on the headset have been pressed (if the headset is e.g. a fancy iPhone headset) and 'translate' those button presses into the appropriate ACTION_MEDIA_*). This might not be possible if the OS can't tell the difference between different buttons, obviously.
Obviously such an app would have to receive the intent with a high enough priority that it would be able to abort the broadcast before the current media player gets it.
I've been tinkering with creating assorted BroadcastReceiver classes and intent filters etc., but part of the problem is that the bult-in Android emulator that comes with Eclipse doesn't seem to have the ability to simulate a user plugging in the headset and/or subsequently clicking the headset button. Therefore, every time I get somethign that looks promising, I have to put it onto my actual phone and try it out - time-consuming and a hassle.
3 questions then:
Am I missing somethign obvious - is this a real problem and if so, has it already been solved?
If it IS a problem, is it possible to write such a middleman app?
Are there any other Android emulators that can check for headset-related activities?
Thanks,
Rory
i´ve already written exactly this kind of app. Its called like the topic of this thead: Headset Button Controller ;-)
http://www.androidpit.com/en/android/market/apps/app/com.kober.headset/Headset-Button-Controller
Cheers Christoph