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?
Related
I'm trying to display a view that the user must dismiss each time they unlock their phone (it's intended to be annoying). It should be able to take a small amount of keyboard input, save it, then return to the previously open activity. I tried having a BroadcastReceiver listen for ACTION_USER_PRESENT and launch my own activity, but then I found out we can no longer listen for implicit intents, or have background services launch activities.
I'm not an Android developer (just trying to build something for my phone), but I did some looking, and I see a few options:
Display a full-screen intent. I think something like scheduling a job to raise a notification whenever the phone is locked, so that the notification appears first thing when they unlock the phone.
Use SYSTEM_ALERT_WINDOW and draw my view as an overlay whenever the phone is unlocked. My only concern with this is how apps like Twilight (which I believe draws an overlay to redden the screen) might interact with it. In those cases, I'd like my overlay to appear at the very bottom.
Are either of those options viable or recommended? Any other suggestions or approaches for how I could accomplish this would be greatly appreciated too. I'm just looking for some guidance on what direction I should pursue.
I've an app that should always start from the initial activity when its icon on home screen is pressed.
I've managed to make this work in every situation by finishing the current activities when the application was going to be exited.
But there's a point in the app where this is not possible unless I ruin user experience a lot, which is if the user opens an ad offered by the app and then either goes to home screen (via home button for example) or press back button to keep on using the app.
In both cases the following events are fired: onAdLeftApplication-> onAdClosed-> on Resume (although as how I understand documentation onAdClosed shouldn't fire in the case of opening the browser, but well... it happens).
With this I find no way to differentiate between the 2 cases, although there might be an event, that would allow to differentiate them-
Think the easiest way to solve this problem is to always force that if the icon is pressed what is fired is never onResume, always onCreate, this way I don't have to worry about the app not starting from beginning for whatever, by default it's going to do that.
But maybe what I'm mentioning is not possible anyway, so maybe some event like the one I'm mentioning might help with this problem. I'll happily listen to any recomendation about that.
I am working on an application in which user should be able to use only one application,
he should not be able to switch application using HOME button,
the app. should be closed only when user presses the close button..
I have managed to override return button, don't know how to disable HOME button.
This is not possible to disable the Home Button in android When application is in the background because it might some application always disable the home button if it's possible. So this is the reason developer can't disable the home button when app in background. But In the Activity, you can intercept the home button.
In Activity you can disable the Home key in android. It work till Android 3.x only.
#Override
public void onAttachedToWindow() {
this.getWindow().setType(WindowManager.LayoutParams.TYPE_KEYGUARD);
super.onAttachedToWindow();
}
TGMCians is right.
Android will not let an activity and its services run completely alone on your device.
Using Override you can capture button clicks (home, back and menu) when your activity is in the foreground. If an activity/service has full control from the background you would not be able to switch for an incoming sms, e-mails, phone calls, etc either.
Personally I think its dangerous to override the home and back button together, if the activity hangs at some point, you can not get out of the app unless you restart the phone.
Personally, I do override the back key for exit, or return to main screen events, but leave the home button alone.
This is not possible using code at all on iOS, ever.
One usage of HOME button is for emergency situation.
Any house, apartment ... they all have an emergency method, like emergency door (exit), glass breaker (axe, bat ...); it saves life.
Similarly, on Android/iOS phone, HOME button saves users' lives (well, kind of). If HOME button is dead, the phone is considered dead as well as required an instant reboot for refresh. The button was designed for such a purpose, so that developers can't messed-up with everything.
Personally, I'm kinda of being thankful for Android/iOS framework team and whoever thought of this situation on HOME button. It saves my development so many times. I suggest you should think and consider the worst case possible if HOME button is not working in your app; for example, app fails to function as normal, HOME is disabled, so how to back to HOME screen, how to switch to other apps?...
The code provided by TGMCians is not working on 4.0+.
In case, you are working on Android framework, such as building ROMs, building frameworks for manufacturers, ... grep the source code with KEY_HOME and trace inner-depth to find how it works and disable it.
actually, it is possible to block the home button using the next methods:
use of security holes, at least on old android versions. this is done on some locker apps. i think some still work even on newer android versions, but it's a risk and it might be buggy on some devices. i know that "widgetLocker" and "Picture Password Lockscreen" try out those holes. i'm not sure how well they work now with them. best solution of becoming a lockscreen is #2 .
make your app a launcher app, which will handle the home button (user must confirm it of course). an example of such an app is "MagicLocker" , and in fact any launcher app...
using a rooted device. i have no idea how to do it, but i think it's very possible.
not quite a blocking method, but you could have your app full screen and on top (using the TYPE_SYSTEM_ALERT window layout type) , so home button won't be captured, but the user won't see what's going on behind your app. the downside is that any other button won't be captured by your app, since it's not really on the foreground.
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
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.