I am writing app to monitor data usage by other installed applications. By far, I managed to get data usage through mobile and wlan interface. It will be pretty useful if I could track GPS usage per application (or UID). I dont know how it will be presented (time on "fix", number of requests?).
I can't find anywhere how to get that data. Does android save logs from GPS somewhere I can read them?
As #CommonsWare indicated in the comments, there mostly shouldn't be a way to access that information for application privacy reasons.
However, a question similar to this was asked on another stack exchange website and the solution was to try using an application called Spare Parts.
I am unfamiliar with the application, but I suspect you will be unable to access this information programatically. If all you would like to do is to see this information, this should do nicely. If your intent is to create some logic based on GPS usage, you may run into a little more trouble.
Related
is it possible to retrieve all the data that the app has accessed in your phone and print it out? For instance the app retrieve my imei, my location and I would like to print it out to a log, like imei:123456789, location: 40° N, 74° W.
I know that in xprivacy it is possible to manually check what have been accessed and restrict the access to some information. But I'd like to know if there's an app or an alternative already to export the data in that matter.
Thanks and happy new year.
Not really. Technically, there are a couple of ways you might get quite a lot of the information, but they aren't very practical.
For example, if you had sufficient privileges, you could monitor your app with strace. This would catch kernel calls. The kinds of data access you're talking about would all involve system calls. Or you could straight up debug an app and gather information that way (not at all practical).
Making that information available constantly would kill performance, so it's not something you can get at normally.
I'm currently developing an mobile application and rest service. The mobile application executes lots of calls to the service even if no update is required and data didn't changed. In order to remove this overhead of rest calls I'm planning to implement GCM (Google Cloud Messaging).
My strategy would be the following:
Load all required data on application startup. When data change was recognized on server side a push notification will be sent via GCM to affected devices to make partial refreshes of data (via specific rest calls). Advantages of this would be less overhead at service side, because there are no unnecessary rest calls and a more fluid user experience in my opinion. Disadvantage is that the app is dependent on GCM Messages and that they arrive in time.
I'm unsure if this is the right strategy for this. Could someone maybe point me in the right direction and tell me if this is a good practice?
We could use more information before answering details...
I'm unsure if this is the right strategy for this. Could someone maybe point me in the right direction and tell me if this is a good practise?
I will consider for the sake of giving an overall answer that:
A - User is not always with the application "online", neither has network, not even a desire to have updated info at all times.
B - User is eletronicaly litterate enough to understand difficulties with the program.
With those in mind, then what would be a good approach is:
Poll relevant data, store them locally. At this stage, one would consider the relevant informations that user would have and store them, with a date flag.
Once a flag goes "old" (below your threshold), re-query that data.
Operations follow 2 directives... When observing a data, check its state, show the user if its recent or not, and if its not, poll it. If it is, if the user selects operations on it (POST mostly), re query the data.
This way, you have no static overhead, if users dont have the app on foreground. Also, should they use your "always online app", they understand that network is a necessity.
Is there any way to identify that a Voip conversation is happening in android?
I have an app that needs to know whether any conversation is happening now through Voip. Never mind if it's Skype, Viber, WhatsApp or whatever.
I know that there are many different protocols for Voip, some of them proprietary. But I wonder if there is some clever way to do it.
Profile the bandwidth.
Find an API that lets you monitor incoming/outgoing bandwidth on a per-application basis (I don't know android but this is possible in windows and unix)
Check each application and write heuristics to classify their bandwidth usage
VOIP will have significant pattern, You'll have to watch it, but it will intuitively look similar to this
consistent amount of data being sent or received (note: test this with several VOIP solutions, and scale it - compression may vary)
usually doing mostly sending and mostly receiving (one side talks at once while the other just sends Acks)
sending and receiving swaps at a known interval (like a conversation)
maybe write a neural network if you have hundreds of recordings of conversations/non-conversations/borderline to train it with.
Etc ... you get the idea. Google 'detect a conversation' for more (couple good studies near the top). Note these portend access to the data stream; you will only be able to see data usage unless the VOIP is stupid enough not to encrypt or somehow let you MITM them.
Notes:
if something other than a conversation is going on, or there is noise, this may fail
no program has to identify itself as VOIP. Assuming you're monitoring employees they could download something obscure or bespoke to fool you. And data should be encrypted. So this is your only hope.
Possible to fool this by faking sending extra data. Not likely ... why would a program waste bandwidth?
If the users want to fool you into thinking they are talking - e.g., they are your telemarketers - why not mandate what they use? You would probably want to anyway so you can record for legal purposes.
Here is the code that will give current running application
ActivityManager manager = (ActivityManager)mContext.getSystemService(Context.ACTIVITY_SERVICE);
List<ActivityManager.RunningAppProcessInfo> tasks = manager.getRunningAppProcesses();
Log.i("current_running_app",tasks.get(0).processName);
You can detect incoming calls using this:
http://karanbalkar.com/2014/02/detect-incoming-call-and-call-hangup-event-in-android/
I also found another SO answer that maybe can help you:
https://stackoverflow.com/a/22904362/1723525
Using the SipAudioCall.Listener
I'm trying to make an Android app where I need to determine what kind of service class is using a phone, meaning, I'd like to know if the data connection is used for streaming, e-mail, chat, downloads, conferencing...
How can I do this?
If this is something you absolutely had to do, here's where I'd start.
There is a permission, perhaps the most dangerous of them all, called READ_LOGS. If that permission is set, then you can read the system logs. Find one relating to network access, then parse it through, and try to figure out how the phone is being used. These logs are deleted at reboot, however.
Personally, I wouldn't install that application, however...
Also worth looking at is the TrafficStats class, which will give you basic stuff, but not the details that you want.
No, you cannot know that.
If you could, it'd be a privacy violation ... If an arbitrary app could be installed, and know what I'm using my device. If you could get the application protocol type of all network connections, then you could also get the destination of the connections, and their content as well.
So I have read the LVL docs backward and forward, and have it working with my app. I have seen the questions about the response being cached. But it still leaves me wondering, based on some of the wording in the LVL docs, does Google want us to call the license checker every time the app is initialized? Is that the safest way to implement this? Using the ServerManagedPolicy like Google suggests, do we just call the license check, and either run our app or do whatever we choose if they fail? One of my small concerns is the use of network data. They drill into us the need to be cautious of using resources without informing the user, and it seems to me this is a use of network data without letting the user know.
To add to this, is anyone experiencing any type of delay to their app due to this code? Due to the nature of my app, opening it and then waiting every time for an ok to come through the network would definitely distract from its use. Should I cache the response myself, or am I way over thinking this?
You answered your own question; if you feel that calling the service every time you start would be disruptive (which it would, e.g. the user is out of coverage), then don't do it.
Google make no recommendations about how often to use the licensing service; it's down to how paranoid you as the application developer are about piracy, balanced with how much you feel constantly checking would annoy the user.
Ok, fair, only check it once in a while.. But where can you "safely" store the information, that you should check it once a day only?
Eg, the first time you start the app, you will check it. Result of LVL is valid: so you store the date of the last successful check. But where to store it? Using SharedPreferences ? Is this safe? Because if you have root access on your device you could access the preference and change the valid date (to either way in the future, an yes, ofcourse you can check that in the code :-))
PS. Sorry, could not make a comment :(
Call it every time you start the app. The LVL library, as shipped by Google, will cache the response and use it the next time the user starts the app, thus not requiring a network connection if they restart the application within the cache valid time-frame.
What you likely want to do is change the amount of time the cache is valid. By default, google ships with a fairly low cache-valid time, which resulted in some upset users who were outside of a network when the cache had expired.
Concerning LVL: Although the SDK provides a sample implementation, Google themselves, clearly recommend against using it "as-is".
http://www.google.com/events/io/2011/sessions/evading-pirates-and-stopping-vampires-using-license-verification-library-in-app-billing-and-app-engine.html
After watching that, I believe, LVL is not an option for apps sold for 1-2$. Furthermore, a failed LVL check (if no network is available) will piss off legitimate users.
while it is true, that you can implement some kind of caching LVL responses, it will always boild down to the question, in how far you want to protect against piracy at the expense of legitimate users?
And: developer time is limited, so maybe it is more worthwhile to put efforts in improving an app, instead off wasting to much time trying to cut down illegal usage.