I am trying to make a background service which should measure traffic usage of various applications so as to be able to show to the user which apps consume most data traffic.
I found that Spare Parts app does exactly that, but after installing it on a 1.6 Dell Streak device I always get "No battery usage data available" for "Network usage". Does this function at all work in Spare Parts?
Also, I couldn't find a working source code for Spare Parts.
https://android.googlesource.com/platform/development/+/froyo-release/apps/SpareParts
looks to be outdated or incomplete. (?)
But Spare Parts seems to measure e.g. CPU usage per app. How does it do that on an unrooted phone?
My general idea of how traffic per app could be measured is to regularly check the
"sys/class/net/" + sWiFiInterface + "/statistics/rx_bytes"
"sys/class/net/" + sWiFiInterface + "/statistics/tx_bytes"
"sys/class/net/" + sMobileInterface + "/statistics/rx_bytes"
"sys/class/net/" + sMobileInterface + "/statistics/tx_bytes"
files and to see which app currently has focus and thus most likely to cause the generated network traffic.
Unfortunately I can't find how to get the app currently having focus.
I found this:
Android, how to get information on which activity is currently showing (in foregorund)?
but seems it's about testing, not just a 3d party service running on non-rooted Android device.
We can get what activities are running with ActivityManager.getCurrentTasks(), but any of them can be the one with focus. It seems like the Android architects explicitly don't want 3d party apps to know what app has focus, because of security concerns
(see http://android.bigresource.com/Track/android-zb2mhvZX4/).
Is there a way around this?
Also, if I want to not only detect which activities eat up traffic but also what services, I can get all currently running services with
ActivityManager.getCurrentSerives()
and even see for each one if it's in foreground mode (unlike to be thrown out if Android needs resources). But this again doesn't bring me any far.
Any ideas?
You can detect currently foreground application with ActivityManager.getRunningAppProcesses call. It will return a list of RunningAppProcessInfo records. To determine which application is on foreground check RunningAppProcessInfo.importance field for equality to RunningAppProcessInfo.IMPORTANCE_FOREGROUND.
But be ware that call to ActivityManager.getRunningAppProcesses() method must be performed NOT in the UI thread. Just call it in the background thread (for example via AsyncTask) and it will return correct results. Check my post for additional details.
Related
I'm trying to create an app that manages a BLE connection in the background (receives notifications, reconnects and subscribes to a characteristic when connection is lost and the phone is moved near the BLE device again).
Right now I have the app somewhat built - everything that I need works relatively well but only when the app is open. Although the code isn't up to standard as this is my first app and I don't have any previous experience with Java/Kotlin/Dart (this is also why I'd rather not touch anything outside of flutter).
I need the app to send me local push notifications when tabbed out of the app or when screen lock is on and as far as I understand one could do this with isolates. I've searched a lot but found one guide which is kind of hard to understand as a beginner and also uses Kotlin.
Can I get away with only dart code for background code execution (described above) and is it suitable for a beginner?
Also, let me know if you have any alternative solutions since all I need is to get a notification on my phone whenever it receives a notification from a BLE device (and also auto connecting). I've already tried this with kivy since I'm more familiar with python but with no luck.
Talking about BLE there's this plugin by the way: https://pub.dev/packages/flutter_reactive_ble
As for the isolates, they are not ideal for this even though they do run separately, they'll get killed eventually. There's also a little helper package that makes working with isolates very straightforward if you want to try it: https://pub.dev/packages/computer
And so actually for the task at hand (background execution) I would suggest researching/using this one: https://pub.dev/packages/background_fetch
I would not encourage you to use any timer-based solution that tries to wake up your phone every 15 minutes or so, since that uses unnecessary CPU time.
Now I'm not that much into Flutter, but at least on Android, the "correct" way to have an ongoing connection (auto-connect) is to have a Foreground Service in the process running, so the process does not get killed. Then subscribe to characteristic notifications as usual, and handle the values as they arrive, either in Java or Flutter (by using some Java <-> Dart bridge).
for my current project I try to figure out the differences between Android and iOS. I only have knowledge in Android and absolutely no idea about iOS.
What I want to know is:
Is there something similar like Intents for iOS? Especially those which indicate changes in Wifi / BT connection like android.bluetooth.device.action.ACL_CONNECTED or android.net.wifi.STATE_CHANGE? Or is there another method to find out about connection changes even if the app is not running / in background mode?
As I understand from
IOS background service (like in Android) enable all time & https://developer.apple.com/library/ios/documentation/iphone/conceptual/iphoneosprogrammingguide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html, having a background service in iOS is only allowed for specific types of apps. So an app which asks for sensor values (like accelerator) on regular basis is not allowed - is this correct?
I am very thankful for answers and also further literature regarding these quesiton!
You can use an implementation of Reachability to get the notifications about Wifi connectivity, but keep in mind these won't wake up your app.
From Apple
From Cocoapods
You can use Core Bluetooth to look for connectivity events. Again these won't wake up your app. I believe you can setup a delegate to a CBCentralManager to find out about that. Check out the docs here.
However, you are correct in saying that you still need to solve the issue of background execution to keep your app awake. For that you need features that actually make background execution useful to a user or Apple won't approve your app. Here are some of your options.
If your app has actual bluetooth features you can use one of those modes (bluetooth-central and bluetooth-peripheral).
If you have a feature that warrants background audio you can use this
If you have a feature that warrants background location you can use CLLocationManager startUpdatingLocation (but this would eat up some serious battery)
You might also be able to set up a system that spams silent remote notifications and then use the remote-notification background mode. This is meant for downloading content
Also keep in mind that a user can basically disable all of these things on you at any time.
Good luck!
Im not sure if this will answer your question directly but it may be helpful. I know in Android that you can you an Intent to switch Activities. Well in iOS in order to switch to another UIViewController (iOS equivalent of activity) you would perform a segue. In prepareForSegue method you can handle what you want to do in the next UIViewController, such as passing variables etc.
You can use Background Fetch in iOS7 you can perform services while the app is asleep/in the background. This wakes the app at regular intervals in the background to perform a task, like refreshing data etc. You may be able to record the accelerometer values here. http://www.appcoda.com/ios7-background-fetch-programming/ has a good tutorial on this.
I hope this is somewhat helpful.
I hope this question meets the criteria for the site. I'll happily update otherwise.
I am, like many others, developing an application for multiple platforms using the PhoneGap (in this case Cordova 3) framework and want to keep my application alive while the use performs others tasks. I have read around this subject and seem many opinions and possible/partial solutions.
Notionally, what I want to do is allow the user to return to the application had they pressed back, home, they got a phone call, they played tetris or whatever and specifically if the app wants them back under certain conditions.
I am presently tackling this by concentrating on the Android platform and will expand out after this solved. I understand the mechanism by which Android OS will kill processes that are not visible and understand and have implemented an example background service.
I employ JQuery Mobile with collapsible content for my application.
Before I continue development, I would like to ensure I am on the right path.
I have successfully implemented pause/resume to handle phone locking and sleep. My application does not die and I can make it beep and vibrate through appropriate plugins.
My continued intention is this ...
Write a background service to perform periodic "checks" in this case position of phone relative to a known position. The intention is to inform the user when they have reached certain proximity. This would be started on the "pause" event and stopped on the "resume" or of the app is restarted.
Using Local Storage, maintain a record of state of the UI so it can be restarted in the correct state. Upon restart, the stored state will be restored and the app will look like it never went away. There is nothing in the app which continuously updates, like graphics or logs, so there is no reason to retrieve "past states" from the background service and perform a rendering of those as if they had been performed by the app, but that would not seem unreasonable should that be required on the future.
As it's possible that the app will not be running, it seems necessary for the service to create a ("something important has happened") notification that the user can click on in order to restart the application. I have found a couple of status bar notification plugins and intend to use one. I trust I will be able to beep/vibrate accordingly from the background service alo.
In addition, a "stuff is generally happening" continuous notification could be used to restart the app. I see no conflict with the above. It would be nice to find a "bring app to foreground is it's running" method, but I'm holding out no hope.
My essential question is this ...
Am I approaching this problem correctly and maintaining as much cross platform work as possible whilst not setting myself up for a fall when it comes to implementing the iOS facet of the solution?
I just don't want to miss a trick I've not located in the sea of answers to what seems like a common problem.
I am currently working on an Android project that monitors what applications a user is running and cross-checks the corresponding processes with a whitelist stored internally on the device.
In order to make this work, I need to know what the default or system processes for the device are so I can add them to the whitelist. That being said, I have a few questions I was hoping you might be able to answer:
Is there a way to differentiate between a default/system process that MUST be running, and a process that belongs to an app on the device?
Are there different default/system processes depending on what phone/version of android the user is running?
If so, are those process names available somewhere for developer use? Or is there some other way to obtain them?
If I need to elaborate more please let me know, thanks for the help.
Let's say that you try ActivityManager and getRunningAppProcesses(). Iterate over that array of RunningAppProcessInfo objects and find those with importance of IMPORTANCE_FOREGROUND. If the docs are correct (haven't tried this), there should only be one process that is IMPORTANCE_FOREGROUND -- the one that is truly in the UI foreground.
(services can call a startForeground() method to get foreground priority, but I am guessing they have IMPORTANCE_PERCEPTIBLE)
You could then examine the pkgList of that foreground process and compare that against your whitelist.
However, this breaks down if:
Something pops up asynchronously (alarm clock app, incoming phone call, etc.)
An app that is logically in your whitelist has changes that affect its package name (e.g., developer released a "pro" app that a student paid for, and the whitelist only has the free app)
if the device has multiple visible items (e.g., Samsung's multi-window capabilities), if all visible apps are not IMPORTANCE_FOREGROUND
This at least gets rid of the problem of pure background stuff that the student cannot control, including your "default/system processes".
However, it requires you to continuously poll, which will be a serious detriment to battery life. That, plus the privacy implications, means to me that this app should, at best, only be used for exams, and should be something that the student can install shortly before the exam and remove shortly after the exam.
Well I think my team and I have come up with the best solution so far. After reading the Android Docs, we found that by using ActivityManager.getRunningServices() we can use the constant FLAG_SYSTEM_PROCESS to determine what processes are core system processes. Then all we would do is cross-check that with the total list of running processes to differentiate between them.
I'm currently trying to assess whether a project can be realised for Android. One major problem I see it that, since it's a P2P client, we'd have to keep a considerable amount of connections open when running. Now the connections do not transfer large amounts of data, it's more of a messaging system, so having a thread for each connection creates a useless overhead if we're reading a single message of 64 bytes every now and then.
So I was wondering whether there is support for non blocking IO such as select() or poll() on Linux.
Any suggestion?
Check out java.nio Sockets, Selectors, and Channels. Some links:
Android: Unbuffered IO
http://developer.android.com/reference/java/nio/channels/ServerSocketChannel.html
http://developer.android.com/reference/java/nio/channels/SocketChannel.html
http://www.developer.com/java/article.php/3837316/Non-Blocking-IO-Made-Possible-in-Java.htm
Or, maybe I didn't read your question right.
Of course. Once your application declares uses internet permission, you can do all normal linux networking things normally available to a non-root user in C using the NDK, and any of them from java that someone (possibly you if no one beat you too it) has bothered to write support for.
Well, one exception: your mobile provider probably won't permit incoming connections, and neither will most wifi routers unless you specially set them up to. But those are infrastructure issues rather than issues with android itself.
You will probably also need to come up with some combination of an Activity to provide the foreground UI and a Service to continue the actual transfers in the background with just a status bar icon showing.