All in all I’d say your approach makes perfect sense.

The only comments I would make are the following:

It would seem as though the notification image doesn’t have much correlation to the GPS chips use. But this is only going off of what Reto had said with regards to proximity alerts.

If I were to use proximity alerts and I could afford the time to spend on it, I would likely pull the source code from Android and implement a slightly custom version of proximity alerts.

What you also need to take into account is the power to start and stop the GPS chip as you mentioned above.

Good luck and let me know how you get on.

Cheers,
Matt

On a similar topic, I have found that on my Gingerbread phone, when requesting location updates, the two (min_update_distance and min_update_time) arguments make no difference to the GPS state as shown by the icon – it just runs full bore all the time. I ended up writing a service with an IBinder which takes a ‘sleep time’ and a ‘required accuracy’ parameter. Once the accuracy criterion is satisfied it removes the update requests, turns the GPS off and sleeps until the period is up. It sends the locations to the activities via a broadcast (they have the broadcastreceivers).This seems to give much better battery life than the proprietary apps like ubiquitous Google’s Maps app.

I’m wondering whether I should adopt a similar approach for proximities? I.e. just have a List of locations and distances to trigger the alerts in a service and if you have network location on and it tells you you’re 10 miles away, don’t bother turning on the GPS, when you get near one start sending broadcasts

I’d appreciate your thoughts on the idea,

Regards

Nick

However I imagine it is achieved in a similar fashion to cancelling an alarm, so perhaps best to look for an example of that and see if the same can be achieved for Proximity alerts.

Documentation Here: Android Location Manager