android-guidelines | Project Guidelines for the Android Buffer App | Android library

You can have a Presenter without the need of having a view explicitly linked to that Presenter. In other words, you can have a presenter only to encapsulate some logical. In your case, you can have a presenter that only knows how to fetch and provide some images. And your view can make use of this specific presenter.

I did not get why would you have to pass the context to the model.

Right now, my idea is to add the web service request logic on the Model (I'm also using the Repository pattern) and the download logic on the Presenter. Something like this (the code is just an example):

You could do that. However, it seems more like MVVM where you put logical into Model and the Model knows how to fetch data.

In your case, you want to follow MVP, so the model only holds data (pieces of information/data). So, you can have one Presenter that knows how to download your images. And you can have some Utils that could help you with the request part. You can have another model for that Presenter that download images for saving your images, like a cache. And, again if you want to make some sort of cache logic, you should do on the same presenter that knows how to download an image. Or, if it becoming too big and complex, you can make a Presenter that only knows hot to cache stuff.

Once your Presenter only knows how to download an image, or only knows how to save an image. You can test it easy, just pass a link to your Presenter method and check if it could handle download the image.

Note: I did not understand how could be convenient or important you pass context for your model unless it knows some sort of cache using Android preferences?

NOTE 2: I would love if I could unit test this part of the app (Mocking the DownloadManager). So, passing the Context to the Model is not an option, as it breaks the MVP (IMHO) and would be much harder to unit test it.