For a personal project, I'm trying to detect when an android device is with someone driving. I initially thought of using GPS to determine average velocity, but decided that would consume power and requires that the user has GPS enabled at all times. I'd heard that it's possible to tell when someone switches cell towers (on both android and iOS), but is there a broadcast intent for this? I'm very new to Android development, so was hoping I could register a broadcast receiver to run when I believe the device is in a moving car.
I'm not sure if I can create my own broadcast intents and I assume I couldn't rely on a background process to always be running since android may kill it if memory is needed.
As a side note, I notice that some apps, like skype, have a background process that restarts itself even if I force kill it. How do they do this? My thought would be to have a broadcast receiver for when device moves, turns on, etc. to restart the background process... is that what they do?
Thanks for any info!
I would suggest GPS would give you much better indication of motion, since you likely change towers somewhat infrequently. Even mapping applications that are able to triangulate your position using tower signal are extremely inaccurate. Often even with a very good signal they aren't able to triangulate your position any better than within 1600m.
You could also look into asking the user if they have a bluetooth kit in their car. If they have you can find the name of this pairing and when connected you know they are in the car (or close to it).
Related
What I want to do is is there a very way to prevent user from turning off Mobile Data & Location services?
My scenario is this, I am creating a mobile application for a big project we have now. This application is restricted for the use of their employees going out of the field, now this phone by any means should not turn off mobile data and location services as I have an application service that sends constant location data to the administration API.
OR maybe an existing application that prevent native functions like this from being accessed. This may sound crazy but I just have thought if there is something like this.
Thank you!
I hope someone could enlighten me.
No, you can't do that.
Even if you could, it would not solve anything, because there are many other reasons why those services may not work. For example when one is driving through a tunnel and there is no signal or out of town there may sometimes be no signal or the network may be overloaded or something. So you can't rely on these services anyway. Intermittent loss of connectivity is pretty common in mobile devices. You will have to take it into account (log data and send them when you succeed in reconnecting).
If the users need the application, and connectivity in it, to do their job, they won't be turning it off, because they need it. So all that is needed is to create a notification when connectivity and/or location is lost so the user can do something about it if:
the application fails to connect when they turn it on at the start of their shift or
the application looses connection for extended period of time for whatever reason.
And of course if there is somebody in the company using the data (some dispatcher), which I suppose there is, they will notice the particular worker is not sending anything and will try to contact them by calling or something. These should take care of mistakes and faults.
If the users don't need it and it is intended to spy on them (so they may have a reason to disable it), it is probably illegal anyway.
You cannot prevent user from turning off Mobile data. But you can simple record location in a file with time while data is off and send it immediately after user turn on the data.
That is impossible unless the device is rooted.
And it makes perfect sense, because that would compromise the user's experience of Android and/or security.
You must anticipate circumstances like the user turning off the data or connection and act appropriately (for example gracefully stall your connections with the internet and resume them later, inform the user that his device has been disconnected from the internet and that your application requires internet access etc...).
I have a big problem with an Android application that I developed.
The purpose of the application (for business) is to track the position of the device continuously (24 hours on 24) detecting a GPS track on a regular interval, which will then be synchronized to the server to the unleashing of certain events.
Of course, over time the device in and out of buildings, acquiring and losing the GPS signal continuously.
Often the device is not used and remains in office for several hours inside the company headquarters without GPS signal. During the course of time the Android system continues to provide me constantly getLastKnowLocation
My problem is that after some time that the system is running, sometimes two or three days, sometimes more days, my app starts to receive from the system always the same coordinates, regardless of who is in the open or at closed. From what I understand the Android operating system no longer seems able to update his coordinates and It will always return the same getLastKnowLocation indefinitely.
My App therefore becomes useless.
You know how I can fix this?
Is there any process that Android can restart in order for the system to wake up. In My App I will acquire any permission, except for root permissions.
For now the only control that I put, and that if the system always gives me the same identity for a number of seconds I call the method requestLocationUpdates of the location manager again.
But I need something more robust, to give me a better guarantee of operation. I'd like to be sure as possible that the systems try really to get updated coordinates.
The only thing I can think of is that maybe I can ask the system to restart some process so that the Location Manager, is fully reset. Can I do this? What is the process to be killed?
Can you think of any other solution or you found yourselves in this issue?
Thank you.
I have 2 android applications A and B, and both of them are reading gps values based on different parameters. Considering both the apps are running on the device, which of the folllowing approaches would be better?
Both A and B are to be different apps, each one with a component to read from GPS.
To develop a third application with a remote service component to transmit GPS data to both A and B
Would battery usage be minimized by going for the second approach or will the GPS component read once and serve all processes, as in the OS?
Please help
There is a very good explanation given in the Android Developers Website about Location Strategies. I would suggest you to take a look at the code examples on the page.
In both of your approaches i believe second approach is quite better because Turning on/off GPS is a quite expensive operation in terms of battery usage.
GPS’s battery draining behavior is most noticeable during the initial acquisition of the satellite’s navigation message. Acquiring each satellite takes 12 to 30 seconds, but if the full almanac is needed, this can take up to 12 minutes. During all of this, your phone is unable to enter a deep sleep. A-GPS (Assisted GPS) partially solves this, by sending the navigational message to your mobile device over your cellular data network or even Wi-Fi. As the bandwidth of either of these greatly dwarves the 50bps of the GPS satellites, the time spent powering the GPS antenna or avoiding deep sleep is greatly reduced.
Referred from this.
I think the most battery-efficient way would be to poll the GPS location with app A normally, and in app B, use LocationRequests and use setPriority() with PRIORITY_NO_POWER. As mentioned in the docs, PRIORITY_NO_POWER will make app B get updates only when another app gets GPS updates (in this case, app A!!). I haven't tried it, but it should work. It definitely saves you the hassle of an extra app :)
Some more info on Google Play Location Services here and here.
is it the same as OS gPS component will run once to serve all
One GPS serves all.
There is no half GPS saving half the power.
But there are other location providers like cell tower and Wifi locationing which uses less power.
But if you need GPS it is absolutley no difference how many apps uses the GPS service.
If GPS is enabled it uses full power.
For the sake of compatibility and function I would suggest having a third process or program which reads and outputs GPS data, as multiple processes polling data from GPS is less efficient.
It would also be faster to have those two apps read the output of a single GPS tracking app and not needing individual components in each app to do so.
For the sake of power the GPS will use the same level of power regardless, though if it's polled more often due to two applications using it then it may use more - though the amount is likely to be minimal unless there are constant requests for location.
Though this may not be the question it would be most power efficient to have the third application poll GPS at specific intervals and the applications may read from its output rather than search location every time.
Second approach seems to be more appropriate but not sure about battery drainage.It depends upon how you implement it.
Also I would suggest try to use passive providers.Refer following link help it works :)
http://fypandroid.wordpress.com/2011/04/11/298/
Just watched the session about new location capabilities:
https://developers.google.com/events/io/sessions/325337477
and think that feature of GEOFENCES will be a good fit for my app.
I also downloaded the demo app which while quite informative is not giving me the functionality I am looking for.
So could someone please explain me or point me to some example on how could I add a geofencing detection to the app that works while the app is off. If you have seen the IO session and noticed the app Zillo that is what I am talking about.
What I know by now is that I don't want to use a constantly running service in the background that detects TRANSITION broadcast but would like to register for them in the manifest file and than handle them inside a broadcast receiver class. Something like you would do when using GCM messaging.
So the questions are:
What broadcast needs to be registered in the manifest?
When should I register my fences so they are registered only once and stay registered when the app is closed?
Are there any pointers on how to optimize battery life in a case like this?
If someone already has experience what radius for a geofence would you suggest to detect entering a large building (3000-5000 sqm ground floor area for example)?
I implemented what you are talking about. (using a broadcast receiver instead of a IntentService). I started with the sample code, then made a few small changes, listed in my response here.
It seems to be working fine when the app is closed.
As far as optimizing battery life, this is all done by the OS. You just register the fences and Android handles the rest. I think they have optimized it well, I haven't seen significant drain after registering almost 100 fences. But I haven't done extensive testing.
As far as the radius size, I suggest building a sample app that has a map in it, and put a pin on the lat lng and play with the radius till it looks right. For a wild guess, I'd suggest something around 150 meter radius?
--update--
More detail on what I've found as far as accuracy. I built a testing app to see track myself and see the accuracy, and been driving around for the last few weeks and checking it frequently. I've only been testing with gps off since thats similar to what most users will encounter when they are out and about. :
Outdoors, not close to any wifi signals: Not very accurate, something like 100-200+ meters
Outdoors, close to wifi signals: Surprisingly accurate. Between 10-30 meters. If I'm sitting outside a restaurant, or at a strip mall where there are wifi signals, it knows very well where I am.
Indoors: even with wifi, many times it seemed less accurate than outdoors. More like 30-50 meters.
I am a complete Android programming newbie.
I have completed some tutorial examples like HelloAndroid and the HelloViews/Layouts, but that is about the extent of my Android programming abilities.
I am not the programmer on this project, I am the tester(QA) for a company that is developing an Android application that will track company owned devices every 1 minute, and send the positions back once 5 or so are stored.(Limiting mobile network usage, to conserve battery.) My company bought and pays for the android devices, and the employees are aware they are being tracked, both for safety purposes of the employees as well as accountability. Behind making phone calls and some mild emailing, this is one of the most important functions/uses of our devices.
Our biggest problem is that our application can be killed at any time by the Android OS, for any number of reasons(device resources, etc.) Right now, we have an Android service that checks if our app is running every so often and if not, it starts it back up. Once our app is running it can be in the background and request positions using a service in the app itself, then send them to our server for processing and storage.
From everything I have read about Android Development practices, this does not seem to be the most Android "appropriate" way to do this. From what I can gather, and this is fairly limited, we should have an Android service that runs in the background and requests then sends positions, but even this can be killed without notice from the OS, right?
Any advice or suggestions anyone could provide that would point me in the right direction?
It might be worth mentioning that this will kill everyones battery extremely fast... but you pretty much have it right as far as the best way to do it. If the OS does kill your app in the background, your service can just restart it.
What are your concerns, that the OS will repeatedly kill it and not allow it to do its job?
Or that the GPS locations wont be accurate? Location.getAccuracy() could help you figure out if the location is worth saving
http://developer.android.com/reference/android/location/Location.html