TODO

From what I hear from users, the live UI refresh while loading contributes
significantly to the UI loading time. See if we can optimize loading speed 
by refreshing lessoften.

Convert the intent information into XML format, it's getting harder and
harder to manage in the Java file.

Move state toggling into a service. This will allow the user to queue up
multiple change requests, and it's what is necessary to support some kind
of "save all user's changes" and "restore after reflash" feature.

Make it easier to find new apps (sorting by installation date, or simply
recognizing the new apps since Autostarts was last started.

See if we can make it more clear which items have been disabled.

Investigate when, under what circumstances Android starts an app's backup
service, and whether support for this is something we have to add to 
Autostarts. There has been at least one report by a user of such an app
repeatedly starting on boot.

Try using the new Loader API:
    http://android-developers.blogspot.com/2011/03/fragments-for-all.html),
instead of the current AsyncTask-based loading.

Add a search/filter feature. MENU long press brings up a keyboard,
let the user type away to restrict the list to matches. Should also
react to the SEARCH button.

When displaying actions that have no pretty name, the text often
doesn't fit the screen. We show an ellipsis then, but it would be
nicer to adjust the font size, iOS-like. See:
    http://stackoverflow.com/questions/2617266/how-to-adjust-text-font-size-to-fit-textview
	http://stackoverflow.com/questions/5033012/auto-scale-textview-text-to-fit-within-bounds

See if we can replace the current dialog-based GUI with inline-actions.
That is, if an item is selected, it is expanded and includes a button
to disable/enable, and all the other information from the dialog.
Long-press may still be used for infrequently used actions.

Investigate what we can do about activity intent filters. For example,
android.intent.action.SEARCH_LONG_PRESS seems something that might just
as well appear in our list. Are there others? Should they be displayed
separately? Will only of all registered activities be called if there
are more than one (as opposed to the receiver behavior)?

Loading on a G1 with *lots* of apps is terribly slow now with the new
backend (> 1 minute). We could employ caching to improve this, based
on the package version number. Only when that one changes do we
refresh the cache. The "reload" feature would then act as a refresh
of the full cache.

Show a notification whenever a package is added or updated that includes
new autostarts; this makes it easy to "review" all autostarts as new
applications are installed. Ironically, we will have to register a
broadcast receiver ourselves to implement this.

The notification-feature is a good opportunity to implement some kind
of hashing, where we can determine whether I package is new or has changed
very quickly, instead of having to reparse it again everytime, which
turns out to be a costly process (our new backend is considerably slower
then the old one).

For actions like SECRET_CODE_ACTION it would be interesting to show the
intent filter that it matches. For example, the voice dialer here matches
only a certain scheme, and others handle it in a similar manner
(http://www.google.com/codesearch?hl=en&sa=N&filter=0&q=android_secret_code).
Even for PACKAGE_ADDED et al. it's possible for an application to only
register for a specific package. This needs to be made clear to the user
some way, lest he think the app is starting more often than it really is.

Receivers can apparently also restrict themselves by defining a <category>,
and some intents may specifically be sent to a specific application,
like the C2DM intents, or the widget intents. Find out what exactly is
going on and expose the info via the UI.

One of the problems our current way of reading the intents has is that
we essentially trust the apps, that whatever they declare is correct.
Specifically, there are some intents like SCREEN_ON or SCREEN_OFF which
an app cannot register for through the manifest. Possible the right way
to fix this would be to simply remove those intents from the "known" list.
Alternatively, we could show a hint indicating that does events will
not actually be executed; it'll even be helpful for developers to debug.

Do something with the information about protected-broadcasts, see
"framework/core/res/AndroidManifest.xml". We can either pre-store those,
or read live from the system.

The dropdown icons of the ExpandableListView are not properly rendered on a
QVGA 120dpi device (tested in emulator), with anyDensity=true. Since we
don't even really touch those, we need to assume it's a bug in Android.
Confirm (file a report), and try to find a workaround.

Now that we may have quite a long list, depending on installed apps,
a sorting options might also make sense. We could sort alphabetically,
by the number of components in a group, or by "importance" of a receiver.
The latter would be a number determined by us, and would be an attempt
to maintain the current order, i.e. BOOT would be on top.

Another possible attempt to keep the list clean would be a filter that
removes all apps which register for their own intents. Since nobody
"owns" an action, this can't be determined in a 100% guaranteed way,
but for many cases, comparing the namespace strings should suffice.

Helpful would also be the ability to filter the list using a hardware
keyboard, similar to the contact list could be filtered previous to
the introduction of global search. I believe there should be some builtin
facilities that we should use to provide this.

Currently, we don't pay any attention to the fact that a single receiver
may be responsible for multiple events. As a result, disabling a single
component may effect multiple entries. We already reflect this correctly
in the UI, but we want the user to be made aware of it as well. So show
a message like:
  "$APPNAME processes this event in bulk together with $NUM other events.
   If you disable/enable $EVENT, the following events of the app will also
   be enabled."

There are a number of broadcasts which effectively seem to be equivalent to
BOOT_COMPLETED, like a lot of the network state change stuff. Maybe this
could be made more obvious to the user.

Update our custom colors to be stateful.
Also, multiple people have no complained about the yellow used to indicate
system apps not being readable enough. FInd a different color, or a better
tone of yellow.

Implement the ability to disable a app as a whole; nice to get rid of
pre-installed applications.

Some guy here wrote up explanations for a number of broadcasts, some of
which are still missing from our db:
    http://androidvoid.blogspot.com/2009/04/android-broadcast-intent-message.html
Add these music-player control events:
    http://code.google.com/p/needletagger/source/browse/trunk/NeedleTagger/AndroidManifest.xml?r=5

Exporting the changes made to SD card, so they can be re-applied in bulk
after an OS reinstall (suggested by Jeffrey Lee).

There are other ways that applications can potentially start that are not
based on a broadcast event being sent to a receiver. For example, the account
implementation (see  android.accounts.AccountAuthenticator,
android.content.SyncAdapter) requires a service to be defined with an intent
filter. We cannot really do anything here without breaking the functionality
itself. However, we could show to the user the existence of the service.
The user could be allowed to disable it, but a serious warning would be
necessary. I suggest that something like a thick red border could be used to
ensure the user is aware that this different than the standard "
system application" warning.

Create a tablet version.

A mechanism to send unknown intents to a server so we can add information about
them to the next release.

Add a way to quickly change certain events; via a desktop shortcut, or maybe 
by storing "scenes". This would be useful in cases where an infrequently
used app breaks by disabling events, and you want to quickly enable the events 
specificially for using the app.


Far-Future Ideas, might never be implemented
============================================

Use a enabled/disabled receiver to automatically reload if a package
outside of our app is changed.

Add social features: People can write comments about individual
components, and what effects disabling them had. This would need to include
information about the version etc. We probably would want to work with
the OpenIntents.org database here; we could even act as an automated
data source for OpenIntents by submitting which applications hook into
which broadcast intents.