I have the T-Mobile version of the LG G2, running Android 4.2.2, everything stock except the keyboard. I'm not sure what version of Google Maps, but the Play Store says it's up to date.

Yesterday I noticed that the G2's battery was draining a lot faster than it had been. I had thought it was just because I had been listening to music a lot more that day, but then when I checked the battery app that night it said that Google Maps was responsible for half the battery drain. I had used it earlier that morning for directions and it had apparently run the GPS in the background for 11 hours straight. I thought it was a one-off, but it happened again today. I've attached a screenshot.

The GPS on my device is off as far as I can tell (i.e. the visual indicator in the tray is dark), so I don't know whether Google Maps is turning it on stealthily and forgetting to turn it off, or whether it's trying to find a GPS signal, can't because the radio is off, and gets stuck in a loop looking for it. I'm assuming the former because there's no CPU activity, just GPS. When I click the "Location Services" button, these are the settings:

  • Access to my location: ON
  • GPS Satellites: OFF
  • Wi-Fi & mobile network location: ON

So it shouldn't be happening. Why does this happen and how can I fix it? I suppose I can just remember to force stop Google Maps every time I use it, but I'm hoping for a better solution.

Screenshot (click for larger variant)

  • Also, I just discovered that the GPS drain doesn't stop when I force kill the process. Could my GPS just be broken?
    – Zelbinian
    Commented Nov 20, 2013 at 19:48
  • Google Maps does that. That's why I froze it, and only unfreeze it when I need it. Is your device rooted? Is Google Maps installed as system-app, or did you install it yourself?
    – Izzy
    Commented Nov 20, 2013 at 21:23
  • Came pre-installed. And, no, as I said, everything is stock - not rooted.
    – Zelbinian
    Commented Nov 20, 2013 at 22:15
  • In that case, I'm afraid there's not much you can do. Rooted+UserApp would give you the option of using Greenify. Without the two, you could go to Settings→Apps, scroll to Google Maps, and "disable" it – but that can just be done after uninstalling its updates, which is not quite convenient (as whenever you need it, you'd have to "enable" it again, and wait for the updates to be re-installed or use the old version; plus switching on/off requires too many steps). Of course you could disable it, and use a different maps/navigation app altogether.
    – Izzy
    Commented Nov 20, 2013 at 22:39
  • 1
    Done. Hope it's not too technical, but at least understandable :)
    – Izzy
    Commented Nov 21, 2013 at 13:25

1 Answer 1


Google Maps is known for situations like this for years. It doesn't happen all the time and on all devices simultaneously with all versions of maps, but comes often enough. For me, the decision was to disable/freeze Google Maps, and use other Map apps (Locus Map, OruxMaps) instead. But let's go into details how an app (in your case Google Maps) can be "put on ice":

On a rooted device

A rooted device gives you the most alternatives. Say you want to use the app from time to time, you could use the following approach:

Dynamic freeze

  1. convert Google Maps from system-app to user-app. This can be done e.g. with Titanium Backup – and is of course not necessary if Maps didn't ship with your device (but was explicitly installed by yourself, which already makes it a "user-app")
  2. Greenify Maps. This way the app is kept from running unless you explicitly start it. You could think of this as a "dynamic freeze"

Static freeze

If you do not need the app anyway, and rather use another replacement, you can freeze it permanently. A freeze marks an app as being "unavailable", so it can no longer be started. There are multiple apps which can handle this, as e.g. before mentioned Titanium Backup or App Quarantine. Using Titanium Backup would give you an advantage here: TiBu let's you place a shortcut on your homescreen to freeze/unfreeze-start an app, basically emulating the "dynamic freeze" described above. No need to convert the app into an user-app for this.

Disabling Auto-Start on certain events

Many apps register so-called "broadcast receivers" to be notified on system events they are interested in. The best known certainly is boot_completed for apps that want to become active right after the device has booted up – but there are a lot more. Examples include the change of network status (true for our Google Maps candidate), battery-low, or the SDCard being mounted. On a rooted device, you can disable those "listeners" with so-called "Autostart managers". One of the best is Autorun Manager in its Pro-Version. If using those, take care to not disable too much, as that might render an app unusable.

Without root

Without root, I know of only one way to achieve something comparable:

  1. Go to Settings→Apps
  2. Select the "All" tab
  3. Scroll to the app in question (here: Google Maps), and tap its entry
  4. If you don't see a "Disable" button, but "uninstall updates" instead, it's a system app. Tap "uninstall updates", then "force stop".
  5. Tap the "Disable" button

Now the app is de-activated, and should no longer run. I explicitly made "should" in italics, as to my experience often this is only a partial working solution: though the app is removed from the drawer, it seems it's still not completely out-of-reach for certain frameworks.

Pros and Cons

  • Disable: Only available solution if your device is not rooted.
    • Pro: does not require root
    • Cons:
    • app not always completely disabled
    • no dynamics
    • requires multiple "taps"
    • requires to always uninstall updates first (if there are any)
    • not applyable to all apps (manufacturer/carrier can "lock" apps against this)
  • Static Freeze:
    • Pros:
    • Works on all apps
    • Partly dynamic (using TiBu and its "shortcuts" on your homescreen)
    • Con: Requires root
  • Dynamic Freeze:
    • Pros:
    • Dynamic
    • app icons remain in the drawer/on your home screens (so from the user's perspective, handling remains unchanged)
    • Cons:
    • requires root
    • doesn't work on system apps (though there are "experimental features" for this AFAIK).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .