Very cool. But please don't use it. The de-facto architecture design proposed by the Android team is to use fragments for view separation. In my own app development workflow, I have not used multiple activity design for a really long time now. This is what you lose with external routing:
1. Better multiple screen size support: By housing all the fragments in one activity, you have control to hide/show/re-size fragments according to need since you have now have the fragment stack data in one activity. An external router doesn't make sense now, since the internal routing would still need to be handled by the activity. And if you write a router even for the internal stuff, then you need to address other concerns such as: backstack and bundles.
2. Single Top Activities: The Android app stack may have multiple instances of the same activity. When you route with a data path (user/id/1) which activity are you referring to? The Intent and PendingIntent classes have been developed over the years to face such weird idiosyncrasies of the platform.
3. Action Modes: The action mode api helps to create contextual actions. It gives you a nice separation of concern through callbacks. This glues the activity with fragments well. In two calls you setup a fragment and its contextual menus. With external routing you lose that or you handle it with more glue code.<p>I agree there are some cosmetic advantages through external routing, but develop any non-trivial Android app and you will find out, it's not always a good idea to fight the framework. In some cases maybe it is, for e.g this cool project: <a href="https://github.com/mitmel/SimpleContentProvider" rel="nofollow">https://github.com/mitmel/SimpleContentProvider</a>.
Java is already too verbose. Wiring an external router means
handling a lot of concerns yourself. Not cool.