As things go I am releasing a middleware platform called TyphonRT for Android soon that definitely addresses your design concern.
Indeed this is a good example of how a component oriented architecture like TyphonRT shines. Essentially there is a "lifecycle component" and this class mirrors all the Activity methods. The base TyphonActivity manages lifecycle components and delegates calling the appropriate methods when invoked by an Activity via iteration. For ListActivity and any other specialized base Activity in the Android API there are likewise extended lifecycle components with the additional ListActivity or specialized methods defined by the given Activity.
What you can do to solve your problem with TyphonRT is create a custom lifecycle component extending the base type and add any custom logic you need to handle for the Activitiy methods. You can also add your protected methods and any other methods in your custom lifecycle component. You can then create a new TyphonActivity (Activity w/ component management & essential iteration) or a TyphonListActivity (ListActivity w/ component management & iteration) and simply slot in one or more custom components into either.
Even better is that there is an additional XML configuration file for TyphonRT to be able to declaratively specificy components to load and you can filter based on Android OS version, device family/name, screen size, and many other parameters thus being able to provide differentiation across the Android ecosystem without having to embed conditional logic in the codebase itself.
I've been working hard on TyphonRT for quite some time, but a semi-public release is coming soon with a likely full public launch by end of Q2. Drop me an email at the contact address http://www.typhonrt.org/
and I'll let you know when the semi-public release is available.
The essential pattern I described above though is a good way to solve your design problem though.