Battery status integration about ulogger-android

[bfabiszewski]

It sounds fine.
Thanks @mendhak for helpful insight!

Personally I don't need such feature, but I think I could add it as an optional thing, allowing user to select additional extra data that is logged.
This will however have to wait, because I am terribly busy now, sorry :(

[julien-nc]

Thanks for considering this !

[julien-nc]

Do you really think getting the phone's battery status each time the app logs a position is battery consuming ? I would say that it just reads the information provided by Android API which must not cost a lot.

I would love to have that information sent with each position !

BTW : thanks for this great app.

[bfabiszewski]

If we wanted to have updated battery status every time we log position it would mean using more resources. We would have to use more battery in order to get battery status ;)
On the other hand we could just subscribe to low battery broadcasts. Then we could only log two states: battery low and battery ok. Would it be useful? I'am not convinced.

[rui00rodrigues]

In fact battery status is usable in case we are getting positions periodically. It will be good feature to allow tracking periodically without the need of GPS sensor to be always on. What you think?

[bfabiszewski]

This is how I understand it. Read here:

Generally speaking, the impact of constantly monitoring the battery level has a greater impact on the battery than your app's normal behavior, so it's good practice to only monitor significant changes in battery level—specifically when the device enters or exits a low battery state.

And monitoring significant changes means monitoring two states: ACTION_BATTERY_LOW and ACTION_BATTERY_OKAY.

[julien-nc]

I thought the battery status was stored somewhere by the system and that accessing it had a very low cost... Just like accessing the device name 😉. I mean, it should not be costly.

GpsLogger, which is very battery-saving-oriented, gets the battery level for each logged point. I'll ask the dev what he thinks about that topic.

[mendhak]

It's a sticky broadcast, so yep it does become expensive if it's being queried frequently. The way I've done it is here - no application level receivers, just that method and which by default gets called once a minute. From testing that's had no adverse effect on battery life.

So if you were to do this, it's worth setting some kind of a minimum time between these requests.

public static int getBatteryLevel(Context context) {
    Intent batteryIntent = context.registerReceiver(null, new IntentFilter(Intent.ACTION_BATTERY_CHANGED));
    int level = batteryIntent != null ? batteryIntent.getIntExtra(BatteryManager.EXTRA_LEVEL, -1) : 0;
    int scale = batteryIntent != null ? batteryIntent.getIntExtra(BatteryManager.EXTRA_SCALE, -1) : 0;

    if (level == -1 || scale == -1) {
        return 50;
    }

    return (int) (((float) level / (float) scale) * 100.0f);
}

[julien-nc]

To make it short : the battery level could be stored by the app and updated every minute (or even 10 minutes). This stored value would be sent with each logged point. This way, there are not too many accesses to system battery level but a relatively precise value is sent to the server.

What do you think about that @bfabiszewski ?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ohhai]

As for me, there is at least two usecases for this:

• When sending data to server: allow other people to guess why your phone suddenly turned off.
• When saving locally: allow you to estimate how specific settings affect battery life and tune them according to this data.

Both cases don't require frequent battery requests: 2..5 min interval is completely fine, as for me.
And this option could be disabled by default and enabled only by people who are ok to spend some extra power budget on it.