As I once stated in a comment around here, I have seen loads of over-engineering hours wasted by Android dev teams trying to fit a square peg to a round hole: many a times MVP/MVC or other "responsibility containment" patterns refactoring hours are applied to existing, super complex activities that will never be reused; other times applied to super sort activities that need no testing. This cuts 2 of the more relevant benefits of refactoring (testing and reuse). I see technical debt tasks so often, just for the sake of "patternizing" things, without a clear long-term goal (or even a problem to begin with), save for cargo cult programming - 10-file activity modules with 10 LOCs each, when the same could be achieved with 2 or 3 class/interface files providing readable and conceptualizable code still keeping the same testability and re-usability. Even starting something from scratch is no excuse to make it "standardized" - you start with the basics, and when you find reuse/testing/containment problems, you decide to change to a complex approach.
And this is for Android: an already complex, well engineered API that intrinsically forces you to separate responsibilities, and is a reuse/testing heaven. I like most of the SDK and it does look clean. This is so because it provides thousands of official and community documentation pages. You don't see that code and doc quality from small teams that define set standards and work on a fraction of Google's budget (read: more man-month AND more punch per "man"). All in all, most benefits of advanced software engineering are lost, in practice, when applied by small software houses. This is why I believe that even though patterns have a purpose, its benefits are tightly coupled with good judgement of its usage. Over-engineering is a serious disease in the industry.