Google maps seems to have an insane amount of Intents registered for it, as well as other ways of being started.
Since this is a pretty resource hungry app (especially memory wise), I would very much want it permanently not running unless/until I actually need it. However, Android keeps starting it all the time - for example, when the connectivity status changes (which for me happens pretty frequently indoors), or GPS/network location changes.
Is there some way of ensuring that Google Maps doesn't start ANY processes, guaranteed, until I click on an icon to deliberately launch it?
Environment: Droid X, running rooted stock Froyo 2.2; I have Autostarts. and Advanced Task Killer, as well as Pro version of Titanium Backup installed.
I'm fairly open to almost any method as long as
It's reliable.
It lets me use Google Maps with 100% intended functionality once I DO need it, without requiring 5 minutes of work to re-configure.
Ideally, doesn't require me to reboot to use it, but this one is not a deal killer.
I would STRONGLY prefer a generic method which would be applicable to other applications, NOT just Google Maps.
I'm a software developer with a hefty dose of Unix/Linux system administration experience. In other words, solutions which require shell prompt or writing/running shell scripts (or Perl in Android Scripting Environment) are extremely welcome.
Solutions involving writing my own Java Android app are acceptable as long as they are detailed enough than a total Android development newbie can get at least some work done without being 100% lost.
Things I tried:
Killing the processes via Task Killer is NOT working - they come back up, either immediately or in a little while. Probably via Intents but not 100% certain.
Standard methods of getting rid of GMaps issues (log out of Latitude/shut down GPS and network locator). This seems to help a lot BUT I find the need to permanently shut down GPS/locator to be unacceptable - e.g. it won't let me run Locale app or locale-based Tasker things.
Freeze via Titanium Backup Pro. This requires a reboot and generally not very pleasant.
Possible approaches I thought of (but don't know how to do) are:
Somehow FULLY eliminate (turn off) all Intents registered by Google Maps when not needed.
Problems: First, I don't know what ALL the Intents Google Maps uses.
Second, the only practical way of doing that that I know of is Autostarts app which is NOT a workable solution - it takes ~5-10 mins to find and re-enable all the intents I am aware of (Autostarts is really poor at per-app intent management - it's centered on per-intent), never mind possible intents that Autostarts does NOT know about (it's a black box, I don't know which intents are missed if any.
Have a script which will rename the JARs or whatever the executable files on Android are (entire .APK?) from say
GoogleMaps.apk
toGoogleMaps.disabled.apk
and back.Problem: I don't know if this is possible to do on a rooted Froyo. Also, Google Maps was pre-installed on DroidX, so would renaming somehow ONLY affect the update but not the original app?
Have a script which will go into the APK and rename/move/empty out manifest file to remove any intents for that app.
Problem: Would this require a recompile? It definitely requires a reboot which is a minus
Answer
From your mentioning of Titanium Backup I assume your device is rooted. So my absolute recommendation here is AutoRun Manager (and yes, you will need the Pro -- second yes, it's worth it). Having that installed, open the app, use the "advanced mode", look for the app you want to modify (in your case: Google Maps). Expand it. ARM will show you all its listeners -- disable them.
That's it. Nothing is waking it up anymore unless you explicitly start it. BUT: Before you start it, you may need to enable those listeners again, or you may experience strange side effects (I did). On the other side, at least this does not require a reboot.
For technical details, you might want to crosscheck with the question How can I manage intent associations with apps, or directly dive into the Intents section of the AOSP developer manuals.
No comments:
Post a Comment