Maybe someone here had already done this before - I'm not sure how to solve this safely...
My client want a kind of in-app-purchase for an Android application. But that's only subsidiary - my problem is: there should be a kind of "rental" system. That means someone buys i.e. an item for a certain timeframe (i.e. 10 days). The App is only online when he buys that item - so I need a safe way to let this item expire offline after 10 days. If I use the internal clock, there are to much ways to manipulate this.
Any advice how I can accomplish this (relative) safely?
Thank you,
As it is run from an "almost always connected device" you could use an external source for checking the time ( and check it each time it use the rented item or periodically if you find it inconvenient),
It is how it is mostly done, and instead of relying on timestamp it relies on certificate that should be checked against a certificate server and is harder to tamper with.
Related
Background
The company I work for is creating an app that collects information from various device events and sensor data.
One of the things we would like to be able to do is use time to process the data when it gets to the server.
We would also like there to be an acceptable amount of "offline time" allowed, i.e., the app could be used for its purpose even while offline until the next server data update is required etc.
Problem
One issue is that the user can just change the device time.
We overlooked this, and have been able to successfully generate events for the previous day, which would mean that our app could be fooled in situations where device time is a factor, which is very uncomfortable.
Imagined solutions
Obviously I can ensure that the app is always sync'd to the server before it starts collecting important data, and then use server time and make all further time relative to that.
Another way might be to keep a reference to something like the last update time or even the app install time and work out time relative to that.
Questions
How do people get around this typically?
Are there any libraries out there that can be used to enforce real device time?
Thanks guys
In my app, I'd like to keep track of time away from the app, so that if the user is away for say, 2 hours, and come back, they receive 1 in game currency.
In practice I could easily do this by using a date object to get the current time in onStop, saving that date object, and comparing it to a new date object when they return.
However, I have a feeling this can easily be spoofed by change the internal date settings.
Is there a more secure way? Should I just put a cap on how many hours away you can bank up? I'd love some insight. Thanks as always.
you can try to make more secure code in the app, but the safest way is to request something from a server
if you are app is already using internet permissions consider making an HTTP request to get time.
look at this site for example
http://www.timeapi.org/
if you have backend to support your app that would be extra better
if you are not using internet permissions it might not be worth it to add it just for this, you might consider a different "offline" solution
Though as a beginner, I am trying to develop an android app which is story based, i will like to know the best way to serve content to the user, i mean like a continuous update of content, just like updating news by the hour. As users will install just once, how will they get the latest content of my news or story based app.
I have access to domain names and hosting if it requires uploading such content through a domain.
from your experience, what is the best method to achieve this? I humbly await a response, thanks
So given the clarification in the comments this is the answer:
The best way is PUSHING the content to the user's device.
Generally speaking, the two ways for a new content to reach an app are :
1.polling your server (or any third-party server) for new data every,say, 20 minutes. The disadvantage of this method is that it drains the battery. Every time that the phone connects to the internet, the radio in that phone stays on (or in a standby mode) for something like 2 minutes. Those modes (on and standby) drain the battery. Another problem is that it does use data needlessly and in some countries cellular data is expensive (Canada for example).
This could be a solution if the data changes very very frequently (for example a stock's price can change many many times a day). But generally speaking method 2 is the preferred method..
2.Pushing the content to the user's phone.
Your server will send a message to the device once new data that you want to send is there (and you could also put that data in the payload of the message if it's not too much).
This means that the phone will connect only when some new data is available.
Saves battery life,and gets the information as soon as it is available!
I recommend using GCM (Google Cloud Messaging) for this purpose which is free, and simple to use. If you have no idea how to do that in Android (which is likely since you said that you are a beginner), it is explained really well in Udacity's
Advanced Android App Development. It is a free course by Udacity and Google, but the section about GCM is only about 15 minutes long.
If you know how to implement a server but don't know how to use GCM in your server (and you don't find Google's documentation helpful) do let me know..
If you don't know how to implement a server...well then it's something you will have to learn in order to get your content to your users as that's the best way.
I hope this helps! :)
In my app I want to allow user to be able to use it for 7 days offline usage for free, but want him to connect online once 7 days are done and buy a subscription after that. So basically, I want to lock him out after 7 days from install. The problem is user can very well change system time and trick the app. Also, I cannot use server as the authority as the app is supposed to also work completely offline, except for the time of purchasing subscription.
I can run a background service to keep track of any system time change but I want to avoid doing that.
Is there a straight forward solution which can work even if the device is totally offline for 7 days.
You can save the current time in shared preference and compare it every time you sample it. If you get an older sample the user changed the time backward.
Use remote clock , for even simple read the time of server from mobile in desired time gap and use those number for your app's clock
So this is how I am planning to solve this, though this is not unbreakable but will work for majority of users.
So while signing for trial I get network time and store it as start_time in preferences. Next on each app start and app resume I read the current_time and write to prefs. Once current_time of pref is greater than time of device, we lock the app. Once preferences are not there we ask user to come online as suggested by #Zach
To make preferences editing a little inconvenient to the rooted device guys I am storing data in encrypted form in prefs.
This is still no way unbreakable as one can decompile the apk and read the obfuscated code to guess the algorithm and the key but I guess the value of content in the app is not that high for someone to go through that much pain.
can add syscall and track the time offline, get it from here
I am making an Android game. So, people are able to create groups/parties between them and I would like to give them the ability to view each member of their group moving on the Google Maps in real time. This means that I have to find a good way to update each client’s map markers in real time or pseudo-real time at least.
Would an approach with a DBMS be fine or that would be too costly? In this approach, every client should be responsible to update the DB every so with their current coordinates and thus everyone can make queries to view every other party member's lastly updated location. Making this happen within small time intervals will give the feeling to users that people are moving on Map in real time.
On the other hand, would a peer-to-peer approach handle this case in a better way? Like every group/party runs on its own by letting players exchange info between them containing everyone's new coordinates every so (interval). I believe that the second approach is better because it does not give load to our server, but there may be drawbacks. I am not sure however how easy this would be to be implemented and if Android API provides something good for this case.
Any opinion/suggestion/comment is very welcome. Please I would like to hear what you are thinking, since I have no experience on this subject and hence anything might be helpful.
Thank you in advance! Please enlighten me :)
Since the options are all a bit "costy" in terms of connection/operation, i would suggest you to check at the MQTT protocol. It's used as M2M connection with an eye to optimization. It was created for Internet of Things purposes.
I've used it for non-android projects but it can be used also for that.
You only need a server (broker) and i suggest Mosquitto (which is lightweight).
Then every one can subscribe to a topic like: "/location/update/+" using + wildcard means every topic that is one level after "update" topic.
Then every one publishes his own position to the topic "/location/update/{MYID}" and the others will receive the position.
Usually the position are retrieved only when connected, but you can manage to support a sort of "hanging" subscription by using QoS=2 when subscribing and connecting always with the same ClientName.
Does it help?