Develop Reference

Any listener for system preferences in Android

I want to capture event when an user try to go into the preferences screen, so I can ask password for it. The reason why I try this, I am developing app for the disabled. I don't want them to touch system settings directly, just the permitted helper.
Is there any event listener or receiver for this?
Thanks in advance.

I don't think there is anything in the public APIs that will allow you to do this. Device Admin is probably the closest thing, but I don't think it does this exactly.
If you wish to implement this (and be certain that it will be effective) you'd have to modify the OS slightly on your devices.
One possibility that might work and is within the APIs is to create a replacement home screen that does not show the usual items in the menu. If you were to go this route you could "lock" the into your activity and simply provide them no way to go to the settings except with a password or something. This would be a lot of work though, and would require the user to set your application as their default home screen. And even with this on the newer devices you may run into the trouble because there is a settings button inside the notification pull down, which I don't think there is a way to block, even with a replacement homescreen.

Place of Android app launch

Is it possible to track on Android from where somebody has started an application (i.e. from the drawer, from recent apps menu, or from desktop shortcuts, etc.)?

Sorry, but this isn't possible.
Even if it was, consider how easily such functionality could be abused by malicious software. You can listen to intents directed at you, and those that are broadcast, but application launching should not be a broadcast event.
What you may be able to do is replace the launcher. If the user agrees to it.
You might also be able to hack a work-around by reading the logcat logs. For instance, give your application the android.permission.READ_LOGS permission and parse the logs to determine the application that launched it. This is just an idea, however... it sounds like something you wouldn't want to rely on.

If you built your own home screen it could give you some of that information.
But on a stock device with any available home screens no probably not.

Android Home button disable when Custom lock screenis ON in android

My requirement is to create Custom LockScreen, using below link http://code.google.com/p/contactowner/source/browse/#svn%2Ftrunk%2Fsrc%2Fcom%2Fappengine%2Fparanoid_android%2Flost i am able to create working Fine. But my Problem is when i press HOME button it is opening the Launcher screen. (1) How to Block home button in android ? (2)If it is not possible, How few custom lock screen .apks in the android market able to block Home button.
How can i achieve that ?
Appreciate your help...

You cannot intercept the key and do this unless you have access to the android source code and can change it. From an app's perspective, you can't do this unless you have the source either. Keep in mind that this is Frowned upon in android.
So the only thing you have available is onUserLeaveHint() which is a method from an Activity. But you still CANNOT stop a user from going home.
Ref:
http://developer.android.com/reference/android/app/Activity.html#onUserLeaveHint()
Here is proof that you cannot do it directly
public static final int KEYCODE_HOME
Since: API Level 1
Key code constant: Home key. This key is handled by the
framework and is never delivered to applications.
Constant Value: 3 (0x00000003)

actually it is possible to block the home button , as locker replacement apps do (like this one and this one) . however , they do it using a sneaky way which might not work on some devices and/or future versions of android (hint: look at the code of android OS - where and when in the entire runtime of the OS is the home button being blocked from the user?) .
that's why the best thing to do in order to do it nicely is to capture the home button by acting as a launcher . then , when it's time to unlock the locker , you call the original launcher.
another advantage of using this method is that the locker will "stay better" in the memory and will be the first one that will be launched upon bootup (no need for special permission for bootup ) .

it's possible!
use window params setType(TYPE_SYSTEM_ERROR) and you'll get what you want.

JoxTraex is probably right , you shouldn't disable HOME key, or else users will report your app in future
But there is a way to detect home button press,
Check the answer to this question

Android - How can I disable home button temporarily and recreate what Car Home and Toddler Lock have done?

So I'm trying to do what many people have tried before: create an app that does not respond to the Home button. I've looked at many of the similar questions posted here on SO, but none of worked the way I wanted them to.
One thing I tried was making my app essentially another launcher. (Note: a little amount of user input is required to make it work.)
From my application's Manifest:
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.HOME" />
I also disabled the back button and made the launch mode "singleInstance."
I think Toddler Lock did something similar, but my implementation does not behave exactly the same way. Using my implementation, my app exists as the default home launcher indefinitely including after the application has been exited. Is there any way to declare the same behavior in a place other than the Application Manifest where it can be turned on temporarily or and turned off when the app is exited?
Car Home also does a similar thing and actually does it better than Toddler Lock. I'm not sure how it does it (maybe it has more permissions since it is a native app), but it manages to do the same thing without requiring the user to accept the alternate Launcher or choose the app as the default Launcher. Anyone have any idea on how it does it?

hackbod is essentially correct. I have gotten much of the desired behavior by
Make a "capture home key" activity
as described in the question. This
is not the main activity of the
program.
In the manifest, disable it.
In the app, enable the "capture home
key" activity when you want the home
capture to happen, and disable it
when you want to exit.
The only question is what the capture home key activity should actually do. In my case, I needed it to just go to the start of the app... so it manufactures a CATEGORY_HOME intent, tests that it resolves correctly, and if so forwards on to the app. If it doesn't resolve correctly, it notifies the user, waits for the user to be ready, and then uses that intent. This way if the user chooses your app but doesn't make it default, he'll get prompted again.

To disable this after the user has enabled your app as the home app, disable that activity with PackageManager.setComponentEnabledSetting(). Note this implies that the activity that is overriding home should not be the main activity of your app, or else upon disabling it the user won't be able to return to your app.
CarHome is very different -- when Android is in a different UI mode (in a car for car mode or on a desk dock for desk mode), then a different Intent will be launched when the user presses home so that they can have a different "home" in that environment. If you are not writing a car mode home screen, you should not be using this.

Removing Widget from Home Screen when Uninstalled

When my application is uninstalled, a widget that is contained in this packages stays on the HOME
screen and gives an error message "problem loading widget".
How do I remove the widget when my application is uninstalled? Is there an
attribute in the manifest that I am missing?
I thought this thing should be handled by the OS, but guess it is not.
EDITED: I am now catching the "PACKAGE_ REMOVED" intent, and checking the "EXTRA_REPLACING" to make sure it's not a reinstall, but I don't know the actual code to use to actually remove the widget.

You cannot add or remove app widgets from the home screen. Only the user can do that.
Quoting #CommonsWare #4532121