The current GalleryActivity is a proof-of-concept for working with the game data and other backend machinery. But it shouldn't inhibit the ultimate design. As you say, there are various pros and cons to subclassing different built-in android classes, and those should be explored freely. My guess is that the best gallery implementation will evolve largely from the ground up after taking account of the overarching design goals and requirements.
I know memory management for the loaded bitmaps could be important, and the current stand-in does nothing about that. I don't know all the options available, but I have heard RecyclerView mentioned more than once on these forums, as a possible starting point.
Deriving from PreferenceActivity is handy and streamlines development for certain types of UIs like SettingsGlobalActivity, which don't need to be fancy but should be easy to maintain and extend. A version 3 GalleryActivity doesn't seem like a good fit for subclassing PreferenceActivity, so I certainly would not let that constrain you. The NativeActivity is only subclassed for the Xperia Play variant of the GameActivity, since that is the only way to access that device's touchpad input. I don't see any need to change anything in the GameActivity, at least for the time being. The nice thing about the current design is that the activities are well decoupled, so the GalleryActivity can be developed in pretty much complete isolation. So I say focus on a new GalleryActiivity.
The PlayMenuActivity is also not set in stone, and should be seen as subordinate to the design of the GalleryActivity. I.e. PlayMenuActivity currently provides complementary game-specific functionality not found in the current GalleryActivity. Feel free to move functionality between PlayMenuActivity and GalleryActivity, as you ponder the best design for GalleryActivity.