Recently I'm working on a mobile offline game based on Cocos2dx-lua.
I found an app on Google Play called GameGuardian which can set the time speed. The app maybe modify the method gettimeofday() in libc.so. I've tried many APIs such as os.time(), SystemClock.elapsedRealtime(), but all failed.
Could somebody please give me a way to avoid the effect of the app?
The only sure method is to make your app contact your game's server to ensure time. Many android games is doing that. "The Battle Cats" is one example.Say, you can check time validity as soon as app starts, and if no connection available, you can allow resources generated for some allowed time. Not more than 1 hour worth since last confirmed time, for example.
Other idea might be checking current fps. Hardware can't speed up, so frame will be rendered in roughly same time when VSync enabled. If you find that rendering single frame takes significantly more time than it should be, and if it happens for many frames, then it might indicate cheating possibility. But this is not stable solution, since you'll have to be sure your fps normally doesn't drop on weak devices, and it doesn't tell you anything about time spent while game wasn't running.
Extreme case might include complete erasing app's state if you find time jumped back since last saved unconfirmed time for more than ~1 hour (in case user adjust DST, etc).
But generally you can't protect completely offline game from time manipulations.
Related
I'm trying to return time in milliseconds between both iOS and Android devices. I was hoping that since most devices sync their time with a networked server, they would be the same. However, I'm noticing they are not precisely the same.
I'm using this method for iOS:
[[NSDate date] timeIntervalSince1970]
and this for Android:
System.currentTimeMillis()
Is there a better way to try to return the same exact time across devices? I'm noticing these values can be off from each other by up to 2 seconds depending upon the Android device.
The use-case for needing this synchronized time is to display a looping animation that is also synced across the devices. So the animation would need to start at the same time, perform its animation for a set duration, and then loop again.
Thanks for any help.
You'll never get exactly the same time. The problem is that clocks aren't perfect, and that they aren't always synched to exactly the same time source at the same rate. Even if you synch to the same time source, the latency between when they process update messages will make a difference between them. 2 seconds is actually pretty good.
Time is tricky. Take 2 devices in perfect synchronimity. Fly from the US to Europe with one of them. They're no no longer in synch, and both are right- the general relativistic effects of traveling at high speed means one is now several milliseconds older than the other.
Basically what you want isn't going to happen. You'll have to settle for close enough. Although if you post why you need them so synchronized maybe we can give you some ideas.
I'm looking to create a drum machine in ActionScript 3 (as an Adobe AIR Android app), which will keep to a user defined tempo (BPM).
I am struggling to find a way to keep the project in time, I have, at the moment, made it so that 5 different sounds are represented in rows of 8 squares, and the user can click each square to choose when to play that sound (hope this makes sense).
At the moment I am using Timer to keep the project in time, which is very laggy and inconsistent.
using timer is a bad idea for this, there I said it...
The issue is that the timer has a drift and fires several milliseconds later.
Try a simple test where you have a timer that executes every 500ms, and then compare the getTimer() count. What I have found in my experiments that the timer is continually off and it looks like it doesn't self correct. I've tried using a self-correcting timer, that changes the firing time based on the getTimer() difference since last run, but it's still not reliable. and anytime your processor's load picks up, the timer will be off anyway.
The correct way of dealing with this is to use byteArray data as a source for the sound. Based on the calculation of sampling resolution you can populate the stream with the data in advance, and the sound will play on time, pretty much guaranteed. I haven't gone as far as to create something that does this myself. But there are several libraries that you can utilize that can help you with this.
My top two decremented libraries are SiON and tonfall
you can see a sample of SiON here http://wonderfl.net/c/qf4b
and tonfall example at http://tonematrix.audiotool.com/
While I haven't tried them on android, I think either should work
Well i have successfully obtained the light value, however, it is EXTREMELY delayed. Approx 3~5 seconds even when using .SENSOR_DELAYED_FASTEST also even when entering 0 as the rate. Its so slow. I have the program check light sensor values upon screen on then change brightness accordingly HOPING it would solve the horrible automatic brightness delay. but after messing around with it, it seems to me that this is simply a flaw in android. It simply cannot update fast enough. I have used getDefaultSensor() but according to android documention this value can be delayed/filtered, but upon reading another post on stackoverflow the getSensorList() and getDefaultSensor() return the same values and that getSensorList() is no different than getDefaultSensor()
The reason for my question is: Is this correct? Is android simply a fail at updating immediatly? its funny cause my Windows MOBILE(not phone) can update immediatly and i loved it. but with all android devices ive seen its the same thing. so is this just a flaw in androids programming? Is there a way for me as an app dev to fix this? or do we have to live with it?
As I know you cannot get it faster. Please take a look on this question and answer: https://stackoverflow.com/a/5060690/1381641
I don't have the solution for your problem, but I do have an explanation for it. The Ambient light sensor has a delay because of the integration time downloads Sensor Box for android from the Playstore.
You will get the hardware ID of your ambient light sensor, then google search it, and you will get a PDF with technical details about that specific model number. Every Android or IOS phone does NOT use the same hardware.
In that PDF, you will get an integration time. It exists to keep the brightness control stable and delayed as well as sensible. If it is low, and you are in a disco your brightness level will keep on flickering. The same for outside, sometimes some shadows make it go up and down if the integration time is low. It will flicker more and will not be stable.
This will also cause harm to the backlight, so instead of taking single values they compile down the values of a big time interval. My integration time was 400ms. This value is sent to the processor, and then the decision is taken.
You could change this value. It is easy, AMD hard boh depends on your expertise like to update this you have to program the ALS unit by opening the phone, connecting a programmer to it, and connecting the pins in the right way. Then sending an 8 bit signal as mentioned in the PDF (if model is programmable).
I asked this question over in the Android Developer's user group, last week. Nobody responded, so I thought I'd ask it over here.
Does anyone have any suggestions about how to schedule video events to happen at an exact clock time? I've been thinking about an application that would require two adjacent phones to display the same thing at exactly the same time. I'm wondering what that granularity of "exactly" is going to be.
I've done some testing on a couple of devices and it seems that the delay between an invalidate and the subsequent redraw can be as much 16ms. Perhaps I can do better with OpenGL?
Ideas? Anyone?
OpenGL itself is capable of very high framerates (unless I am mistaken). What I can tell you is that plenty of games have been written to run and maintain 30 frames per second. That's one frame every 3.33ms. At that speed, the change should be imperceptible to the human eye, or so I've heard (the estimate limit is 5ms).
However, there is a major difference between what OpenGL can do, and what the device running OpenGL can do. Again, Unless I am mistaken, you should be able to instruct OpenGL to run at 200 frames per second. The caveat is that if the machine you are running the animation on can't handle that framerate, it will either frame-skip or lag, and in either case will hog the processor and GPU like no other.
Again, as I don't know the specifics, I can only guess, but I would think that this is less of an issue with OpenGL vs the other leading brand, and more of an issue of the devices you are trying to sync. With the right code, a proven framework, two powerful machines, and high-speed data transfer capability (read: LAN at the least), there is no reason why you shouldn't be able to sync up the video. If any of these things are not the case, all bets are off.
-Cody
I have a fledgling app under development, which I am installing to my Android phone via Eclipse debugging.
Now, my app is only 200KB in size at the moment, but it runs very slowly. I have a button in my first activity that drops 4 SQLite tables, with a combined total of no more than 25 records, and then recreates the tables and data straight away. To my mind, this should be a pretty damn fast operation, but it takes a good 4 or 5 seconds.
There isn't anything else going on at that moment in time, netiher in the app, or on my phone. I just can't understand how it can be so sluggish. I've even made the operation above an AsyncTask, and it's made no difference.
Also, when I go into my phone's Settings -> Manage applications, the list of all my installed apps shows that they're all "computing...". Every single other app finishes this a good 3 or 4 seconds before my tiny one stops "computing..." and displays the app size info, etc.
Could all this just be symptomatic of an app not having been installed via the Marketplace? Is it something to do with the debuggable setting in my Manifest?
I'm not ready to play around with signing and release yet, not by a long shot, so I can't test to see if that's the reason. Or can I?
I have a button in my first activity that drops 4 SQLite tables, with a combined total of no more than 25 records, and then recreates the tables and data straight away. To my mind, this should be a pretty damn fast operation, but it takes a good 4 or 5 seconds.
Writing to flash is not as consistent, speed-wise, as is writing to magnetic media. Brad Fitzpatrick, in the 2010 Google I|O conference, cited some tests he ran where writing a single byte to flash, while normally fast, could take as long as 200ms.
If you are not using transactions, things will be slower, because there is a flash write and sync on every database operation.
Beyond that, it is difficult to provide you with advice, particularly with no code to examine.
I'm not ready to play around with signing and release yet, not by a long shot, so I can't test to see if that's the reason. Or can I?
Well, you can certainly sign it. For release testing, you can put the app on a Web server somewhere that is set up with the proper MIME type (application/vnd.android.package-archive), or send it to your device via Dropbox, or something.