StanKo

Вообще тут по собственному усмотрению надо делать.
Можно делать фрагменты со стеком, но ведь боковое меню-то останется при этом доступно и юзер сможет туда зайти и логика аппа поломается, т.е. не забыть отключить боковое меню. Однако при системе фрагментов в стеке есть проблема сохранения этого стека при уходе на фон и возврате (запустил календарь, нажал Home типа случайно или тебе как раз в этот момент внезапно позвонили, вернулся в апп - грабли) или при смене ориентации девайса с портрета на альбом (повернул девайс - грабли), потому что в стеке остается только последний фрагмент в таких случаях.
Соответственно хочется перейти к активити и в данном случае лучше запускать активити на результат (startActivityForResult). Соотв. бокового меню не будет вообще, а стек будет нормально сохраняться. Но вот незадача - фрагмент не имеет метода onActivityResult(), он есть у фрагмент-родительской активити, т.е. придется сооружать Вам тут костыли недюжинные чтобы из активити этот результат передать во фрагмент. Ну, гугл на эту тему подскажет.
Ну, или делать как Вы сами и предлагаете - путем именно замещения фрагментов, 1 фрагмент на стеке сохраняется. Но опять же - как транспортировать целевые данные будете в итоге? Через SharedPreferences? Через БД? А как будете знать что это актуальные данные, а не с прошлого выбора остались?

mock locations - это вообще-то вещь, которую используют при тестировании приложений, а в реале оттуда никто не будет брать координаты.
Вы никак не "обманите проверку железа", т. к. там нет такой проверки. Просто соответствующие службы или сервисы на Вашем устройстве недоступны из-за отсутствия железа. Вот и все. А мапс получает данные именно от этих служб.

Вам для этого придется нанять очень серьезных дивелоперов, т.к. данная задаче в принципе нереализуема на SDK и нерутованном девайсе. В итоге нужны дивелоперы на NDK/С++, которые бы написали нечто подобное. Это будет Вам стоить очень и очень немалых денег, думаю минимально от 10кб (килобаксов).

А если не отвязывать EventBus в onPause(), а только уже в onDestroy()? Да, активити будет на паузе и не отобразит реакции интерфейсно, но отловить и обработать все равно можно будет, да хоть бы и в коллекцию событий закинуть.
PS Google сам заявляет что не стоит использовать их реализацию EventBus (которая в Guavа), поэтому лучше использовать greenrobot-овскую.

мб нарисовать по бокам белые треугольники? Если не подходит, тогда надо смотреть в сторону Matrix transform

согласно описанию сначала в обязалове должен отработать Callback.surfaceCreated - есть такое? ибо в коде не видать.

Почему то статические переменные сохраняются в памяти после перезапуска приложения.

На то есть причина и кроется она в хитром "завершении" приложений в АОС. На самом деле приложения системой не "убиваются" они дальше болтаются в ОЗУ ведра, для "оптимизации" времени повторного запуска этого приложения. Здесь нет видимой логики, как с "вилЬка и тарэлЬка", а статики потому и "выживают". Ваш код, хоть безусловно и неверен из-за использования в статик-поле ссылки на контекст, мог бы работать в принципе, если бы выход из приложения был был реальным выходом, т.е. приложение и всего процессы убивались бы системой, собственно есть для этого костыль, но я его не приведу, чтобы оградить от неправильного программирования.

По-моему все так и должно быть содержимое врапается нормально в скроллл, ведь тот весь экран занимает, иначе надо ограничить высоту TableView до 1 строки, либо ScrollView. Либо юзать ListView.

По сути задача, как я подозреваю, что-то типа надо вывести некий список, но его источник - в интернетах. Поэтому к моменту отработки АТ надо иметь на экране готовый ListView. Для этого надо таки делать что-то типа событийной модели или же модель с интерфейсом и CallBack Method-ом, в последнем случае придется сохранить результат в поле класса, например, и дальше, если GUI построен (onCreateView отработал), то подключить к листу и вывести, если нет, то тогда в конце метода построения GUI проверять а не пусто ли в поле-источнике данных, если есть данные - сразу и подключить. Вообще, кажись, АТ подключается не к фрагменту, а к его активити.

Теоритически если такое приложение и возможно, то только для рутованных девайсов. Тут просматривается слишком уж интеллектуальная задача - блокировать определенные области, да еще же в зависимости от того, что на экране, т.е. пока на экране меню игры, то может получиться ерунда. И еще такое приложение должно давать пользователю обозначить блокируемые области, например, как в программах снятия скриншотов типа LightShot.
Скорее всего такого приложения не существует просто. И единственное что можно сделать - отключатсься от интернета, если это не приводит, в свою очередь, к ограничениям в самой игре.
Тут надо понимать одну простую вещь - в данной игре просто-напросто непродуман интерфейс либо это сделано специально, поэтому это получается проблема разработчика данной игры.

Если говорить о, скажем, картинках, то спасения тут простого нет.
Например, каких размеров картинку не делай и не распихивай по hdpi/xhdpi и тд, но она не будет выглядеть одинаково на экранах с разрешением 800х480 (самый распространненный, особенно у Сасмунг) и 640х960 (например Meizu MX) / 1080х720 (например HTC Rezound), т.к. соотношение сторон у этих экранов разное (1.6(6) и 1.5). Как не масштабируй - либо растянет по ширине, либо по высоте (fitXY), либо придется делать "наезд" с потерей краев (cropCenter). Т.е. просто тулзени, автоматизирующей ресайз под dpi - недостаточно, надо искать компромисс с типом масштабирования ImageView.
Кроме того следует помнить что для ведра картинки, как красная тряпка для быка, можно очень быстро достичь ООМ (Out of memory error). Поэтому советую картинки изначально занижать по разрешению, например для hdpi юзать картинки не больше 640х380 "добивая" растягиванием.