Composition over InheritanceWhat it means for your Activities
So we've all heard the suggestion that we should prefer composition over inheritance. For those that haven't, the idea is classes should only inherit from classes if they can fully stand in for their parent class, not just to share some behavior (more information at ). Despite this, I can't count how many Android projects I've been on/seen that had some BaseActivity that all of their Activities must extend from.
This can be problematic on a few fronts. The most obvious is that when Joe Newguy comes in and adds ShinyFeatureActivity, there's nothing forcing him to make sure it extends BaseActivity. Hopefully it's caught in code review. Additionally, it prevents you from extending from any other Activity class (E.g. PreferenceActivity, ListActivity...). Many of these Activity subtypes have been replaced by Fragment subtypes, but not all. Some libraries might also need their own Activity subtype.
Somewhat more insidious is that you might have some behaviors that are used in several of your Activities, and another set of behaviors for another group of Activities. Since Java doesn't support multi-inheritance, you have no choice but to put all of the behaviors into a single base class if these groups overlap. That means reduced maintainability, and possibly some performance penalties.
It's easy to see why we like to do this. Code reuse is a good thing, right? And much of our common logic needs to happen at specific points in the Activity lifecycle. Application.ActivityLifecycleCallbacks can be a pain to work with (they're passed Activities rather than living in them) and likely need to be registered in Application.onCreate() which we try to avoid.
This is where headless Fragments come in. While a lot of Android developers think of Fragments as UI components, they're really more lifecycle components. So what do I mean by "headless"? Just that onCreateView() either isn't overridden or returns null. Essentially, these are Fragments that implement some process or control that doesn't have a UI itself.
To differentiate my headless Fragments from my View oriented Fragments, I've taken to suffixing my headless Fragments with "Helper" and other Fragments with "Fragment". For example, AnalyticsHelper would be a headless Fragment for attaching my analytics logic, while HeaderFragment shows a header View for something. This is totally optional, but I've found it helpful.
Since there is no UI for these Fragments, there is no layout ID necessary to inflate into or animations to worry about, so your factory methods can be smarter and more controlled. For that matter, they can handle adding the Fragment themselves. I've created a gist  that shows how to do this. In Android Studio, you can add this to the "File and Code Templates" section in settings, and when you create a new class (New -> Java Class), select it in the "Kind" dropdown.
Adding FooHelper to its parent is as simple as calling FooHelper.attach(this). You'll get compiler errors telling you if the parent doesn't implement FooHelper's callback interface, and if attach() had already been called, it will return the preexisting fragment. The gist includes overloads for framework Fragments and Activities, but switching them to use support Fragments and FragmentActivity is pretty trivial. It also includes a getParent() that is a simplified version of my FragmentUtils.getParent() gist .
Obviously headless Fragments are more useful than just getting stuff out of your BaseActivity. They're also great for encapsulating processes that need lifecycle callbacks (or onActivityResult(), or a child FragmentManager...). The great thing about replacing BaseActivity, though, is that now you can split up the "common" logic onto single-purpose modular components, and decide for each Activity which modules you actually need. If most of your Activities need a lot of the same modules there's no reason you couldn't write a CommonComponentsHelper to pull them in, but now you're not forced to keep all your common dependencies in one base class.