The question I'm about to ask may seem dangerous for the user, so here's the story before the question:
I'm working in a compagny that tries to sell Galaxy Tabs to schools (children under 10). So, I've been asked to develop an application that starts on boot showing a login screen. The child HAS to log in before he's allowed to use the tablet (just like logging in a computer).
My application starts on boot, shows the login screen, all buttons are blocked (the kid must not be able to use the tablet before the application lets him) except the home button.
fortunately, it seems impossible to block the home button.
I've been trying to rebring the application to front when onpause/onstop is called, this kind of hacks.
So my question is : Can I prevent an user to quit my application until I let him do so?
I know this sounds like a virus, I'm not really happy to be looking for this kind of solution either.
You have to build a custom Home screen, and then set it as the default Home application.
EDIT: see more on this previously asked question (at How can I create a custom home-screen replacement application for Android?). You can just make your authorization the default Home application, then when they log in it forwards to the regular Home screen. If they hit the home button your app gets called, can check if they have logged in and if they have will just send them to the regular home screen.
Related
I was just bored of iOS and I recently changed to Android. I have a Nexus 5 device, and I've just finished installing my favourite apps in my device.
One of those apps is Line, the famous communication app from naver. I installed it and I configured it with a passcode in order to secure access to it, so no one despite me could see the "confidential" conversations inside.
The problem is even if I have the passcode enabled on line, if someone presses the "Recent list applications" button, they can see perfectly a screenshot of Line with my last conversation, so anyone could see what I was doing in Line.
I made the same test on iPhone and .. surprise ... iOS is taking the snapshot AFTER the passcode screen is enabled, so anyone could see nothing. It seems that in Android the snapshot is taken BEFORE passcode screen is enabled so anyone could see what last line screen looks like :)
So, having read other threads on this forums, I'm supposed to have several ways to solve this:
Wait for LINE's company NAVER to add an option to prevent this app to show on recent app list (adding android:excludeFromRecents="true" on THEIR manifest) [that won't be soon]
Wait for LINE's company NAVER to force the snapshot after passcode screen is enabled [maybe soon but not in company'sroadmap]
Decompile apk and change manifest on my own - or use FLAG_SECURE - (I tried it but when I launch the new app it suddenly dies on startup with a message "Application stopped". I thing LINE's server verifies on startup that the client app is what is expected to be, comparing sizes or something else)
So I don't know more ways to get around this. Do you have any more idea? I'm stucked on it.
Thank you a lot.
Detect when LINE has left foreground
Create a background service that detects if LINE is on foreground and when it leaves the foreground. (https://stackoverflow.com/a/14044662/1683141)
When line has left foreground, you should take action:
A. Stop the line app completely
OR
B. Open & "close" the line app so it will show a locked state in the multitask thumbnail
A possible way to accomplish situation B:
Optionally: detect which app the user has now opened and remember it
Wait a few seconds and open the LINE app again after the user closed it (by intent for example)
Now the LINE app will show the lock screen
Now let the background service open the home screen (or make an intent to the remembered activity)
Now the LINE app is back to the background and it will have a multitask-thumbnail showing the locked screen.
Ofcourse, this will create a loop, and this isn't a stable solution
-Option A is a relatively reliable, and a (in my opinion) good way to accomplish what you want: no one can see your secure chat. Disadvantage is that the application is now removed from multitasking.
-Option B is only an idea, but maybe, if it's done the right way, It could work.
Edit: Option A will not work. The application will not be removed from multitasking if the task is killed.
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.
I have read many question about whether it is possible to prevent an Android application from starting, but all of the answers seem to be "no, you cannot".
The idea is very simple: we want the user to be able to use a restrited set of applications that will be preinstalled on his mobile device. If the user tries to start a non authorized application, he will be prompted with a dialog asking for a PIN. If he enters the right PIN, then he will be able to run the application. Otherwise, the application will not be run.
As I said before, all the answers that I could find out there fall into two categories: "you can't do that" and "you can do that by writting your own launcher application".
However, I have seen applications such as ZDBox, which allow you to do just that. That is, with ZDBox you can define "non authorized" apps, in such a way that if the user tries to start one of them, he will need to enter a PIN to actually start the app. If he fails to provide one, the app will not start. The funny thing is that ZDBox does not require root access to do this.
So my question is, how can we prevent other apps from starting, just as ZDBox does?
Option 1
All the examples I've seen involve running your app as a Launcher/Home Screen replacement. This is how all the child lock style apps I've used work. This has the advantage
Pressing Home button doesn't leave the app
You have control of app launching
You can check out the android Launcher2 code to see how the Android launcher works. https://android.googlesource.com/platform/packages/apps/Launcher2.git
Option 2
There does look to be one alternative that I can see. In that you can try and read the logcat entries to detect when a blacklisted app is launched or brought to foreground and then launch your app over the top.
Similar to how they detect an app launch in How to detect when the user launches another app? (Android)
I am trying to build an AppLock like Android app but I encountered a difficult problem (for me): I managed somehow to detect when a given app is launched, by polling the system log, and bring to front a lock screen, on top of the launched app. My question is: how can i dissmis the launched Activity which must be protected (and, of course, the lock screen) if, for example, an invalid password is provided for the lock screen or the back button is pressed before entering a password?
I have tried using killBackgroundProcess with the correct package name, but it doesn't seem to work and I can't find a relevant answer anywhere.
And one more question: is it, somehow, possible to totally prevent an app from launching, form my app rather than covering it?
Well I found an alternate solution that works like a charm! Instead of dissmising a blocked app, in case an invalid password is provided (for example), I simply bring to front the phone's home screen which implicitly sends to background the blocked app. Hope it will help others with the same issue.
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.