I want to write an app that needs accelerometer data while the user has the device in his pocket. However, at least on my phone (Motorola Defy with a nightly CM9 build), a dim-wakelock is needed because the accelerometer somehow turns off together with the screen. But if the screen stays turned on, the user might trigger random touch actions with his body movements. I could just display a black area, but that won't protect the menu keys. So, what should I do to protect the device from accidential user interaction? Things that come to my mind:
use root access to somehow hook deep into the system and require an unlock pattern or so - but I as a user would hesitate to give an app root just because it wants to block my input, and if I as coder make a mistake, I might lock out users -> might work, but probably the worst possible solution
somehow use the lock screen for this - but I don't know how I can safely, whatever the settings on the device may be, activate that lock screen without needing root
Gah, this all just looks bad to me. Is there any way to solve this that doesn't suck?
Related
I am developing an app that locks the screen for some time, just like parental control apps do when the screen time runs out. However, I do not really know how they work. I suppose they don't use lockNow because there is that message that shows up telling you that the time has run out. I also don't think they use overlays, because the phone is supposed to detect the use of overlays. So does anybody know what kind of function is used? Also for my app I want to add a button that ends the screen lock, so I am looking for a suitable way to achieve that.
I want to prevent users from leaving the application (client requirement, not a mass public application).
But the IME allows the user to reach settings by pressing some touch. How can I block this without developing my own keyboard ?
As far as I understand from Google documentation, there is not much I can do because the IME is the first component to receive the screen inputs and it is the IME which decides what inputs my application receives.
Any pointer appreciated.
There's really no way to prevent somebody from being able to leave your app without a custom rom. However, Android 5.0 Lollipop allows device owners to pin the screen. For example, conferences that hand out tablets to their attendees are using the feature to restrict tablet usage to the conference app.
Here's a good write up to the feature:
http://www.androidpolice.com/2014/10/17/lollipop-feature-spotlight-screen-pinning-allows-you-to-lock-your-device-to-a-single-app-before-handing-it-to-a-friend/
Alternatively you could try one of the various launchers on the Play Store that use alternative locking strategies, but in my experience there's often a way around them unless they simply lock the device completely.
I want to write a simple convenience app that allows me to have two locking modes on my phone. By default the phone would just go to the slide lock after a minute or two, but after a longer time or if I activate my app, it should engage a more stringent lock, such as the face unlocking. Basically when I have the phone on me, anything but the slide lock is overkill.
To do this I would have to read/write the preferences for the screen lock or find a list of available locking/unlocking mechanisms so I can select and invoke one of them. Does anybody know where this information can be found/is stored?
I expected the preference keys to be found in the (System.Secure class), but could not immediately find anything related except the LOCK_PATTERN_ENABLED setting, which would not be enough.
I tried searching for references to the FaceDetector class, but none are returned in my Eclipse.
The Device Administration API Sample looks like it might give some leads if I could look at the source code. Unfortunately the page omits the detail of which of the several folders of each of the sample directories for the approx. 10 API levels supporting I need to download and look in, as far as I can see.
You can change lock modes in your app only if it is a device admin. These API are located in class DevicePolicyManager and methods setMaximumTimeToLock() and lockNow() etc. It is only accessible only if your app is a device admin. If you are interested in crating a custom lockscreen app, you can try this.
A little background first. I'm developing an application for corporate devices running on the Android platform. It won't be distributed on the Play store and thus, is unavailable to the general public. The devices are owned by the company and its only purpose is to run this application. So accessing the home screen/notifications/application history/ app drawer are unnecessary and in fact we want to focus the user experience directly on this application.
The current problem I'm facing is preventing access to the notification tray. Simply making the application full screen is not a solution. We do actually need to see the status bar. It's the easiest way to provide network,gps and battery status information to the user.
So far my research has only turned up one solution, which is to go full screen (again, not a solution for this problem,I need the status bar to be visible). I know there's a number of lock screen apps that are able to do this so there must be a way. I just haven't found it yet.
I am not sure, but probably that you can't just lock notification bar from the application level. Android app is isolated from the Operating System and another apps, so it is not able to lock OS features.
Solution that came into my head is to make app fullscreen and create Your own status bar with battery level, current time and network status. It is not hard.
Another solution would be to prepare Your own Android distribution :)
Moreover probably You would like to override all buttons (home, back, search) so user is not able to leave your app.
Very likely is not going to be possible on a Stock device, you'd have to root and potentially install your own version of the OS to allow for this behavior. The system was purposefully made to disallow applications from having this type of behavior. The creators of the OS had the general public in mind as users, and they wanted to prevent applications from being able to "lock" the user out of portions of the device.
Much easier solution like #Jacek states is go full screen and make your own View to display whatever info that you do want from the Notifications bar, AFAIK there are public APIs to access all of that information.
Is there a way to display text on lock screen? Like the information about unread SMS messages or like that Music Player on lock screen with Play/Pause buttons.
Thanks
Yes and no. Their is no public API to create or modify the lock screen. Whoever built the OS version on your device created your lock screen. Some of the manufacturers or carriers have added additional things to the lock screen. I've seen some that tie in to the music app, HTC sense has a somewhat customizable lock screen. So if you were willing to create your own rom and flash it to your device you could write your own lockscreen. Short of that the best you can do is write an app that the system thinks is an alternate home screen that has some kind of lock mechanism before the actual home is displayed. Then you set your device not to use a lock screen(so that it won't show both) This is not a great solution however, there are bound to be more ways to access the device if you use a "fake" lock screen like that so if security is an issue I wouldn't mess with it at all.
You might be able to find one of these "fake" lock screens on the market that suites your needs or you could create one that is exactly what you want. You could also search around on XDA for a rom that works with your device, 3rd party roms may be more likely to have the features your looking for on the lock screen.
If you end up making a pretend lock screen by using the home replacement method I strongly suggest you do not distribute something like that on the market. It is insecure and the users are unlikely to realize that there is a difference between that and a legit lock screen. Plus there is no guarantee that this method doesn't get broken at some point.