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.
Related
In Xamarin.Forms Android app the MainActivity.OnCreate is called again after pressing the device Back button to exit app then pressing app icon or snapshot in the app running list to launch again. Thus, all states are lost though the app seems to remain in the app running list. If I press the device middle button to exit then press the app icon to launch again, I see the apps keep all states since MainActivity.OnCreate is not called, which has some initialization codes.
Question 1: Why there's difference between exiting app via Back button and via Middle button? While both ways have the app still running.
Question 2: Is it worthy/legitimate/conventional to make both ways provide the same app behaviors -- keeping all states when being activated again?
Question 3: If yes, how to do correctly?
Please refer to: https://learn.microsoft.com/en-us/xamarin/android/app-fundamentals/activity-lifecycle/
And: https://learn.microsoft.com/en-us/xamarin/xamarin-forms/app-fundamentals/app-lifecycle
Question 1: Why there's difference between exiting app via Back button and via Middle button? While both ways have the app still running.
In XF, the back button can serve multiple purposes on android such as popping pages from the navigation stack or exiting and killing the app. Although the app still appears backgrounded after pressing back, it is actually terminated. The middle button puts the app in the background.
Question 2: Is it worthy/legitimate/conventional to make both ways provide the same app behaviors -- keeping all states when being activated again?
This question is subjective, meaning it depends on what you are trying to do. But generally, no. It is important to adhere to Android OS best practices because users expect the buttons on their device to behave in a similar fashion to how they behave in the OS.
https://developer.android.com/distribute/best-practices/develop/
Question 3: If yes, how to do correctly?
See links above. This is also a great resource: https://learn.microsoft.com/en-us/xamarin/
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 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)
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.
Can someone point me in the right direction to have an Android Application reopen itself to the forefront after a user has pressed the home key? It should be able to be linked to some kind of countdown (which I already have setup, and runs when pushed to background).
I just can't find the function to force this action
*And yes, this is what the user will want, don't worry, I know this doesn't sound user friendly (forcing open) but in this case the user wants it.
Thanks
I needed the exact same thing before -> an app being displayed upon an event but I was sure I read on the Android developers site that this can't be done and that's what notifications are used for, although starting a new activity does bring an app to front. I found this link however to a NEW_TASK_LAUNCH flag with startactivity that might solve your problem -
http://developer.android.com/guide/appendix/faq/framework.html#4