SharedPreferences SharedUserId доступа

я получил два приложения, с этими именами пакетов:SharedPreferences SharedUserId доступа

com.blah.a
com.blah.b

Они получили «com.blah sharedUserId. общий". В/данных/данных в устройстве они оба получили папку с там данных, которая содержит папку shared_prefs и файлы по умолчанию SharedPreferences имени:

com.blah.a_preferences.xml
com.blah.b_preferences .xml

Я знаю, что два приложения с одним и тем же sharedUserId могут обращаться к файлам других. Как я могу прочитать SharedPreferences приложения из приложения b?

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

try { 
    Context c = context.createPackageContext("com.blah.a", 
     Context.CONTEXT_IGNORE_SECURITY)) 

    aPrefs = PreferenceManager.getDefaultSharedPreferences(c); 
} catch (NameNotFoundException e) { 
}

Благодарим за помощь!

источник

2012-03-22 Gabriel Ittner

Как правило, вам не нужно это делать, а sharedUserId - плохая идея для производственных приложений. В любом случае, это код для этого, но вам не нужно указывать IGNORE_SECURITY. Если ваши приложения имеют одинаковый UID, они должны иметь возможность читать друг друга (личные) файлы. Что касается исключения, исключение будет выдаваться только в том случае, если пакет не существует. Вы можете проверить, действительно ли это происходит, и выполнять только код, если он существует (т. Е. Установлено другое приложение). Вероятно, есть кеширование, поэтому вы должны загружать префизы каждый раз, когда они вам понадобятся.

источник

2012-03-22 02:35:50

Хорошо спасибо за ответ. Я попытаюсь заставить его работать с этим методом. Почему sharedUserId имеет плохую идею для производственных приложений? –

Я проверил немного больше. Даже если я загружу предпочтение непосредственно перед его чтением, он не обновляется. Поскольку метод не является надежным, я сохраню значения в таблице с одной строкой в своем ContentProvider. Хотелось бы теперь, почему sharedUserId - плохая идея ... –

ContentProvider звучит хорошо, вы можете иметь мелкомасштабный контроль над тем, какие данные выставлять. Что касается sharedUserId, он, по-видимому, первоначально предназначался только для системных приложений. Цитата: «У вас будет много тонких последствий для вашего приложения, которое вам может не понравиться, - все, что угодно, от всех приложений с одним и тем же общим идентификатором пользователя, вместе взятых для учета использования батареи, чтобы ваши процессы были убиты, когда один из ваши приложения с общим идентификатором пользователя обновляются ». –

SharedPreferences SharedUserId доступа

ответ

Смежные вопросы