I need to do a study of what apps are actually used among a group of test users taking part of an experiment. I would like to know the time each of the random 3rd party apps have been used to do statistics on it. If possible, I plan on distributing an iOS app through TestFlight. My app will gather the app usage statistics and send it to my server.
The overall goal is to get total usage time for each installed app on a daily base from each of the users taking part of the experiment.
What I have:
One of my ideas are to develop an app that will use the VoIP backgrounding profile (or similar) to run in the background and periodically (like every 10 secs) log the name or bundle identifier of the current foreground app (if any).
I have found a method to get the current running processes: Can we retrieve the applications currently running in iPhone and iPad
The method described in the above post gives a struct kinfo_proc that includes other structs with information such the process name, priority and running time (including time spent in the background). I have not been able to identify a flag revealing what process is in the foreground. Also the priority does not seem to be a reliable indictor. Something I'm missing here?
The above method can be used to get the current running time for a process, but as each app can be sleeping in the background for days (or weeks) this is a poor indicator for how much the app has actually been used. If I could kill all the running user installed apps every hour or so I could get an indicator of how often apps are used. The most used apps would be cold-started by the user more often. But that would give an unpleasant experience for the testers as apps are killed randomly. But anyway, is there a way I can kill another process?
Another idea is to traverse through the view hierarchy to probe the label of the leftmost app in the task bar. Any ideas of how this might be possible to hack?
I had another idea of analyzing device logs and gathering app usage statistics that way. However it seems that app background-foreground switching activity is not logged to the system console. Is there some other logs containing this information or can I get it somehow by enabling energy diagnostics logging?
If I had my test users set up to use Apple Mobile Device Management (MDM) would I then be able to collect the information I am interested in?
Any ideas are very much appreciated.
A few notes:
My test users does not have jailbroken devices, but I can use private APIs as I am not distributing through the App Store.
I would use an analytics tool like Flurry Analytics to get the data concerning usage statistics, which you could then download into your app using their API. They can get you very details stats on how your users are using your app, how frequently, etc. It's a great tool, plus it's free!
Related
This might be asking for the moon but here goes...
Is it possible to have an iOS app receive data and then forward it all while running in the background?
We're a restaurant currently using an ordering system that uses a main iPad as the till, with a second iPad in the kitchen to receive orders, and another third iPad used by the servers to take orders. Orders are sent to the main till which relays orders to the kitchen.
Works great... Unless someone switches app on the main till iPad to our other (necessary) hosting app, then all hell breaks loose and all orders stop getting sent.
Developer (small team) has told us it's impossible to solve but I have done some digging into recent Apple APIs that allow simple tasks to run in the background and have seen a few promising options, or perhaps it's possible via the External Accessory Framework, or even syncing via iCloud? A question for the more knowledgable than me, but is there currently a workaround to solve this that I could suggest or are they right in that it's currently impossible in iOS?
Yes there are ways to have an app in the background receive data, generally using either:
beginBackgroundTaskWithName:expirationHandler:
or
beginBackgroundTaskWithExpirationHandler:
Take a look at the Background Execution section in the documentation for more info...
I work as a software developer, but I am absolutely new to Apple in general. We have the following case in a project, and we have not been able to figure out a solution for it, I would really appreciate some advise to find a solution (or drop the case if not possible)
A (potential) customer with multiple retail stores is interested in having a very simple app to display some content (this could an image or html, nothing too complicated) and periodically update this content from a server (this requirement is important). So it is very simple case, to use the device screen as advertising space
But here is the catch, users should be able to go out of this app and check out the device's system and other apps, and then the content should come back on the foreground when the device is idle. So basically we need something like a screensaver app that fetches the content (images) from a server and keeps them updated.
We have been looking at the guided access mode, but we are not sure it fulfills the requirements, because of the following issues
- Allowing the user to check out the device system and other apps. As far as we understood guided access restricts the device to one app.
- Re-launch the app (or bring it to the foreground) when the device has been idle for a period of time.
Note that we should account for a variety of devices (iPhone and iPads) with different OS versions
I appreciate your help and ideas. Thanks.
Apple does not allow apps to run continuously in the background except for a small limited group of exceptions. (music playing apps, for example.)
It's possible to set up your app to pretend to be a music playing app, and stay running in the background, but that means you will not be allowed on the app store.
Your client may be able to use the enterprise program to create apps for use in their retail stores. Enterprise apps don't have to go through the app store approval process.
I did this for a client recently (for an enterprise app.) As I recall I would have the app request background processing as soon as it moved to the background, and when it was notified that it's background time was ending, I would play a short "silence" sound and request another block of background time. Unfortunately it was work for hire and the contract ended, so I did not retain the source code.
I want to develop an iPhone application which can track the contents (such as location information, device hardware/sw information, contacts …etc) being collected from your device by all the applications and give a report to the end user at end of each week.
Because, I believe that end user should be notified about what information being collected by his device and sent to which servers to store them.
I Googled it and read few articles as well, but all pointed to the conclusion that a given application cannot (or restricted by Apple) peak into operations of other apps and collect any information about what those applications are doing.
But I've seen this Onovo Count app http://www.onavo.com/apps/iphone_count is collecting the data usage of all the other apps in your device, so can we just go few steps beyond that get this done ?
From the looks of it Onovo Count redirects all device traffic through a VPN. I presume their servers look at the host names of the traffic and record it against the device. When looking at the app, you're just looking at a dump of the data for your device.
For the rest of what you want to do, it is not possible on a standard device, you'd need to have it jail broken or something.
I recently came across an app in the app store called Dataman Pro. It has a feature that lets you see the data usage per app basis (see the attached screenshot). I have been wondering what is it doing to get this sort of information.
See this post about getting the list of installed apps, and this git project.
Then about usage tracking:
If you wondered about any public APIs that give you network statistics out of the box - there's nothing there.
DataMan it self is an app that used to work in the background all the time, and bind to the network interfaces to track network usage. Which is one of the reasons that its data is never 100% accurate as it is not guaranteed to always work in the background. This is also the reason Apple kicked it from the AppStore after a few versions...
Now that app has returned, if I understand correctly, after making a few changes: Mainly avoiding "hacks" to stay in background, and using Location Services to get back online when the user moves around. I guess this is another hack but one that Apple did not oppose to, yet.
Edit:
After looking around the web for a bit, it seems that Apple found that trick also, and removed many apps from the AppStore due to staying in the background by using location. I guess right now it's not working more than 10 minutes in the background, so you open it when you want to measure current Activity, and it stops measuring after 10 minutes.
About the tracking code itself, its mainly C code, using CFNetwork framework, and you can find some answers on stackoverflow on this subject.
More, in response to comment:
Well, the part about seeing the installed apps list, and foreground app, is not exactly private APIs, but private plist, as you mentioned.
Apps which access private files do get through from time to time. When Apple finds that some "private" files are accessed and need to be kept safer - they change it in an iOS update, like they did with the call history file, which is sensitive. Old apps tended to use (around iOS <= 3.3) the call history db to do some stats, and on iOS4 they were obsolete by the file moving to a secure location.
Reading "private" files which are unprotected is pretty easy to do without getting caught by automatic analyzers.
When you know which is the foreground app, and you can count current network usage, you can associate it with the app... And get an estimation. So this is how they do it, most likely.
However, The techniques change from time to time, due to Apple re-reviewing apps and their own policies, and due to API changes, and if you track the history of such apps and even this specific app - you will see that from time to time they get kicked off of the AppStore and return with a twist. They adjust... So no technique is reliable and this is a major headache to maintain, which is probably why the developer charges 9.99$ for it. I would.
I have an app where the requirement is to view all the user-initiated apps, which can be terminated. I tried searching, but didn't find a way to proceed. I am able to get all the processes, including system and user processes,b ut I need to filter only the apps which can be terminated. One way I found could be filtering based on pid, but I am not able to distinguish between pids of user and system processes.
With Apple's SDK this is isn't able and such an application wouldn't get through the approval process of the AppStore. You will need to use a jailbroken iOS device for this kind of job.
Anyway I'd recommend you not to investigate in managing applications manually, since iOS makes a nearly perfect job there already.