I'm writing an app that requires frequent location checks using GPS. It needs to get the current location every 10-15 seconds and then write it to a database (the database part is mostly irrelevant for this question, just wanted to throw it out there). The issue I'm facing is that I can't find a decent way to accomplish this. I've tried several things:
Using LocationManager.getBackgroundLocationListener() never seems to work. I've tried it on both Android and iOS and nothing ever seems to happen. Might be something I'm doing wrong but regardless, I've read that on iOS, it will only get hit when moving to a different cell tower, so that doesn't meet my needs.
I've tried using Background Fetch, but it's only reliable on Android. The frequency is completely random on iOS and so this won't meet my needs either.
I've tried just starting a new thread that will fetch the current location every 10-15 seconds, but this only works when the screen is on and the app is being used. This won't meet my needs because I need to make sure it continues getting location updates when switching to other apps.
Does anyone have any suggestions on alternative methods to solve this problem? Note that I don't have a background in objective-c, so a cross-platform solution like Codename One is really my only option here.
Background fetch isn't the right choice in this case as iOS expects you to declare what you are actually doing. What you are trying to do is prohibited in iOS and might be problematic in Android too.
Fetching location data in the background (especially at this resolution) has serious privacy implications so I doubt it will work. Doing this in the foreground should work fine to allow use cases such as navigation but in the background it might be an issue.
This is further compounded by the fact that location and networking are big battery draining activities. So there are limits to the resolution you can apply with these API's. One of the more common use cases for background is geo-fencing which allows you to track when a user approaches an important point of interest. The reason this API exists is to reduce polling costs and keep location usage to a minimum.
Notice that both Android & iOS provide tools to detect battery usage for the user and these might impact misbehaving apps.
Related
Well i have read a lot of answers of similar questions (even if they are old from like 2013-2014) and i understood that it is not possible to know it exactly since android doesnt count the hardware usage as usage of the app, and some other possible problems like services etc.
At the moment I'm trying to test the perfomance of an App using a protocol to reach a goal and the perfomance of the same App using another protocol (not well known by everyone) to reach the same goal, the default android battery analyzer is good for me since both cases are like 90% the same and i know how the protocols work
My problem is that i'm not sure which one is the best to measure the mAph consumed by my App, i know that there are some external apps that shows it but i would prefer using the one of default, I believe this is something important not only for me but for other people who might have to compare different protocols.
I know that i can measure it programmatically and I've done it too, i save the percentage when the app is opened and how much has been consumed until it gets closed, but it isnt an exact measure since while the app is opened some other apps can do heavy work and add some kind of noise of what i'm measuring so i would prefer to use the android's battery analyzer.
Get a spare device. Load it completely, then run the protocol until shutdown without other interaction (no youtube or anything), note the time it lasted. Repeat with the other protocol. Imho that is a fair way to compare. Note that every device behaves differently and it may or may not be possible to transfer this result to other devices e.g. with different network chips, processors or even firmware versions.
For a more fair comparison I think you should compare how the protocols work. I.e. number of interactions, payload size etc. because the power consumption can only ever be an estimate.
I am working on the GPS part of a project and I would like to get something past the community. I have searched around for all the typical GPS "jumping and drifting" and I have worked on improving what I get but last week I got some really weird data that I cannot put my finger on.
The application basically has a foreground service that tracks the location and then uploads that data on a timer. Of course we have all the proper permissions needed and there is also a filter that weeds out data with really bad accuracy and "detects" stops. All was working well until what you can see here happened.
These are some of the data points I got. A "beautiful" pattern drawing. The same happens to another location too but not to this extend. I checked the data to find out why my filter didn't even try to make things better and I found out that it would be unable to. All the points have proper speed, heading, and accuracy and for all intents and purposes I could say that the person actually did the whole thing. The problem is that it didn't happen. The phone, (Samsung J5) might not be the best there is out there, was in a room the whole time. From my understanding of the Fused Location Provider there is no speed reported if there is no GPS involved in the process. And lets assume that where the phone was sitting it could actually get a GPS signal. I can see it jumping around but going for a walk around the neighborhood?
I know and understand that the location in Android (and any other platform) can be a very complicated matter comprised of many different variables that mainly start from the hardware providing these variables, but how can we explain this sudden influx of crazy, even though seemingly proper, data? Can we consider that keeping the location service up and running for a long time actually bogged or "tired" the system? How can the same device that has given OK data to this point suddenly provide this dataset?
To add to the issue. In the data there were also one or two long delays of around 2 minutes (intervals set to 15 and 10 (for fastest) seconds). I am 100% sure that the service did not restart or anything of the kind because I am logging for that.
Any kind of insight would be greatly appreciated and if there is any way/method/algorithm you could recommend looking into to "fix" this kind of behavior would be great. Thank you in advance and sorry for the long question. I needed to provide a proper background.
EDIT: This is not really the answer to my question, why such a behavior suddenly appears, so I am adding it here as a way to try and mitigate the problem, at least a bit. I decided to use the Google's ActivityRecognitionAPI (comes bundled in the location API so no need to have more dependencies) and merged its output with my existing filter to hopefully "fix" the "false" location data.
If someone could still, though, give me a good answer (help me understand) on whether there are factors like long running times, or other hardware (or software) factors (excluding the typical knowledge that GPS chips on phones are bad) that can cause weird and unexpected behaviors like the mentioned one would be rather appreciated.
(We can of course always say - "It is the phones fault" - and be done ;) )
The GPS has errors, so even if you stand still at the same point you will get different readings. There's a couple of things you can do:
Use the accuracy value of the GPS - if the distance between the new reading and the previous one is lower than the accuracy - ignore it.
Use the device's accelerometer in order to determine if it's moving or not.
It is a well known issue that many Android phones switch off the accelerometer when the screen goes off. However something seems to have changed with Android Fit (the app). Fit keeps counting steps even when the screen goes off. If Fit is installed, then events are raised for step counting within the Fit environment and I am able to capture them using
Fitness.SensorsApi.findDataSources(mClient, new DataSourcesRequest.Builder()
.setDataTypes(DataType.TYPE_STEP_COUNT_CUMULATIVE)
I have tested this on a Samsung S4 and on a Oneplus One and in both cases the steps are counted.
How do they do that? What Android classes do they use?
My understanding is that the available method introduced since Kitkat is to implement a SensorEventListener. For example theelfismike provides code that implements this. However on many phones the step counting stops when the screen goes off. Interestingly the counting does not seem to stop if the Google Fit app is installed (hence I guess they keep the accelerometer on).
Am I missing something? Is the functionality of keeping counting steps after screen off available to the mortal programmers?
Thanks!
As Ilja said, your code runs even after the screen gets turned off. But in this case I guess we need a little different answer.
They definitely use a Service that keeps a wakelock and they query the sensors for data. Important part here is holding the wakelock - you have to prevent the device from going into sleep during lifetime of your service - if you don't want to miss some data.
But this approach will be drain the battery really fast, because in order to detect steps you need to process quite a lot of data from sensors.
Thats why there is sensor batching. That allows you to get continuous sensor data even without keeping the device awake. It basically stores the sensor events in a hw based queue right in the chip itself and only sends them to your app (service,..) at predefined intervals in batches. This allows you to do a 24/7 monitoring without draining the battery significantly. Please note that only supported chipsets can do that (you can find details in Android docs), in case of older phones you need to fallback to the hideous wakelock keeping method in order to get your data.
You can also just use Google Fit APIs, but this would only work when there're both Google Fit + Google Play Services installed on the device with monitoring turned on.
Every normal Thread is keep on working when the screen goes off or when the Activity lost its focus...but when the activity gets killed then all thread are killed...
However you can use services for longrunning tasks like asking the accelerometer for example
So I am working with a quiz game in android where you are supposed to be two players playing against each other on different devices.
I am trying to figure out how the correct way is to set up the server communication to the devices. I want both devices to know when both players has given their answers to a question so they can receive the game result.
My first thought was that both devices will repeatedly ask the server if the other device is finished so they can have the game result. But I start thinking this is a bad idea as it will cause a lot of unnecessary traffic and probably some background performance.
So what is the correct way of doing this?
The Google Android way of doing this would be using Google Cloud Messaging (GCM.) This approach is battery & processor efficient, supports broadcasting up to 1000 users at once and has built in functionality for outdated/expired messages.
http://developer.android.com/training/cloudsync/gcm.html
Of course there are other ways of communicating that may be correct/right/valid but this approach is the best for your specified requirement.
Well i have successfully obtained the light value, however, it is EXTREMELY delayed. Approx 3~5 seconds even when using .SENSOR_DELAYED_FASTEST also even when entering 0 as the rate. Its so slow. I have the program check light sensor values upon screen on then change brightness accordingly HOPING it would solve the horrible automatic brightness delay. but after messing around with it, it seems to me that this is simply a flaw in android. It simply cannot update fast enough. I have used getDefaultSensor() but according to android documention this value can be delayed/filtered, but upon reading another post on stackoverflow the getSensorList() and getDefaultSensor() return the same values and that getSensorList() is no different than getDefaultSensor()
The reason for my question is: Is this correct? Is android simply a fail at updating immediatly? its funny cause my Windows MOBILE(not phone) can update immediatly and i loved it. but with all android devices ive seen its the same thing. so is this just a flaw in androids programming? Is there a way for me as an app dev to fix this? or do we have to live with it?
As I know you cannot get it faster. Please take a look on this question and answer: https://stackoverflow.com/a/5060690/1381641
I don't have the solution for your problem, but I do have an explanation for it. The Ambient light sensor has a delay because of the integration time downloads Sensor Box for android from the Playstore.
You will get the hardware ID of your ambient light sensor, then google search it, and you will get a PDF with technical details about that specific model number. Every Android or IOS phone does NOT use the same hardware.
In that PDF, you will get an integration time. It exists to keep the brightness control stable and delayed as well as sensible. If it is low, and you are in a disco your brightness level will keep on flickering. The same for outside, sometimes some shadows make it go up and down if the integration time is low. It will flicker more and will not be stable.
This will also cause harm to the backlight, so instead of taking single values they compile down the values of a big time interval. My integration time was 400ms. This value is sent to the processor, and then the decision is taken.
You could change this value. It is easy, AMD hard boh depends on your expertise like to update this you have to program the ALS unit by opening the phone, connecting a programmer to it, and connecting the pins in the right way. Then sending an 8 bit signal as mentioned in the PDF (if model is programmable).