Зависимость обновили, приложение собралось, вход и сохранение сессии работают. Можно выпускать? На тестовом устройстве была чистая установка. У пользователя — данные, записанные год назад другой версией библиотеки. Их новая сборка ещё не читала.

У flutter_secure_storage в v11 убрана поддержка прежних алгоритмов шифрования и EncryptedSharedPreferences. Такие данные сначала нужно перенести через v10. Команда может выпустить обе версии в нужном порядке. Только пользователь не обязан устанавливать каждую.

В опыте ArkTelos Lab проверен переход 9.2.4 → 10.3.2 → 11.2.0 на Android 15. Сборки ставились поверх прежних, без очистки данных и автоматического сброса при ошибке. Старая запись прочиталась в 11.2.0 после реального обращения к хранилищу в промежуточной сборке. Простая установка 10.3.2 не помогла. Открытие её экрана без чтения — тоже.

Приложение запускалось. Миграция — нет.

При прямом переходе с 9.2.4 диагностика обнаружила нечитаемую запись. Это не доказательство уничтожения данных: новая реализация сообщила, что не может их прочитать, а стенд остановил дальнейший доступ.

Собственный storageVersion кажется решением, пока не уточнить, версию чего он обозначает. Версия пакета говорит, какой код исполняется. Механизм хранения определяет алгоритмы, ключи и служебные отметки. Прикладная схема описывает содержимое записи. Число в настройках не возвращает библиотеке удалённый алгоритм.

В стенде сначала проверяется возможность доступа через checkUpgradeStatus(), затем — собственный формат. Метод ничего не переносит; даже его ok нельзя принимать без учёта причины unsupportedPlatform. Для одной строки новый формат содержит схему и значение, сохраняется под отдельным ключом и читается обратно для сравнения с исходником.

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

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

Тогда выбор — сохранить совместимое чтение в реально получаемой сборке либо подготовить допустимое восстановление. Повторный вход подходит для заменяемого токена. Единственный ключ к локальным данным он не вернёт.

Отсрочка тоже имеет цену: нужные исправления остаются недоступны. В v11.2.0 исправлены биометрические сценарии и область действия deleteAll; Android-реализация требует минимум API 24. Проверить надо и данные, и поддерживаемые устройства.

История релизов команды не равна истории миграций на устройстве. Даже поэтапный выпуск не решает проблему человека, вернувшегося со старой установкой через месяц.

Опыт ограничен одним Android-образом, без биометрии, EncryptedSharedPreferences, облачного восстановления и отключения питания. Он даёт конкретную причину отложить обновление: подготовить путь со старых данных. У «не трогать, пока работает» такого условия завершения нет.

Перед обновлением стоит сверить эти пути со своим приложением. В полном разборе — код, таблица и ограничения: https://labs.arktelos.dev/ru/articles/dependency-upgrade/ Исходники: https://gitlab.com/open8381011/experiments/storage-upgrade-trial ArkTelos: https://arktelos.dev Lab RU: https://t.me/arktelos_lab_ru Lab EN: https://t.me/arktelos_lab