I have googled, but I can find no advice to prevent user change system date/time in android.
We are developing an Enterprise Application, we would like to prevent the user of the device to be able to set time settings. In other words, we want to set a policy which defines, that user cant change date and time in android device.
Are there any recommendations to do this?
Thanks.
Here is a third alternative that should significantly save on battery life:
Register a BroadCast Receiver for when the time gets changed by the user. Then disable the app until the device time is checked against network-time or server-time.
Those Broadcast Receivers exist. I just checked now with this app called Internal Broadcast Monitor I just found on Google Play.
Here is the interesting part below where I changed both the time and the date:
And below is the part where I changed the time zone:
.
Since there is no policy support for this in the device administrator framework, you can't. File a feature request, it might get added in a next version.
I don't know of any way that you can change the default behavior of the device.
You can however prevent your application from running if the system time differs from the network time. Or you could use the network time in your app instead of system time.
The answer to this post explains how to access the network time.
How can I get the "network" time, (from the "Automatic" setting called "Use network-provided values"), NOT the time on the phone?
you can save current time to db when application start and check every 1 minutes if current time not equal to db time+60 set system time to db time+60.
Related
I'm wondering if you can launch a given Instant App based on the user's location. Is this kind of thing possible? I suppose it would require some kind of server to be always running on the device.
Edit: To clarify a bit, this would be like if App A has a service that tracks the user's location and if they go to a certain spot it would launch Instant App B.
Thanks!
it would need a constant running service and launching the app might be a problem since this particular function could be ransomware like but a notification could be instead that's.
beside that it would a continuous location request at all time.
I am developing an Android application and I am planning to release this build in “Open Beta” on the Google Play Store.
I want to implement the app security logic which can ensure that the beta build won't work after certain date dd/MM/YYYY.
Currently, I can think of two approaches for this logic:
Retrieve current date from the device (using Android code to retrieve system’s time)
Issue: User can change the device date to hack the security system
Use time server to check the current date
Issue: My application don’t need internet connection and hence it will be bad user experience if I am asking for internet connection at the start of the app
I have following questions:
What alternate approaches (other then checking dates) can be used to ensure that the app won’t work after date dd/MM/YYYY?
How can I detect that the user has changed device date manually?
Other approaches to find current date even if device is offline?
EDIT:
The beta build has all the premium features free and hence I don't want beta build to work after date dd/MM/YYYY.
NEW QUESTION:
I have implemented the code to check the real date using time server at the start of the application. What possible hacks can be done by users to access app after the date dd/MM/YYYY?
Thank you in advance.
Agreed you don't wish the device to be dependent on the internet. At some point however, the device will be online (A human will never leave his/her device offline since the installation of your app). At that point you check the time stamp and proceed from there. You could disable the app or perform any action. Many apps exhibit this behavior to run an action when and only when the net is connected.
Other than the net and device clock the only other final solution you have is to run a background timer from the moment the app is installed. Good luck
The new Permissions model includes "Internet" as default (you don't need to request it specifically anymore).
If you don't want to use internet you can use following idea. Get current timestamp when running application first time and save it preferences or in external storage. check current time stamp with saved timestamp every time user launches application. please check for negative values to prevent user setting previous dates.
You can check the date, and at the time that the date exceeds the deadline, you can save a variable in preferences, so that when you enter the application, even if they change the date, the application will detect that date been exceeded.
I'm looking in to the capability of locking out a user from using my application further. Let's say your app will run for some time, and after some event (time expiration, # of app starts, etc.), you want to lock out the application, or brick the app in some way that it can't be used anymore
I've considered storing a piece of data either as an internal file, or as a shared preference value, that would track when the event is hit. The issue here I believe is that the user can go in to the OS and simpy clear the data, which would erase the progression to the lockout event.
Does the community have any suggestions of being able to lock out a user that can't be circumenvented, and doesn't require a rooted phone / unique ROM image? I am targeting Android 4.0+ if necessary, but currently have min SDK of 11, and target SDK of 15
I did this in an early beta by checking the date, then after the specific date, displaying a message saying it had expired and doing a divide by 0 error.
For a specific time after they have installed it, you will have to use an online service, or try and hide a file on the SD card (not guranteed to work at all).
I have a Bike computer app that logs data while the user is riding. I have had a user report an issue I had not considered. He was out for a long ride (100+ miles) but while out and logging data the app got updated via Google plays auto-update. This unfortunately killed off the app mid recording and the user lost data till they spotted what had happened and restarted the app.
Ideally I would like to be able to programmatic stop the auto-update happening while the app is data logging. All my research indicates that this is not possible possible but I may of missed something so dose anyone know of a way of doing this?
Given no solution the best I can do is advice the users to enable the update only over wifi option in the Play app which in this instance would of helped. Unfortunately one of the key points about my app is that it will log indoor sessions using ANT+ sensors so I have a good number of people using it with wifi active.
Edit
I managed to do the experiment to see what happens myself last night. I had an app going in the background data logging then pushed a new version to Google Play. Unfortunatly it was not picked up totaly automaticaly when I had to leave 10 hours latter but I opened up the play store app and it found the update it did not start updating automaticaly but I forced it. The act of downloading and installing the new version killed off what was in progress. It was already dead before I used the notification to go to the new version.
As you say yourself, you can't do that what you are asking for. You could hack your way around it by changing the permissions each time you update. The users will then be prompted about it in the regular way.
I'm not sure about the "life-cycle" for automatic updated apps that are running. But I read somewhere that is wasn't the re-install but the reopen of the app that crashed it. If that is the case you could set a flag indicating that the user is currently logging and then on restart just resume the logging. But again we need to know more about the inner workings of activities/apps which are running and get an automatic update (actually didn't think it could happen).
Edit
Based on your findings I'd say you have to handle the app is shut down in onDestroy etc. or/and make sure you save everything persistently. Then you might need to have 2 apps where 1 listens to the other being re installed and when that happens it starts it up again (there is an interesting discussion here). If you are targeting api >= 12 then the broadcast action ACTION_MY_PACKAGE_REPLACED might also have interest.
Is there a way to get a system notification when an app has been uninstalled?
I would like to maintain a table of all clients' info currently using my app. However, that seems impossible if there is no way to detect this event.
The first solution I can think of is to have an always running service in the background listening for android.intent.action.PACKAGE_REMOVED. But then would that service be killed once the uninstallation process has ended, or would it be stopped just before the process has kicked off? Also even if this is a solution it's has the potential to put off a lot of people when they realise that part of the app is running in the background.
Any suggestions? Thanks!
You could simply do it the other way round and maintain a table of users actively using your app. Just call a webservice at a point in the program that show it is active. If an app isn't used for a certain time mark it as inactive.
The documentation for the PACKAGE_REMOVED action says the following:
The package that is being uninstalled does not receive this Intent.
So you can monitor for other applications being uninstalled but not your own.
So you'll probably need track who is still using your application, not who has stopped using it. If you don't want the overhead of having your own server to do this you could use a free service like Flurry.
From Android document, the app uninstalled by user can't not get
Intent.ACTION_PACKAGE_REMOVE
But we can use other method to implement this feature. We all know that there is a directory named with your package name under the /data/data directory after your app installed by user. If your app is uninstalled by user, the root directory of your app(/data/data/com.example.yourappname) will be removed by system. The remove action happen immediately when user click "uninstall", and the directory will be removed by framework package manager system.
So, we can monitor the existence of your app data directory(which usually /data/data/com.example.yourappname) to detect if your app uninstalled by user.
In order to monitor this directory, we have to fork a detached process from JNI.
In this new fork process, we can use Linux system api inotify(7) or access(3) to determine the existence of app's data directory.
Here is a workable implementation. But it got the permission problem when try to send an intent to start system browser on high version Android device. I have no idea how to bypass this. However the example above is enough for your question.
Hope it will be helpful!
Android doesn't provide an inbuilt function for tracking the app uninstall.
Notification can be used as an alternate way to track the app uninstall. For this send notification on the app and track the status of the notification. Count the number of undelivered notification for a particular time period. If status of undelivered notification doesn't change in that particular time period, then consider that the app has been uninstalled from the device.
For example, i have used a cron script which run every 3 days and check the status of last 10 notifications delivered to the device (2 notifications are sent in a day). If all of these 10 notifications have status "undelivered", then the app is considered to be uninstalled from the device.