I'm planning to deploy an app on my android smartphone which is supposed to be used by multiple other persons. Now of course I do not want them to do things with the device they are not supposed to do so I informed myself about several different ways to make it as safe as possible (Lock-down apps, Kiosk mode, Mobile-device-management, Code-tweaks and so on).
I found some solutions that look really promising but they all share the same problem that a user could just restart the device and boot it in safe-mode where those helpful apps won't be started. However, there is one exception: I've installed a MDM app called maas360 which somehow manages to apply the restrictions that I defined even in safe-mode, for example by blocking access to the menu settings. How is that even possible? The thing is just that this is not a free app and it offers a huge variety of functions - overall it seems to be a bit excessive for my goals.
So my general question would be: is it somehow possible to restrict access to the safe-mode somehow? Maybe like a password? From what I understand it is not even possible to set a system password for Android devices that you'd have to enter once it boots (except if you set up a password for unlocking the screen first which would then be the same one... very redundant).
Disabling physical switch of volume down (in case of samsung devices) will stop access to safe mode on device. I dont find any other way to do so.
Related
I am currently working on a research project which involves people playing games on an Android device. I am hoping to be able to write an android app that records the accelerometer and touch events. I would like my users to be able to play games such as angry birds, whilst I record their touching data.
I understand that this type of data collection is possible from inside the app, but is it possible from outside the app? (perhaps via an app running in the background?)
If this is not possible, are there alternatives? (I believe I could theoretically go into the android OS source code and make this happen?)
I understand that this type of data collection is possible from inside the app, but is it possible from outside the app? (perhaps via an app running in the background?)
For touch events, no, for obvious privacy and security reasons. It used to be possible (research the term "tapjacking"), but current versions of Android finally blocked this behavior.
For accelerometer events, you can record those, because they are the same for all apps simultaneously. Bear in mind that your sampling rate may not exactly match that of the app being used.
I believe I could theoretically go into the android OS source code and make this happen?
Yes, though you would then need to turn that modified Android into a ROM mod and install it on devices.
Apps are not allowed to do this on a secured device (ie, consumer phone/tablet that has not been 'rooted').
However, depending on your needs it may be possible with the development tools connected to a computer. If you can do some moderately annoying setup before each controlled-circumstances trial, I believe you can do it on some stock devices by using the USB cable to switch ADB into wifi mode, then monitoring input events over a wireless ADB session. See
http://source.android.com/tech/input/getevent.html
That document seems to imply that 'su' is needed (which is odd as the official 'su' isn't usable by non-root users), however it works without on many stock devices.
You'd probably also want to be running logcat to figure out what application is in the foreground.
I'm developing a peculiar application which need to prevent the user can go out from application Activities, except with the ways I established inside the application. The Clock in tablet status bar for example allows to go in Android Settings, and I want to prevent it... because I need only some "device administrators" can access to android settings and other apps, others people must can only use this app.
There is a SDK solution?
PS I need to restrict capabilities only to device owner to prevent accidentally damage.
Nope nothing within the public APIs will allow you to do this. I understand that there are legit use cases for it, but to have it possible on all devices would create significant security concerns. (i.e. malicious apps could "lock out" users from their own devices.)
The closest you can get is create a replacement home screen that does not give the user the ability to (easily) go anywhere except where you want.
However as you've noticed with the settings in notification bar there are still loopholes around this. Another of such loopholes is many android keyboards contain a button that will take you to settings.
Also the user may still start their device in "safe mode" which would disable your application.
If you wish to implement this and have it be 100% effective you'd have to modify the OS to allow for it.
I'm wondering if it's possible to develop an android app that will be run in sort of a kiosk mode. The idea is that the user should only be able to interact with the phone through this app.
I understand that an app can be auto-restarted, and things like avoiding incoming calls, could be implemented via a service that would subscribe to the telephony events and would hang up when an incoming call is received. The downside of this is that the usual "answer call screen" would pop up for a short period. The reason behind this is that the stock android app that receives the incoming calls will still be there.
I also understand that, by design, this custom app could be killed at any time by the OS if memory usage gets too low. Although this should only happen if there's a memory leak in any of the running apps.
I'm not sure either if it would be possible to disable the behavior of the physical buttons to access home or settings screens.
I understand that rooting the device and/or creating a custom ROM with modifications would be a safer approach, but also more complex. I'm wondering if a good-enough kiosk mode could be implemented with an android app.
P.S: I'm sorry for reposting these questions, but answers to similar questions are not clear enough.
Make your application be a home screen. That can still be bypassed unless you make your own custom firmware where your application is the system default home screen. We cannot tell you whether being a home screen alone is "a good-enough kiosk mode".
I've been searching for this for days now, nearly every answer is not a complete solution at all (and it's doing my head in)
This link though has the best answer so far
http://thebitplague.wordpress.com/2013/04/05/kiosk-mode-on-the-nexus-7/
I am wondering is it possible to do all these on an Android phone? Example, Samsung Galaxy S phone
To automatically launch a video clip upon phone start up i.e. from off position or phone ‘reboot’/’restart’
To run the video clip while the phone is idling
To launch to a particular wap site when interrupted
To restrict user from going to other portal other than the 3 steps above
To restrict user from running other application on the phone.
1) Yes but it may be hard to completely replace the phone's own screens and animation effects thus giving the smooth experience I think you're looking for. It's also pretty user-hostile.
2) What is 'idling'? If you mean standby, absolutely not. You'd kill the battery in 20 minutes in any case.
3) You can launch a website when the phone comes out of standby but it would be really annoying for the user. As for WAP .. I have no idea if you can view WAP on Android. Probably someone has made a viewer. I wasn't aware WAP was being used by anyone since some time around 2008.
4) Not without making your own custom build of Android and flashing it (very difficult technically). Sounds pretty evil for the user.
5) Again, not without making your own custom build of Android. You're reducing the phone to a brick pretty much with this stuff.
Yes, though it is user-hostile.
I have no idea what you are talking about.
I have no idea what you are talking about.
No, except by making your own firmware. Even by replacing the home screen, the user can boot into the Android equivalent of "safe mode" and bypass a replacement home screen app. You would need to have your home screen be the only one on the device, and your apps be the only one on the device.
See #4.
I will add only to question (1), since all the questions have been already answered. If you talk about replacing the standard boot and shutdown animations, then yes, it is very possible and pretty much any custom ROM for the SGS will let you do that. It's just a matter of assembling the sequence of PNG files you want. There are two image flashes before the animation, one is built-in in the bootloader, the other is hardcoded on the kernel.
Examples: http://forum.xda-developers.com/showthread.php?t=869347
You can do all these things, however you will need to flash a custom image - I assume you want to customise in-house handsets for a specific project, rather than have this as a generic app - I can't imagine normal users installing this kind of lockdown, and it sounds similar to an approach I was looking at for a project needing cheap PDAs with GSM connectivity.
If that's the case, and volumes are low, you might be better off targeting developer handsets, which can be bought through a publisher account on Android Market. I think this limits you to 10 handsets.
Hope this helps,
Phil Lello
We are currently developing an Android app that is a fitness-tracker application. It runs constantly in the background, and it works fine on most devices, but we've been having issues with the application dying completely on some Samsung devices. After some investigation, it seems like some Samsung devices has a completely custom "App Optimisation" feature (http://forums.androidcentral.com/samsung-galaxy-s6/599408-app-optimisation-after-updating.html), which is basically a (very) primitive version of the Doze feature that exists in later versions of Android which basically just murders apps if they haven't been used for three days.
As this app is more or less only doing logging, and doesn't open the activity, it presents a big problem for us, because this feature is pre-enabled on many Samsung devices. The problem is solved by using a foreground service, but that is a sledgehammer of a solution that requires disturbing the user with a constant notification, and we really don't need the app to be in the foreground - we are fine with the normal power management of Android.
The Samsung App Optimisation feature clearly states that it will "optimise" apps if they have not been used for three days. Does anyone have insight in what Samsung considers to be "used" and can I somehow trigger that?
Side-rant: In my opinion, this is a badly implemented feature that makes development on Android more hostile. Besides our use case, it will any messenger applications break. If it were not for the fact that Facebook Messenger and Whatsapp are hard-wired to be exempt for the app, users would be going crazy because it would be breaking their experiences.
I've owned (and currently own) Samsung devices, so I know a little as to how it works from the user's point of view. The technical specifications and how it works on the inside is an entirely separate issue, and one I can't answer.
The system can detect if you open an app. Samsung uses that in their app optimization, and will save power on apps that haven't been used in over three days. It is a terrible system though.
It ignores background-processes that may be critical to apps, and even if it is an app you actively use, like a fitness tracker, it will have issues. To quote what it says inside the app optimization-list:
"To save battery power, apps that haven't been used for more than 3 days will be designated to save power. Apps designated to save power may not show notifications"
(Rough translation from Norwegian, originally taken from an S6 running Android 6)
Therefore, apps that have been manually, or automatically set (3 days of no use) may give various issues with background processes. But remember that the user can set any app to never save battery, and ignoring the automatic setting. So with this in mind, let's consider possible solutions.
There is one scenario where you do not need to worry about the app and app optimization: When app optimization is disabled entirely.
Looking aside that, there is really only two things you can do:
Ask users on Samsung to disable battery optimization for your app to prevent issues
As #MinaSamy suggested (in their now deleted answer), SyncAdapter and having a periodic synchronization. Note that I haven't tested this, so I don't know whether it works or not.
And there's also a third option, which really isn't a solution, but you can ignore it and gamble on app optimization being disabled, or just not care about it at all.
Does anyone have insight in what Samsung considers to be "used" and can I somehow trigger that?
As far as I know, unless Samsung added some safeguards against accidental opening or added some kind of minimum activity requirement, opening is enough. It appears to be a "stupid" feature, which runs on hard-coded rules rather than a dynamic system that actually detects app use and sets power saving relative to that. It's "easy to enable", but fortunately easy to disable as well.
Meaning you cannot trigger an event that will keep it alive (unless SyncAdapter does the trick)
And to make the facts clear, from #Neil's answer:
It does seem like the user can do this, so there must be some database or setting somewhere that controls it.
There kinda is. There are a total of four settings, three of which are app-specific, and it is stored in a database (or some other form of data storage). These four settings can be used, although extremely shallow, to alter the behavior of the app optimization:
Always optimize
Automatic optimization
Never optimize
Disable app optimization
The first three options are on a per-app basis, which means each app can have separate settings. Disabling app optimization is exactly what you'd expect: it disables the entire feature for all apps. If it's disabled entirely, nothing is optimized.
There's also a website listing ways of bypassing optimizations on a per-brand basis. The entry for Samsung is more or less what I've said: tell the user to manually disable optimization. There are no developer solutions.
In settings>device health>battery there's an option to "put unused apps to sleep". You can turn it off, or change the amount of time it takes, which is 3 days by default.
Sounds like that's your problem.
https://forums.androidcentral.com/samsung-galaxy-s10-s10-plus/964083-whats-disabling-some-my-apps-background.html
Is there a reason you can't add your service to the 'don't optimise' list?
It does seem like the user can do this, so there must be some database or setting somewhere that controls it.
Alternatively, if you detect you are installing on one of the devices, open the optimise activity page, and show a message saying "Don't optimise us!".
As a workaround, i implemented the SyncAdapter mechanism, using this link as a good starting point: https://github.com/bmeike/MiniSync
It doesn't work perfectly (for testing, in my app i write a log every 1h, and after 3 days, it starts not respecting this scheduling), but at least it doesn't stop after 3 days, without the need to put the app in ignored optimization mode.
UPDATE: After the update to android PIE, scheduling stopped again after 3 days.
On another device, same app with android Oreo, scheduling is working (even if not completely respected).
On Samsung phones, the culprit is this Sleep setting:
You have got to take your users to this system settings screen and ask them to turn the feature off.
In my opinion you should implement a 'Broadcast Receiver' that listens to a custom 'Intent' and this 'Intent' to be Broadcasted by the 'Service' from 'onDestroy()' method of the 'Service' because when the 'System' kill the 'Service' this method will be called definitely.
And when the 'Broadcast Receiver' receives the 'Intent' you should start the 'Service' again.
And to distinguish between you stopping the 'Service' or the 'System' stopping the 'Service' just use some 'booleans' stored in 'SharedPreferences' and then in the 'Broadcast Receiver' you decide whether to activate the 'Service' or not
we are fine with the normal power management of Android
Are you? From the Android docs
However, since the user is not directly aware of a background service, in that state it is considered a valid candidate to kill, and you should be prepared for this to happen. In particular, long-running services will be increasingly likely to kill and are guaranteed to be killed (and restarted if appropriate) if they remain started long enough.
Three days seems like it would fall under "long-running...guaranteed to be killed".
If the problem is not that your service is killed but that it isn't restarted, you could use the AlarmManager to regularly check the status of your service and restart, if necessary.