Приложение аварийно завершает работу с ClassCastException при тестировании класса приложения M резервной копии

Я следую руководству, чтобы указать исключения из полных резервных копий, но сталкиваюсь с сбоем, когда пытаюсь его протестировать.

$ adb shell bmgr fullbackup <PACKAGE>

Работает нормально - файлы исключены, как и ожидалось.

Я очищаю данные, затем запускаю:

$ adb shell bmgr restore <PACKAGE>

Восстановление работает нормально, но в следующий раз, когда я пытаюсь запустить приложение, я получаю ClassCastException:

Caused by: java.lang.ClassCastException: android.app.Application cannot be cast to com.domain.app.MyCustomApplicationClass

Похоже, что по какой-то причине есть экземпляр моего приложения, но это не экземпляр пользовательского класса приложения, как указано в манифесте.

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

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

1 ответ

Обычной причиной этого является ручное восстановление "неправильным путем". Боюсь, это очень плохо документировано, но существуют разные способы вызова "восстановления bmgr", один из которых вызовет именно ту проблему, которую вы описываете.

(Проблема, в частности, заключается в том, что для операций полного резервного копирования / восстановления данных в настоящее время требуется, чтобы приложение запускалось без создания провайдеров контента или какого-либо определенного приложения подкласса приложения; вместо этого вы работаете с экземпляром приложения базового класса. приведение к вашему объявленному подклассу вызывает исключение ClassCastException, как вы можете себе представить.)

В обычном порядке ваше приложение уничтожается после восстановления. ОДНАКО, если вы запускаете восстановление следующим образом:

adb shell bmgr restore PACKAGE

этого не происходит Этот конкретный синтаксис вызова запускает "мое приложение хочет восстановить свои данные" вживую "прямо сейчас; не убивайте меня до или после" пути кода, который вы получаете через BackupManager.requestRestore(), В этом пути кода приложение намеренно не уничтожается после восстановления. Это артефакт того времени, когда ключ / значение было единственной парадигмой резервного копирования / восстановления, и в этой парадигме нет таких проблем подкласса приложения и т. Д.

Вам нужно убедиться, что при запуске восстановления через bmgr вы используете полный синтаксис:

adb shell bmgr restore TOKEN PACKAGE

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

" TOKEN " - это идентификатор набора данных, содержащего данные, которые вы хотите восстановить. Если вы используете локальный транспорт для отладки, то TOKEN всегда равен "1". Если вы используете облачное резервное копирование, то это будет собственный текущий идентификатор набора резервных данных устройства, если таковой имеется, или наследственный набор данных, если устройство не сгенерировало его самостоятельно. Вы можете увидеть это в выводе

adb shell dumpsys backup | egrep 'Current:|Ancestral:'

Идентификатор TOKEN в наборе данных - это шестнадцатеричная строка, указанная там.

Другие вопросы по тегам