What architecture for Android app is

This article inspired by few architecture articles about MVP/MVC patterns I sew recently.

Why do we need planning and designing software code, we can just start to write it?
The reason is maintainability and scalability. In order to follow Agile, we have to be able to produce new features within the same amount of time.
So the amount and granularity of independent layers are depending on team size and app complexity.
Tools and libraries that crossing layer’s boundaries are architectural decisions as well. In the case of android dependency of android platform, DI framework and RxJava is usually the case of architectural decisions – we cannot eliminate this dependency easily since many layers and their interconnection depends on it.
There are two edge cases of dividing our project to independent layers and creating abstractions around it – one called mess (unmaintainable) code the other is over engineering. Both are very bad practice.
There is general rule – the more people working on the same codebase in the same time – the more abstract and separated codebase should be.
Example
In a case of the simple music app, high-level design can be something like this:

Few independent cases of business logic and UI layer. These modules should be isolated, but all of them will depend on the framework, all will have app context (bad practice, but unavoidable).
This diagram doesn’t include POJO’s, which is basically data structures in OOP languages, then can be layer specific, but can be shared across all app. It doesn’t include any details of UI layer implementation either.
Is this architecture simple? Yes, this is a simple app so it has simple architecture. I always keep things simple when it possible.
We can present Music Provider Module as Access Checker and Files Provider. If so, they should be more separated.
Implementation details
I prefer using Dagger2 for dependency management, and we can create separate subgraph for each module. Or cannot, all depends on requirements and resources to implement it. It helps to keep them independent as much as possible. At least, when we have less than 20 of these subgraphs and it’s manageable manually -).
Now we can look more closely at the implementation:
UI module:
There is a lot of approaches to implementing UI, and there are more articles about just this aspect (many programmers call it architecture for some reason).
I personally prefer MVP approach, where View entity is responsible for HOW to show data on the entire screen. Is implemented by “framework controller entity” like Activity, Fragment, or Conductor’s Controller. The presenter is responsible for the binding view to the “model” and tells them what and when to show. Don’t be confused with “model” name here, it’s not the data structure (I call data structures POJO), it’s domain module.

Media Player
This is responsible for playing music. This will have service, possibly called DoNotKillMyAppPlease, since this is the responsibility of Service – tell the platform that we do something in the background, when we do, to increase our priority to not being killed.
This module will handle MediaSessionCompat controls to be compatible with all android ecosystem. It will support several playbacks implementation.
It will have a notification with media controls.
But it doesn’t know anything about where this music came from and is user allowed to listen to it.
Music Provider
Will be responsible for restricting access to paid content, grabbing data to the mobile device and providing files or streams to play. It completely independent of media playback and UI. It may interact with UserManager module if users will have their data or may interact with other users. In my case it will share POJOs with other modules just because in this small app creating different POJOs and transform it between layers will be over engineering. It bigger project it does make sense.
Conclusion.
Implementation details provided is NOT an architecture. Architecture is how we divide our software to independent layers and what technologies we bind ourself with globally in order to implement new features fast and with constant speed.