Develop Reference

how to prevent use of HOME button in android and ios?

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.

Give user choice of setting default home page

I'm looking for a way to present the user a choice of setting the home page programmatically.
What I want is for my app to ask the user to pick their choice every time it starts up. Is there a way to do this? Or is there a work around for this?
Thank you

The only thing you can do is bring up the home screen. If the user has not already chosen a default home screen, and there is more than one home screen installed on the device, the chooser will let the user choose a default. The user is welcome to not choose a default as well, as it is their device, not yours.

Adobe Flash Builder Flex Mobile Android: Avoid that user can close the app

I am developing an app for android. It is not always clear to me when the app will be terminated by the OS. Sometimes it happens when you press the back button and sometimes when you press the home button. What is the logic behind this?
My app must be keep activated during a long period (when you run it the app must stay resident). Also another question is if it is possible to popup when an event comes in and activate the screen and bring it to the front.
Does somebody made this already? Or is there more information about this (how to do it). Search the internet but doesn't find some useful things.

Pressing the Back button on the main activity will finish and exit the app.
Pressing the Home button will pause and leave the app in the background, it will return to the previous state when it's restored.
Override the onBackPressed() method on the main activity if you don't want it to quit when the back button is pressed.
If you want an event to occur when the screen is shown, override the onResume() method and do the checks and event required in there.

Being that your answer is with Flex the issue is that you need to listen to the stage's keyDown event.
stage.addEventListener(KeyboardEvent.Key_DOWN, yourHandler);
Then you need to response to the back button and inhibit this - if your intent is to stop the back button.
private function _onStage_keyDownHandler(event:KeyboardEvent)
{
if(event.keyCode == Keyboard.BACK)
{
event.stopImmediatePropogation();
event.preventDefault();
//your code here
}
}

And one more moment - android can close your app when it thinks that it need more memory for more recent apps.
And you may need to use native extensions or even develop your app in java if you want to implement reliable resident behavior.
Update: java service+ air ui example:
http://www.jamesward.com/2011/05/11/extending-air-for-android/
end of update
And you must know that air apps eat at least 30mb of memory(if they are empty and do nothing), normally they will start from 50-70mb. I guess that no user will wish to allow another 70mb of his memory-hungry device to be eaten by something not critical.
And for automatic maximizing of your window you may need root access.

Need clear understanding of Home vs Back events

I would like to know the "idea / use" of the home versus the back button. I mean obviously the home button takes you to the home screen and the back button takes you to the previous screen. What I am trying to understand is what the users / development community expect.
In other words when a user hits home in my application should I handle that event and terminate the application? Is that what the user has grown to expect or just the opposite?
Same for the back button. Do users expect the screen being departed from to be lost much like a web page would be?
What I am getting at is trying to make sure my app behaves consistent with what the user community has grown to expect.
TIA
JB

Home Button will put application in onPause() -> onStop() , again when you relaunch application, the activity will execute the method: onRestart() -> onStart() -> onResume() -> i.e. activity life cycle
and
Back button finishes or kills the current Activity on click of back button and jump back to the previous Activity which is in stack.

Generally I'd say that pressing home is like minimising on a desktop. So I would expect the app to return to where it was.
If it acts like this then I can easily switch between apps if I need to get information from them.
Pressing back should take me backwards through the things I was doing in the app and when I reach the end of the stack it should close.

home button pressing causes an intent that is used by the the launcher app to show itself .
back button is a real event that can be caught within the current app .
in general , home button should hide all apps and go to the launcher , while back button should go back to the previous screen the user saw (finish the activity or dismiss the dialog) , and go to the previous app (task ) in case the current one doesn't have any more screens to show .

The community expects that if you press the home button, your app will go to the background and be resumeable from there. Multitasking is in the core of the Android OS. To finish your activity or app when home button is pressed is unusual to android users.
The back button is when you want to go one step back, like in the browser as you said. If you are know to IOS it will act like when you press the back button there in the top left corner.
Hope this helps

I would like to know the "idea / use" of the home versus the back
button
Let me Discuss for Back Button First.
The back button behavior is inconsistent.
for Users, it is very easy to use.
for Developer, to understand what actually pressing the back button does it isn't so easy.
The back button can perform any of the following actions as Officially said by Android site :
Go back to previous screen (activity)
Dismiss a popup
Terminate a long running process
Close on-screen keyboard
Go to previous page on browser
Exit the running app when on the last activity
Return to previous app when on the last activity and the app was launched through intent from another app
When Problem Occur with BACK button?
An added problem comes when trying to understand when the back button
cancels a running operation and when not. For example, when installing
apps from Android market tapping back takes users to previous screen
and leaves the installation process running in background. I know
there's a rule that back cancels operations that are presented users
as popup progress indicators and any other cases it is used to
navigate. But is that what users expect? Do users have to think before
pressing back to understand what is going to happen?
Home Button
Home button will take users to home screen and swiping in the
multitasking menu will kill the apps if needed. As on ICS on new
phones all the buttons are on-screen the back button could simply get
disabled when user reaches the last activity if the app was launched
from launcher icon. This would make some of the confusion to make away
but still wouldn't solve all the problems.
Finally , Don't Make Users Think Navigation is some what more important. Users should always know where they will endup without thinking.
I don't think there are easy answers for this problem but I think it may help you to find workaround for your problem according to your app.

Android: How to control the home button

We're trying to provide an application to the mentally and physically handicapped daughter of my neighbor that let's her use an Android tablet as a Talker, i.e., she presses a few big buttons and the devices generates speech. The application is basically a WebView and an additional object in Javascript used to perform and control the speech generation, plus some logic to handle the orientation changes. Html files are generated offline for her specific layout of the talking items. We've also added some music playing and picture viewing facilities to make the device more appealing to her.
Problem is that the home button brings her back into the madness of the Android launcher screen, and that on the test device (Archos 70) the home button is not a physical button but rather shown on the touch screen itself, making it too easy to accidentally hit it.
So I'd like to return to the Android launcher only by pressing a sequence home, back, home with no other action in between.
Can I achieve this by making my application itself the launcher? How can I then get back to the original launcher upon the home, back, home sequence? It seems that this goes deep into the innards of Android, huh?
The only clue I found so far is Overriding Home button for a Car Home replacement app, but this is rated -1 and reported to work in the emulator only. Also I doubt if I could completely abandon the original launcher, as otherwise there is no access anymore to e.g. the USB mass device control to allow new HTML files to be downloaded, the application to be killed and restarted, and so forth.
I'm willing to go for a kludge as well. Maybe a background service could be started that would bring the application to the front again as necessary?

The Home button cannot be overriden. You can write an application that responds to the home intent (that's what a launcher does) but that's all.

Can I achieve this by making my application itself the launcher? How can I then get back to the original launcher upon the home, back, home sequence? It seems that this goes deep into the innards of Android, huh?
Yes. Not too deep into the
innards. You can manually start a launcher by specifying the component, note that this may vary from device to device and user to user, if you're just using this privately you could hard code it, but if you release it you must allow the user to specify their real home app.
/* This should come from a preference that let's the user select an activity that can handle the HOME intent */
String packageName = "com.android.launcher";
String packageClass = "com.android.launcher2.Launcher";
Intent home_intent = new Intent(Intent.ACTION_MAIN);
home_intent.addCategory(Intent.CATEGORY_HOME);
home_intent.setComponent(new ComponentName(packageName, packageClass));
home_intent.addFlags(Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS);
/* Here you should catch the exception when the launcher has been uninstalled, and let the user save themselves by opening the Market or an app list or something. Users sometimes use root apps to uninstall the system launcher, so your fake launcher is all that is left. Might as well give the poor user a hand. */
startActivity(home_intent);
Detecting home/back/home is a bit awkard because home won't come as a onKeyEvent but instead as a new intent. Simply long-pressing the back button then display a prompt is probably a safe/good approach.