Develop Reference

Android - blocking hardware buttons while locked

I'm looking into making an app that prevents the default action on volume up / down key presses, and would like to get some input to see if I'd be wasting my time trying.
Here's the setup:
I have a Samsung Galaxy S3. I like to listen to music. Often i unintentionally change the volume of whats playing when the phone is locked and in my pocket.
At first i thought it would be simple; having tested a simple override of the onKeyDown() method for retrieving the integer values for the volume keys. Quickly i came to the realization that this would only work if i were to not lock my phone and keep ONLY that app open.
Next i found a few articles on Services, however i believe this also falls short for my needs as it's not a subset of Activity and so doesn't implement onKeyDown(); and unless I'm mistaken, a wake lock actually wakes and/or unlocks the phone?
Should I give up now, or is this actually achievable?
(actually it must be possible as the whole point of this is that i don't have to pay £3 for an app for this one feature. lol)
Note: Running 4.2.1
New to Android, but not to Java.
Steve.
Edit: Just a thought, but if i extended Activity to my own class (and override onKeyDown), and instantiated it in a Service as a static instance, would that custom activity persist while the phone is locked?
Edit2: I found this SO post which suggests using FLAG_SHOW_WHEN_LOCKED. I'll start looking at this when I get home, but I'm still open to suggestions and advice :D
Edit 3:
OK so tell me if i start losing the plot here...
Using a broadcast receiver i will listen for the ACTION_SCREEN_OFF flag. If that gets called, create my custom Activity (with the onKeyDown() Override) and set it to FLAG_SHOW_WHEN_LOCKED to take over my lock screen (i don't care because the screen is off). The receiver then listens for the ACTION_SCREEN_OFF, if called it will then destroy the Activity before showing the screen (or after, I'm not bothered if it flickers).
(possibly even just pause it, and only kill it if it detects an unlock).
Also a big thanks to #StoneBird for getting me this far, sometimes it helps to just hash it out with someone who knows what there talking about (hopefully ^_-).

Try this?
Settings.System
You can start a service and set system volume like every 1 ms to keep it at a steady level. No key checking should be needed since the value is overwritten every 1 ms.
Also, there are free volume keepers on the market so you don't have to pay for that.

Is there a way to know why your application was not given priority as a receiver

I'm trying to override the default incoming screen, something that I know is possible in all edition of Android as fullscreencallerid does it (and well).
If I register a receiver and start an activity, I successfully replace the view with my activity. If however I start filtering by EXTRA_STATE, the default incoming call screen appears.
I suppose what would help is somehow seeing what the hell is android thinking at that point, and why it preferred the default receiver.
Is there a way to trace application lifecycle, even if it involves some heavy tweaking (It's purely for learning purposes).
Thank you.

Call Back button from service Android (system-wide)

I need to remap the Honeycomb "Back" button to a button in my app (service) but after hours of search I'm still nowhere. The functionality must be there system-wise like the back button in ButtonSaviour (see market)
Most solutions for emulating the Back button are based on calling finish(). Not sure if it will work in my case since I have to call finish() from whatever activity I find on the foreground. I do manage to get the foreground application with the code
ActivityManager am = (ActivityManager) getContext().getSystemService(getContext().ACTIVITY_SERVICE);
List<RunningTaskInfo> T = am.getRunningTasks(5);
System.out.println("top activity: "+T.get(0).topActivity);
but I'm not sure how I should send a finish() intent to that..
I also tried the solution posted here http://www.anddev.org/throwing-simulating_keystrokes_programatically-t717.html but I couldn't get around the IWindowManager (has it been removed in Honeycomb?). That solution, however, looks interesting because with that I could send KeyEvent.KEYCODE_BACK from anywhere, anytime.
Please let me know which is the best way to implement this functionality SYSTEM-WIDE, i.e. from a service rather than from a specific application of mine.
cheers
PS: The app is meant to run on my own rooted tablet rather than for distribution to others.

Why does people spam the thread with advises about designs and good practices when the question clearly states that this will not be used for the market?!
Replacing android nav bar is sometimes required in some applications, even if no more than for own pleasure (or programmer satisfaction).
try from java Runtime exec
input keyevent 4
4 means back
button savior most likely uses hidden api, I had encountered that somewere, but don't remember now. When I will find it, I will post back.

The reason you're not finding an answer to this is that this is a terribly hacky way to do things and it indicates that there is something majorly broken with the design of your app. You should not be able to "call the back button," that doesn't make any sense at all. In fact, you really shouldn't change the behavior of the back button at all, users get really upset when you do that. If you have a service, and you need to send messages to an Activity, then use a messenger. But you should certainly not (and certainly cannot) be changing the behavior of other apps from your service. (This would indicate a major security flaw in the system, and would let you hijack someone else's UI, doing potentially dangerous, or at least annoying, things.)

Will the activity be open when you want to simulate the back button? If so, you could set up a timer inside your activity that checks for an exit file every 5 seconds or so. Then, from your service, create the exit file when you want to simulate the back press. When the activity sees that the exit file was created, delete that file and call finish().
As others have suggested, though, doing things this way means that you might need to rethink the app's design. What exactly are you trying to achieve?

application open and close notification

How can I receive a notification whenever a user is opening and closing any application on the phone?

Depends on what you want. Inside the application: ofcourse. you can find out if your own application is getting opened or closed using the function from the lifecycle.
Using the same functions you can deduce you are being send to the background, so that's a bit like finding out something is happening, although it doesn't need to be another app (it could just be 'home'). Also, you won't get the notice what app is being run.
As far as I know there is no "this application is being started" trigger, but you could go the long way around: just like taskkillers do, you can ofcourse find out what tasks are being run. If one is added, then you can kind-off be sure it is being started, and so there you could create some sort of trigger for yourself. But this sounds a bit like a hack.
Maybe you want to expand on your goal, and check out of there are other sollutions?

movement of phone causes unexpected result in code

I am developing an android app which makes no reference to the sensor aspect of the phone. At a certain pint the program sends an sms and then sleeps for five minutes. If I move the phone during this sleep period a dialog box displayed earlier reappears. I realise this is rather vague without code at this stage but to start with is this something to be expected. I am wondering if one of the broadcast listeners is being triggered by the movement but even if this is so I cant make the connection with the dialog box. Any pointers will be much appreciated.

Fist off, I would take care of the orientation change possibility by forcing the app into an orientation by using the option in the manifest file.
Second, I would look at what other apps are on the device that might have an affect on this functionality. Assuming by your question, your app uses BroadcastReceivers. If this is the case, provided your business logic permits, use explicit intents ( new Intent(this, )) in place of implicit intents and receivers. If this is not possible because of business logic, then perhaps using permissions to protect against accidental implicit intent receive triggers. Ref: http://developer.android.com/guide/topics/manifest/permission-element.html (its a good starting place anyways).
Without more info on your specific business logic or source code I can't go much deeper into the problem, but my first suggestion would probably give the simplest result. Just remember to set this attribute for each activity that this problem affects.
Steve.