Android 4.4 KitKat - возвращение SharedPreferences INSTALL_FAILED_SHARED_USER_INCOMPATIBLE
Я уже некоторое время работаю над проектом, нацеленным на минимум 4,0 ICS. Недавно я получил новый Play Edition Moto G, который после запуска всех обновлений работает под управлением 4.4 (KK). Поэтому я решил, что хочу попробовать развернуть на нем программу, а также два других тестовых устройства, которые у меня есть.
Все шло хорошо, пока моя программа не достигла точки, где она пыталась получить доступ к SharedPreference через PreferenceManager.getDefaultSharedPreferences(Context). После отладки и выполнения каждого кадра я смог выяснить, что значения на самом деле записываются в файл настроек (или, по крайней мере, так оно и есть, поскольку контейнер Map в объекте SharedPreference содержит значения, которые я поместил туда ранее). Однако, когда я пытаюсь прочитать любое из значений с их соответствующими ключами, я получаю вместо этого значение INSTALL_FAILED_SHARED_USER_INCOMPATIBLE, что приводит к сбою моей программы (не напрямую, а к вызывающим функциям, которые требуют правильного вывода из Preferences для сбоя). Это происходит только на 4.4, насколько мне известно.
Я искал сеть и ТАК для ответов на этот вопрос, и я не могу найти ничего, что решило бы мою проблему. Мой манифест не объявляет sharedUserId или sharedUserLabel, поэтому я не думаю, что это будет причиной проблемы. Я несколько раз удалял и переустанавливал пакет, но безрезультатно. У меня сложилось впечатление, что файл XML, используемый для SharedPreference, был записан в локальный каталог программы, который, как я понял, предоставлял как минимум доступ для чтения / записи самой программой (если только это не изменилось в 4.4). И, похоже, он не хранит это местоположение на внешнем источнике, поскольку в Moto G нет SD-карты.
У кого-нибудь есть идеи, как обойти это? В настоящее время моя программа не может быть развернута на устройствах 4.4, и мне бы очень хотелось, чтобы этого не произошло.
1 ответ
Так что после некоторого сна я в конце концов понял свою проблему. Это был кульминационный момент нескольких бессвязных SO-сообщений и столько же почти бесполезных поисков в Google.
Некоторые из моих предпочтений должны быть зашифрованы до того, как они будут записаны в файл, и, очевидно, начиная с версии 4.2 Android использует OpenSSL в качестве нового поставщика безопасности вместо традиционного Crypto. Поэтому, потратив несколько дней на исследования, я смог решить свою проблему, обеспечив принудительное использование Crypto SP и более четко указав алгоритм / режим / заполнение шифрования и преобразования, чтобы помочь не только согласовать размер блока, но и сделать его более ясно, что происходит вместо того, чтобы позволить API определять, что может быть лучшим. В этом случае, даже после принудительного применения Crypto, он все еще был сломан, поэтому дальнейшее копание в A/M/P.
Так что моей первоначальной проблемой было замаскирование действительного исключения, и было очень интересно это выяснить.