BACKGROUND:I'm in the process of writing a tasker application that tracks usage of other apps--it keeps track of the time that a reading app is open, for example.
In order to make sure that I'm actually reading and not just leaving the reading app open, I want to make the display timeout 30 seconds long.
ISSUE: The reading app locks the display so it never times out. How can I override the reading app settings to make my 30 second timeout take precedence?
I can't find anything out online because everyone is trying to do the opposite. However, everyone else's Tasker timeout seems to avoid conflicts naturally, so I'm not sure why mine is having issues.
Pseudo code:
Event: Reading app is active AND display is on
Start time = current time
Timeout save = system timeout
Display->display timeout->30 seconds
Event: Reading app closes OR display is off
Total time += current time - start time
Display->display timeout->Timeout save
have you tried with Secure Settings plugin?
it does have better than Tasker control over some of the OS parameters
After extensive research, I have found that there is no way to override the setting. (At least not for the beginners like me)
Google briefly made it possible to override app permissions in Android 4.3, but soon took that privilege away in a subsequent update. Pity.
A cheap and dirty workaround that I came up with is to have a small dialog in a corner with a timer that counts down for your screen timeout. In the last 10 seconds, a button becomes visible which resets the timer and hides the button, or else the display is shut off. (This works for the purposes of MY app -- My intention was to make sure the user was interacting with a third-party reading app, and not just turning it on and walking away, as my app counts the amount of time the reading app is open and the display is on).
#Tomaski - Unfortunately, the Secure Settings plugin doesn't have this power, although you are correct that its capabilities are greater than vanilla Tasker's.
Related
Google Analytics (using iOS SDK version 3.14 and it's built in sessions tracking) is reporting a significant percentage of app sessions as 1 second.
Maybe users are launching an app to view a page and (effectively) then instantly leaving the app, but that seems unlikely (that it should continue as the top use case. You think such users would stop using or uninstall.)
Initially I suspected this was related to "background fetch" but when I look at a prior incarnation of the application (that did not have background fetch enabled or used) I still see these (seemingly) bogus sessions also. That application (pre iOS9) had no universal links.
The (obvious) reason I don't want to see these sessions (especially if from automated action not user action) is it removes all value of "user behavior"; i.e. loyalty, recency and skews "average session length". These are the main reasons I want to use GA, i.e. to see if folks are using it more/valuing it more.
My questions:
What might these sessions be caused by? Are they bogus?
If bogus, how can I stop them?
Can I ensure new "background fetch" code doesn't somehow trigger them?
Some things I've considered / looked into:
I am seeing a similarly large set of "short sessions" on an Android application (this application's peer) and again with extremely high numbers. I've been wondering if this was a result of a web searches & site links, with those site links automatically loading the app, and the a (very) quick user "move on". (Universal linking is something the new iOS application is working towards, but doesn't see much of yet.) Given it is not that on iOS I am starting to doubt that it is that on Android.
There is a "optOut" option on GA. That feels like a sledgehammer solution to this walnut problem. It is also a persistent setting, which feels risky to use for a transient situation. I could attempt to toggle it at applicationDidEnterBackground / applicationDidBecomeActive (and will if it is deemed the solution) but worry it could have negative side-effects.
One can have multiple trackers. I am planning to attempt one for human foreground activity and one for background operations (which might allow time /event tracking when in background, w/o impacting human user tracking numbers. That said, I don't know / believe this is the cause of the bogus sessions. )
One can manage sessions manually and also customize the sessions interval timeout, but I don't see why this application should need any custom behavior. It is a normal application.
The application isn't reporting crash totals to match these numbers; it is a generally well liked 4/5 star app w/ few crashes.
Google Analytics measures duration as the time between interactions.
This means that in order to be able to measure duration, Google Analytics needs a minimum of two interactions to measure between. But they still need to collect data on one-interaction Sessions, and from the reporting perspective, every session starts the same - with an interaction. It's just that some don't go any further. To account for this, Google Analytics keeps a running total of Session duration.
When a user first interacts, that total is set to 0.
31 seconds later, they interact again. That total is updated to 31 seconds.
10 seconds later, they interact a third time. Total is now 41 seconds.
35 seconds later, they quit. This is not measurable, and hence not an interaction. Google Analytics waits faithfully for 30 minutes, before deciding that they aren't coming back.
Your total Session Duration is recorded as 41 seconds, as that was the last point at which you checked in. There's no way of knowing that you stuck around an extra 35 seconds.
This isn't an issue if you looked at 4 or 5 pages, but if you had only looked at 1 page, we would have been left with a Session Duration of 0. This is what happens with every 'Bounce'; every Session with only one interaction is measured '0' seconds long.
Throw into that a handful of people who interacted 8 or 9 seconds later, and you have an average of 1 second for the '0 - 10' category.
Turns out the problem was inside the Google Analytics SDK. A new version has been posted:
[Google Analytics SDK issue with short sessions][1]
Some background on my application: I am developing an app that will be used by a small user study group. They are to go through two separate short questionnaires throughout a day. Within a day I schedule seven notifications to fire. If a user clicks on a notification they are taking to complete one of the two survey types. Each notification will be cancelled within 3 minutes of it triggering. If a user does not access the notification within that time, then the app records that a notification has been missed. There is also bedtime function (user receives no notifications) and a delay notification function for notifications that are currently triggered.
I add local notifications with this plugin:
https://github.com/katzer/cordova-plugin-local-notifications
So on to the weird issues... I have been debugging my PhoneGap application religiously for the past two weeks and everything seems to be working perfectly when I debug the application in Eclipse with my phone. A member of my research group says that he sees certain GLARING bugs in the application when he runs my release, but I have could not reproduce them while debugging in Eclipse. I figure he is using an old APK and doesn't know what he is talking about, as I had already fixed the issues he was mentioning...
Then I unplug my phone and carry it around with me for a day and all is well until the next morning when an alarm is scheduled to go off and wake me up. I hear nothing, so I continue sleeping. When I eventually wake up I see that I have a stack of 3 notifications in my status bar, all of which cancel at the same time about three minutes after I wake my phone up... I should mention that for the sake of debugging, I increased the number of surveys a day to 50, explaining the quick succession of notifications.
Now I've recently come to the conclusion that this is an issue with how Android conducts memory management-- Android will kill low priority tasks, such as the javascript timeout functions that I have running via a background-mode plugin
background mode plugin I use: https://github.com/katzer/cordova-plugin-background-mode
It turns out that , for Android, this plugin only enables/disables a flag that tells Android not to kill the process... however for the sake of memory management, this flag is overridden and the js functions running in the background of my application are killed... this explains the previous strange behavior.
However, there a couple other odd things that only happen to my app when running it in release... If I delay a notification (cancels current notification and adds another one ten minutes from now), sometimes the login process screws up, requiring me to login twice at a minimum. Sometimes the login procedure just repeats itself over and over again, taking the user to the main menu then sending them back to the login screen. Other times I cannot log in at all... However, if I keep trying to log in, it will eventually give way and I can get in, but only after quite a few tries...
I have been through my code very thoroughly and there is no way that my code would result in this sort of behavior... What I am wondering is if this memory management issue mentioned above is contributing to these strange states of the application? Why does this not occur when I debug within Eclipse (This has never happened when debugging)?
I have no experience debugging issues with memory, but this is the only explanation as to why my code is acting so strangely...
I can post code, but I don't know how much use it will be... Really I just want to know if this sounds familiar to anyone who has experienced issues with Android managing its memory.
I've been in contact with PhoneGap Support and they have this to say,
"I talked to our lead Android developer on our team and he had this to say:
"Yeah, this guy is going to get garbage collected if he leaves his Cordova app running for a long period of time. We allow apps to run in the background for short periods by default since this is what people expect with the Android life cycle, but anything not on top of the stack is low priority, and you will need to implement a background service to do what he's wanting.
As far as running on Eclipse, anything with a debugger attached will be kept alive, because the debugger is a system process and has higher priority."
Al"
I am creating an application, which will save the current time (with some delay eg. 2 hours) in file, when the user presses a button. Later on, the application will check if the time has passed and do some stuff...
So... I click button in application (time gets saved in file)... I quit application... shut-down phone... I turn it on after 1 hour, get back to application... and I will still have to wait 1 hour until the application will let me do "something"...
QUESTION:
Is there a clock that cannot be changed by the user and keeps running when the device is turned off? I'm currently using SystemClock.elapsedRealtime(), which works fine, because even if users change the time in settings, elapsedRealtime stays the same. The problem is if the device gets turned off, because at every boot elapsedRealtime starts with 0.
I cannot use server time because application will not be connected to Internet.
If there is no such clock, please suggest me another solution.
actualy, you have no chance to get "off" hardware clock data. hardware clocks was just on older phones in the new phones i think nobody need it so they dont build it in hardware. In the old phones there was "hardware" clock but in the new device is nothing like that i think. I did read something about that google want to make some framework or what to implement it. But there is no alarms what are able to start in off mode.
So i am sorry, but i think it is not possible right now..
You could store your time in a database as a DateTime value, indicating Year Day Month Hour Second Millisecond, then you could request for a service to start on boot and read that data creating an alarm that triggers in the remaining time. I would give you a code example, but i'm not really good at java programming so it may be useless, anyway goodluck and try to implement this.
You obviously need to save your data to non-volatile storage. When your app is paused/destroyed by the Android, you should take it as a threat and save your time values to the disks, and then when your app has started again your app should read the data you have written before and keep on running as it would normally.
Well when it comes to question how:
the simplest solution is to use SharedPreferences,
the more complicated and the more flexible one is SQLite Database,
for more data on Android storage I will suggest: Storage Options
My app will have a 'clock in' in the listview. As a user will click that item it will grab the time/date from the phone itself and send that data out to the server. I prefer doing this over using server time since if they dont have a signal/reception they wont be able to clock in. I would like to add a password security to the time/date settings itself so the user wont be able to take advantage of changing the time when clocking in. How can I make that happen?
Thanks
I don't think you can do that, but you can cross-check the time.
When you "clock in" also open /proc/uptime as a text file and read the value there. I believe it is in seconds. When you clock out, re-read the value and use the difference as a cross-check. If a server is also available, check the time from the server too (or report the clocking in immediately)
If the phone crashes or is powered off in between, the difference in uptime could be less than what you've recorded via the ordinary clock. In that case, the difference in uptime might be less than the ordinary clock (likely it will be negative) so if your clock-in was done without access to network time your software may have to have a way to report that particular result as unverified, and track the number of unverifieds per user to flag for human review if it becomes excessive.
A user could conceivably compile and install a kernel that lies about uptime, but that person could probably get around most of the other things you would do, too.
I would suggest to just send message to server "user X wants to clock in". And server will use its local time for "clocking in". This way you will completely ignore device's time, and have more control over your infrastructure.
In general, if you want something to be as secure as possible, don't do this on the client side (unless you absolutely have to). And in this case user may gain root on his device and use some command line magic to fool you server with fake date/time. Its not that hard. And you just won't be able to predict all the smart workarounds of you "time protection".
You could set up a service to run every minute (or so) that checks the time. If the time is not ~1 minute after the last check then it may have been changed. You should confirm with the server at this point to make sure the discrepancy wasn't caused by rebooting the phone.
If you find that the time was changed, you can change it back or log this with your main application and flag the "user" for disciplinary actions.
Hello
In my android application i would like to get Time since when the app is opened.
Initially what i tried was getting the time when the app is loaded from the server and then taking the difference with the current time from the device.But by doing that if the user changes the time then i willnot be getting the actual time.
Its not posiible to hit the server again for the same.
Is there any way to achieve this in android?
Please share your valuable suggestions.
Thanks in advance:)
Try the "SystemClock" class, "uptimeMillis()" method.
Store the result in a variable when the app starts.
Echoing what I said for your other question, you first need to become familiar with the activity lifecycle and understand the novel meanings (almost meaninglessness) of common words like "open" and "start" in the life of an android app.
There isn't any way you can prevent the user from changing the system time - you just don't have the right to do that to users. Normally this should be a rare event, unless you do something that makes them want to, such as lock them out of a free version of your app after so many minutes. (However if the phone is on a mobile network, presumably the mobile network occasionally adjusts its time to correct for errors in the device's oscillator, or administrative time changes)
What you can do is check the system time on every entry point to your application. If it ever goes backwards, well... something is going on. If the clock has been set back, you could assume no time between the calls with the negative time difference and resume your time meter from there, at least keeping all the previous used time in your record.
It may be that there are cpu cycle counters which you could query and correlate to system time, but this may be highly device specific and may in fact be resettable. And it may get weird if the cpu frequency is demand throttled.
You might be able to set a countdown timer as a bound on the maximum possible time between entry points at which you could meter. I don't know if these work reliably across system time changes or not - ideally they would. Testing or reading the source will reveal.
Use elapsedRealtime in your onCreate() store it. More reliable.