Как хранятся сессионные данные

Что проверяют

Понимаете ли вы, что «сессия» в Android это несколько разных вещей: токены авторизации, состояние экрана и кеш данных, и у каждой своё место и свой срок жизни. Следом почти всегда спрашивают, как вы защищаете токен и что происходит при выходе из аккаунта.

Как отвечать

Разложите данные по типу и сроку жизни:

• состояние экрана: живёт в ViewModel, а то, что должно пережить смерть процесса, кладётся в SavedStateHandle или rememberSaveable. Туда идут идентификаторы и введённый текст, но не большие объекты;
• настройки и флаги: DataStore (Preferences или Proto). SharedPreferences ещё встречается, но DataStore асинхронный, отдаёт данные через Flow и не блокирует главный поток;
• токены: access token можно держать в памяти, refresh token хранить зашифрованным. Ключ создаётся в Android Keystore и из него не извлекается, а шифруете вы сами или через Tink. EncryptedSharedPreferences из androidx.security:security-crypto помечена устаревшей, в новом коде на неё не опираются;
• структурированные данные сессии: история, черновики, кеш ответов. Это Room, а не ручной SQLiteOpenHelper.

Отдельно скажите про выход: очистить DataStore, вызвать clearAllTables() у базы, отменить задачи WorkManager, сбросить куки и кеш HTTP-клиента. И про резервные копии: без правил dataExtractionRules (или fullBackupContent для старых версий) Auto Backup унесёт файл с токеном в облако и восстановит его на другом устройстве.

Где спотыкаются

Хранят токен открытым текстом в SharedPreferences и считают, что MODE_PRIVATE его защищает. На рутованном устройстве и в резервной копии файл читается как есть.

Путают состояние экрана с сессией пользователя: держат токен только в ViewModel и удивляются разлогину после того, как система убила процесс в фоне.

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