Push Pull

Ratchet? вы уверены? это лишь css фреймворк (с проблемами) + push.js для перехода по страницам + js для модальных окон и slide эффекта.

Ionic - дак он же базируется на Cordova.

так что для вас подойдет только Titanium, какой в деле - неизвестно, но я думаю что он уже готов к использованию.

P.S. судя по комментарию выше я мог не так вас понять, так ли это?

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

Что для начала из теории надо бы: ООП (интерфейсы, абстрактные классы, области видимости, полиморфизм, ...), паттерны (можно для начала хотябы этот маленький пост habrahabr.ru/post/136766/)

Владеете теорией - вперед на амбразуры. Для начала предлагаю ознакомится со стандартной библиотекой и по работать немного с ней. Хотя бы примерно увидеть как можно и когда использовать различные структуры данных.
Затем написать пару прог на Java SE (настольные приложения) c использованием Swing, т.к. в дроиде все равно будут различные Layout'ы и надо примерно представить что это такое и как они порой удобны за счет динамического расставления елементов.
Ознакомиться с XML что это такое и с чем его едят. Для описания интерфейса понадобиться.
Желательно ознакомится с системами сборки Gradle, Ant, желательно в таком порядке, Gradle уже наступает на пятки Ant.
А затем уже можно начинать писать под дроид, благо есть startandroid.ru/ru

С++, Java, Python, Ruby, Js и так далее.
Разработка под Android не ограничивается одной Jav'ой

надеюсь у вас есть какой то общий класс родитель для таких тасков, в его "execute" можно добавить проверку на подключение к интернету, и если его нет, то делать что другое, или ничего.

для проверки наличия соединения:

<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

и

private boolean isNetworkAvailable() {
    ConnectivityManager connectivityManager 
          = (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE);
    NetworkInfo activeNetworkInfo = connectivityManager.getActiveNetworkInfo();
    return activeNetworkInfo != null && activeNetworkInfo.isConnected();
}

Пароль никогда не хранить, но если он шифруется мастер паролем который нигде не записывается, то можно (тут от приложения зависит).
В остальных 99% случаев пароли (шифрованные, хэшированные) хранятся только на серверах,
логин и токен храните, без паролей доступа не будет.
В идеале конечно только токен хранить, но все хотят сделать пользователю жизнь удобнее заранее вводя за него логин.

Интересно, из каких размышлений исходили когда придумали штуку с ApiKey который генерируется 1 раз при регистрации?

Пароль и логин не хранят на клиенте все верно. ApiKey ваш, тоже.
Посмотрите на то как реализована авторизация у сложных систем, ведь у них везде есть токен сессии. Рекомендую и вам его использовать.

Схема такая: на сервере, как то, где то храните токены пользователей. У токена есть время завершения сессии. например пару дней.

При каждом запросе передается этот токен и продлеваете время сессии, на текущее время + ваш срок истечения сессии. Если передали устаревший токен, пишите в лог подозрительные данные.

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