Rustem Saitkulov

Вероятность, что вы придумаете какой-то продукт с высокой виральностью - крайне низка.
Если вы планируете построить бизнес с самоокупаемостью, монетизацией - важнее уметь выводить даже плохой продукт в реальный рынок и конвертировать ваших пользователей в платящих клиентов.
Для этого важнее изучать ЦА, ее предпочтения/потребности и ваши маркетинг возможности:
"Цифровой маркетинг" Кент Вертайм, Ян Фенвик
"Повышение эффективности интернет-рекламы" Тим Эш.
"Ключевые принципы повышения конверсии веб-сайта." Брайан Айзенберг.
"Взлом маркетинга." Фил Барден.
"Стратегия голубого океана" Ким Чан, Рехе Моборн

Главные минусы AsyncTask-ов:
- утечка памяти (хранит ссылку на контекст)
- у API не предусмотрена обработка ошибки
- нет привязки к жизненному циклу
- работа только с одним потоком, который не кастомизировать

Использовать можно, но только для простых коротких операций и очень аккуратно

В качестве достойной альтернативы уже больше года рекомендуется использовать RxJava + RxAndroid

Это охват. Чем более старую версию вы выберите в качестве минимальной, тем большему количеству устройств будет доступно ваше приложение.

Fiddler (Windows/Linux)
Charlesproxy (Mac)

Фичеринг на Product Hunt, но на самом деле этл все еще только капля в море, однако для старта и проверки продукта вариант хороший

Кстати в Telegram появился канал с новостями и полезными ссылками для Android разработчиков https://telegram.me/AndroidResId

Попробуйте применять TDD, так быстрее узкие места текущей архитектуры выявить.

Нет.
https://vk.com/dev/mobile_apps
https://vk.com/dev/android_sdk

Еще вариант - структуру данных "Queue" реализовать в виде таблицы БД (логику работы этой несложной структуры - в отдельном классе) и не надо никакой сериализации, работаем с классом как с оберткой. Доступ через ч/з стат. методы класса, либо проинжектить через DI (Dagger2 например).

P.S. если у кого есть возражения, пишите каментом, интересно обсудить.

В вашем вопрос недостаточно данных для ответа.

Всегда будет вопрос: правильная архитектура для чего именно?

ИМХО нужно всегда держать в запасе (и поддерживать) пачку своих архитектурных проектов-шаблонов, осознавать плюсы/минусы того или иного подхода и применять в зависимости от особенностей проекта.
В большинстве случаев решение по архитектуре пляшет от конкретных задач проекта.

P.S. Кстати, если вы по отдельности тут опубликуете свои под-вопросы, вы с большей вероятностью получите менее абстрактные ответы.

Пусть WebView живет во фрагменте, тогда при повороте не будет изменений, но вам придется логику переписать. Простых путей сохранения состояния WebView нет.

Поставить первым экраном сплеш/лаунчер скрин с лого и там реализовать нужную логику.

Content Provider - сущность, являющаяся независимой оберткой над источниками данных (бизнес-логика приложения может даже не знать как именно она устроена: БД, файлы, сервер или еще что-то), которая также следует REST-подобной архитектуре и стремится привести данные в обобщенный тип.

Кратко можно тут ознакомиться habrahabr.ru/post/132720

P.S. Почему в документации пишут далеко не все достоинства Content Providers - непонятно, объяснений не встречал, но тема там крайне плохо раскрыта, т.к. у этой сущности много интересных особенностей: например в документации ни слова о том, что они использовались для реализации классических A, B, C паттернов by Virgil Dobjanschi (конференция Google IO 2010 www.youtube.com/watch?v=xHXn3Kg2IQE ).
Тема на самом деле очень обширна, в одном абзаце это не раскрыть, вам нужно изучать/практиковать. Актуальность на сегодня контент провайдеры не потеряли, даже наоборот.

Однако существует таки готовое решение quickblox.com/developers/SimpleSample-location_use...

https://f-droid.org/

Используйте CoordinatorLayout, AppBarLayout, Toolbar как тут например
stackoverflow.com/questions/32398500/toolbar-in-ap...

kpfu.ru/itis