Rou1997

какими пакетами

В основном используется протокол HTTP, формат ответов - обычно JSON, запросов - JSON или кодирование URL, все это можно увидеть с помощью сниффера (Fiddler, Wireshark и т.п.), еще можно декомпилировать, дизассемблировать само приложение.

Возможно, поможет разобраться:
codeproject.com/Tips/1018322/Android-Using-SQLite-...

Еще, в принципе, с SQLite на Android можно работать через JDBC (как и на других ОС), но это нежелательно:
www.codeproject.com/Tips/815186/Java-JDBC-SQLite-R...

Статический класс-контейнер, уж более быстрого и легковесного варианта быть не может.

придется в каждом onCreate тратить ресурсы и время

Посчитайте, сколько конкретно ресурсов и времени, скорее всего, окажется совсем не критично.

Не понимаю, зачем вам DOMContentLoaded, почему не window.onload, лямбда тоже смущает, а click наверно обрабатываете неправильно, вообще я бы попробовал jQuery, он же кроссбраузерный.

Нет идеального, Genymotion (VirtualBox) быстрый, но он x86, а на устройствах обычно arm, поэтому в приложениях нативные библиотеки делают прежде всего для arm, и иногда им и ограничиваются, из-за этого на Genymotion некоторые приложения вообще не запустятся, а стандартный (AVD) очень медленный, зато есть и для arm.

То, у которого есть соответствующее разрешение (permission), а еще, если понимаете в программировании, то можно довольно легко декомпилировать, и посмотреть.

Если есть возможность напрямую подключаться к базе данных сервера, а не через API (HTTP), то за локальную базу лучше взять такую же, как и на сервере, например, локально поднять MySQL (через JDBC), а не использовать SQLite - классическую встраиваемую (локальную) БД для Android, которая отличается синтаксисом запросов и т.п.

если да приложение будет стабилно работать...

Зависит от приложения, для одних подобные фреймворки подходят, для других нет.
Стабильность тут ни при чем, просто не всё можно и имеет смысл писать на этих фреймворках.

или это будеть потерии времини

А это зависит от планов на будущее, если будете создавать те приложения, для которых подходят Cordova и Ionic, то это не будет потерей времени.

То, что в браузере (HTML & CSS & JS) - это клиент, вам нужно свой клиент сделать, взаимодействующий с сервером, как оригинал.
HTTP курите, и Fiddler или Wireshark используйте, если F12 в браузере недостаточно.

Если нужно просто страницу с сайта вывести в приложении, то WebView достаточно, еще PhoneGap можно использовать для удобной "конвертации" веб-клиента в приложение.

Заменить Layout наверняка можно с помощью setContentView, как в onCreate, но эти кнопки при этом исчезнут, поскольку они тоже в одном из Layout, а еще надо слушать (обрабатывать события) элементов с каждого из трех Layout, вы все это хотите смешать в кучу в одном классе Activity, и потом путаться?

Это абсурд, сделайте три Activity, или 1 Activity с 3 кнопками (кнопки понадобятся только в одном Layout) и с 3 Fragment, которые переключаются кнопками.

как без рута вытащить лог с ошибками с телефона

Разрешить на нем отладку по USB, подключить его по USB к компьютеру, и там смотреть LogCat, для этого есть утилиты, или можно самому написать по-быстрому.

возможно такого способа нет

Такой способ есть, вместо HTTP нужно использовать непосредственно TCP/IP, устанавливаем соединение, и сервер, когда хочет, шлет пакет устройству, и устройство тоже так может со своей стороны, нет никакой необходимости слать пакет (запрос), чтобы получить ответный пакет.
Или хотя бы использовать Long Polling, это долгое, а не частое опрашивание, так снижается частота запросов, это намного проще сделать, при этом сервер по-прежнему остается HTTP-сервером, но лучше TCP/IP.

Какой из вариантов предпочтительней?

Очевидно, что первый, меньше нагрузка на сеть и на процессор, нет "бесполезной" нагрузки на сеть, думаю, что батарея будет разряжаться насколько-то медленнее.

VK SDK - это обертка над VK API, поэтому смотрите здесь: https://vk.com/dev/
В любом случае, можно реализовать без API, но это трудоемко, и в любой момент может перестать работать, потребуется обновление, насчет Google Play тоже сомнения в таком случае, хотя, он вроде бы только жалобы обрабатывает.

Что означает эта загадочная аббревиатура - BODY?
Всего-навсего передачу данных в теле POST-запроса в формате JSON, вместо url encoded?

"В чем преимущества передачи данных методом"
У JSON основное преимущество - для вложенных структур (или структур, которые пока не вложенные, но в процессе доработки функционала могут стать таковыми), в остальных случаях он будет замедлять работу, так как лишние байты в запросе, + парсинг.

"есть ли методы распарсить строку на значение-люч"
Средства для парсинга JSON почти под любой язык программирования уже есть.

"1. Почему никто толком не может объяснить, зачем rx в Android-е?"
Потому что им сказали - надо использовать, они используют, им не объясняли, и они не дошли до этого сами, поэтому не понимают, и вам объяснить не могут.
Видимо, это одна из проблем "умных книжек", их авторы доносят до читателя мысль, но не заботятся об ее объяснении, вот и получаются "зомби", бездумно скандирующие лозунги.
А вы - дойдите. Сравните с ним и без него, подумайте, для каких задач он хорошо подходит.
Используйте это в своей работе, и другим потом объясняйте.

"2. Неужели Android SDK так убог, что нет альтернатив?"
Очень убог, был бы у вас шире кругозор, вы бы просто поражались с него.

"Какая асинхронность??? - если её в принципе в Activity и Fragments не должно быть?"
Как это не должно быть? Скорее - наоборот, любой качественный UI должен быть асинхронным, то есть все тяжелые операции - в потоке, отдельном от UI.

"классические проблемы Android разработки"
По мне, основная проблема разработки под Android - это то, что пишешь много, а делаешь мало (как девиз jQuery, только наоборот). Библиотеки очень многословны, IDE - не заточены под Rapid Application Development.
Может быть, Rx частично решает эту проблему в некоторых случаях?

Нет необходимости ничего в ней знать, всё равно по ходу все изучите, точно так же, как если бы писали под Desktop.

Но, конечно, опыт не помешает, навыки работы с IDE и несколькими стандартными классами (их весьма мало) ускорят изучение Android.
А если вы изначально на C# на Windows Desktop программировали, то вам будет проще с удобной и простой IDE перейти на сложные и навороченные, такие, как Eclipse и Android Studio. Еще C# на Windows Desktop имеет самые лучшие средства для GUI и др., многое можно взять оттуда и применять на Android, можно свой фреймворк писать потихоньку, "шарповские" концепции RAD помогут ускорить разработку (если, конечно, вам это надо - и ваши работодатели не против этого, а то некоторые боятся, это боязнь всего нового).

Лично я такие вопросы решаю в зависимости от того, насколько срочно мне нужно начать этим направлением зарабатывать деньги.
Сейчас осваиваю Apple, денег уже имею достаточно для жизни, потому никуда не тороплюсь.
А когда только-только начинал (как раз Android осваивал), то не ждал у моря погоды.

Еще имеет значение, чем именно будете заниматься на Android.
Может это разработка игр, там вообще всё иначе.

А вот от чтения Герберт Шилдта и любой другой книги нет никакого толку вообще, так как без личного опыта вы ничего оттуда толком не усвоите и не запомните.

чтобы там не рассказывалось про ListView и прочие deprecated вещи

Что, простите?
ListView уже не комильфо? Как так? Почему? На Android очень мало контролов, если еще и умышленно ограничивать себя, это нужно совсем уж крышей поехать.

Есть ли какое либо "красивое" решение подобной задачи?

Есть, создать свой кастомный View, внутри которого скрыть всю это не радующую глаз логику.

Поверьте мне, на самом деле костылей в вашем коде гораздо больше. Если вы хоть раз печатали findViewById пальцами по клавиатуре, то это тоже костыль по сравнению с кое-чем. Да, есть такая параллельная вселенная, где это делается автоматически))
Так что, надо расставлять приоритеты, и смотреть на вещи реально, потому что все костыли сразу - не победить.

При переходе между Activity используется Intent, у него метод setData (и, кажется, getData), через них и ложат/забирают данные. Гуглите, и найдете не только код, но и туториалы, кажется, у Климова был.