Hi Sean, this wasn’t so much an issue as much as it was a improvement-suggestion.
However, I have been activelly tracking UE4 android support since… well, before 4.0 went public. And with so many different hardware packages out there, I merely “suggested” that UE4 “borrows” some of Genymotion’s device-specific details while configuring the project for Android support, but I realize that such a statement was out of place.
As far as I’m concerned - the question can be closed. But the underlying question that was asked, which goes “normally, android games are many similar but slightly different games, each tailored with certain optimizations to make most use of the hardware+software stack” and my view so far (having based it since 4.0 to 4.6 preview so far) is that UE4 might be more fitting for the catch-all solution, rather than all these slightly-different-but-mostly-the-same projects which are finely abstracted away from the user (and sight!) by Google Play.
The example I used was based on a any Angry Birds game, which seems like just one game, but in reality, is 70 mostly-same-but-slightly-different games all sharing a similar name but containing different optimizaton combos to make best use of the hardware/software stack in question.
To further elaborate, the catch-all solution works equally bad across most Android devices, but will surely work. Then, as certain devices are targeted in order of popularity, the first specific version might tackle issues found only on Nexus S phones, while the in-game patch log will mention “added support for Nexus S” or similar. Over time, that number grows up, and even the users still consider it as ‘one project’, developers do and have to know that it’s not one project. In this case, it’s now two projects, one targeting all devices except Nexus S, and one targeting Nexus S specifically. Thanks to Google Play’s specifics, the two projects still appear as they are just one. However, they are not 