An Activity or a Fragment is where you handle the logic of updating views with model data. However, they are tighly coupled with the Android's framework.
Are these classes already presenters?
Bonus: Is it overengineering to design exclusive presenter classes that are not coupled with the framework?
Consider scenarios where classes like REST API client and local database manager (Both singleton injected via IoC container) are dependencies for a presenter
A framework, by its nature, pervades your application, or better, is all around it, and you don't have much choice if you want to program Android.
By what I read on Wikipedia, yes, Activities/Fragments are presenters, being the middleman between the view and the core of your application. You could extract the "controller" part from them by taking out the listener implementations, but updating the views still requires knowing which value goes into which widget and how to set it... you have to get dirty with the framework at some point.
Even the implementation of your REST API client might be framework dependent, as Android has its own http connection tools IIRC, same for local db. What you can (and should!) surely make framework-independent is the core, business logic of your application (e.g. the board model and rules of a chess game, the "top scores" service, "save game" one...) In this core you would define also the interfaces (i.e. what you expect to get from them) of the REST client and db manager.
Like you say, the presenters should just be clients of such core API, but I don't see how they can be decoupled from the framework, as they're what binds your core with Android.
