I need to "lock" a user into an application. The device's sole purpose is to use this application, and so it is not feasible to allow the user to navigate the device for any other reason. What is the best way to make sure that the applications Activitys are always in the foreground, and if not, launch the main Activity?
Now I know this goes against everything about the typical Android application development, but these devices are going to be specifically used for this one application.
What is the best way to determine if any of the applications Activitys are in the foreground, and launch one if not?
What is the best way to make sure that the applications Activitys are always in the foreground, and if not, launch the main Activity?
You don't.
Make your activity be the home screen, and they can't go anywhere. And roll your own firmware, so that the user can't safe-boot the device and remove your home screen.
I will probably use a service which gonna check using a flag as example for a living activity.
Look here for more detail about how to do : http://developer.android.com/guide/topics/fundamentals.html
See the answer to this question: basically you must implement a second app that captures home intents and simply re-launches your primary application if it is ever closed.
In reference to what CommonsWare was saying, you could actually partially brick the device. I've done it on accident where I've bricked the recovery menu, but not the actual regular boot. This is a terrible idea of course and should not be used practically.
Related
Is it possible to close an activity which hasn't been started by your activity?
So, suppose I have an app which has MainActivity. My Mainactivity wants to close CNN app that is installed on my phone (and probably running in background). Is it possible?
To do that, you'll either need to have a rooted phone, OR, have created the other application yourself (so you could write code to close itself down when getting a specific broadcast)
Seeing as you want to close the CNN app, which im guessing you haven't created yourself, then no, it's not possible.
An application can't simply manipulate other applications lifecycle.
Mostly no. Because of android security model you cannot have direct access to third party activities data/methods. You could only close 3rd party activity via intent in this activity will support this kind behaviour.
I own an android 4.0.3 tablet and I'm programming in Java/SDK, still not tried NDK.
Now, suppose that you want to program this tablet to put it in a service point, with a single use case, like a restaurant, where it would show menus and let the user pass them. I would like not to let the user to shut down this software. Also, it must automatically runs at tablet start up and persisnts on, i.e. if it shuts down by some reason, the tablet should not go back to its standard GUI but to restart this application.
I don't know any start point for this, like some keywords etc. I imagine that here I must code a service (that maintains the persistence and startup of the application) and the application itself.
Could you please give some ideas / keywords / potential start points / comments?
Thank you in advance.
Here some things you need to check:
1.) How to start an application at boot.
2.) How to run a service/thread in background to check if the application is running and if not to start it.
3.) How to deactivate buttons, ie like the "back" button to not exit the app or program a way that the activity never exits with user interference. (That is very bad practice though!) :)
4.) There should be a way to exit the application though for maintenance purposes. Be creative in that one. Maybe exit only with password or something.
I would like to not to let the user to shut down this software so it must persist.
Make it be the home screen.
Also, it must automatically runs at tablet start up and persisnts on, i.e. if it shuts down by some reason, the tablet should not go back to its standard GUI but to restart this application and represent its GUI.
Make it be the home screen.
i just want to know how can i detect if the user opens an app so an activity of mine launches as well.
For example, the user opens the sms app and right after a kind of lockscreen appears.
You can create a service which will run int the background and you can use this API to determine which activity is visible. That's how many app lock works.
As far as I understand the Android system, it is not possible unless you are making a custom firmware.
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.
I am not satisfied with any of the app locker programs for Android that I have found and would like to create my own, but I am having trouble figuring out how to implement the actual lock. How does one go about implementing an app locker for Android?
There are two issues:
Detecting an Intent, usually from the launcher calling startActivity() or from an ad launching the market app (I'm not talking about broadcast intents -- I need to handle explicit Activity Intents).
The permissions for the locker apps I have seen all have "read system log files" and/or "retrieve running applications" which suggests they might use polling to look for app launches. I think I could do this, but I would like to find a better solution if possible.
Preventing the locked app from processing the Intent. I would prefer not to allow the locked app to run at all until the passcode is entered since it is impossible to tell what it might do when it starts up.
When running my current app locker, logcat shows "ActivityManager: Starting activity" first with the Intent for the locked app, then again with the Intent for the app locker, with nothing in between (separated by 10-20ms). If I enter the correct passcode then I see "ActivityManager: moveTaskToBack".
I have experimented with a test app which demonstrates that, using my current app locker, none of the Activity callbacks are invoked if the app is locked and I do not enter the correct passcode. So it appears to be preventing the app from starting (but I don't know how).
I could use ActivityManager.killBackgroundProcesses() to stop an app, but I have no guarantee that the app hasn't already started running by the time it gets "killed".
I might be able to use PackageManager.setApplicationEnabledSetting() to prevent an app from being instantiated, but I don't think that will take care of apps that are already running (which shouldn't be allowed to process new Intents or come to the foreground). I might be able to use killBackgroundProcesses() to stop all running locked processes so they would have to be re-instantiated. But I don't like this approach because other apps could mess with the Enabled settings and defeat the lock.
Optimally, the system would send every Intent to my app for inspection and allow me to stop or let it pass through, but I'm pretty sure that's not possible (at least, not for explicit intents to start activities from a launcher).
Does anyone know how app locker apps are implemented, or have any bright ideas on how it could be done?
I would look into the lifecycle. Once the app in question begins to load, some activity from that package will be added to the forefront activity.
A scan of the changes in forefront activities might do the trick.
http://developer.android.com/reference/android/app/Activity.html#ProcessLifecycle