Best practice for package structure in an MVP project

Your problem is just only UI part of MVP architectural pattern. Which is View classes along with their corresponding Presenters. And the better solution is the first approach.

App should have package according to features, NOT by the common functionality. We should group together the classes which are getting changed/modify together.

Some developers group source code by layer - like the second approach - because they want to keep the same package structure for ALL the projects they work on. But that is bad decision because it's always HARD to find classes when they are grouped only because they share same parent classes!

Ex: For activities, some developers put them in activity package because all activities extends Activity class. It makes sense because this is activity-ONLY package, BUT it is hard to go through those packages.

For more information, see: android-mvp-architecture and this S.O answer