Об открытости данных в Android-приложениях

[akira]

Интересная статья о #androiddev и не how to, спасибо.

[Propheta13]

В случае сервиса я бы еще указал android:permission. Если сервис должен быть доступен не только вашему приложению — вещь не лишняя.
Пример:
<service android:name=".MyService" android:process="example.service" android:exported="true" android:label="@string/app_name" android:permission="com.sec.example.service.ACCESS"> <intent-filter> <action android:name="com.sec.sec.example.service.MyService" /> </intent-filter> </service>

[Propheta13]

Еще рекомендую обратить внимание на поле android:process. Если перед названием процесса поставить ":" он будет доступен только приложению поставляемому с сервисом.
P.S. Извиняюсь за код, отформатировался криво(

[forceLain]

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

[knott]

Тут кстати интересный вопрос возникает, который я все никак немогу проверить.

Есть два приложения:
Первое приложение декларирует компонент, скажем Activity и защищает его своим кастомным permission.
Второе приложение использует этот компонент причем честно запрашивая этот permission.

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

Вопрос в том, что будет, если сначала установится второе приложение, а лишь затем первое?

[zyrik]

Так здесь же описывается, как защитить свое приложение от того, чтобы к нему не подключались другие. Как мне кажется, в этом случае лучше использовать разрешения с уровнем signature. В этом случае, только приложения подписанные вашим ключом смогут получать доступ к компонентам, защищенным данным разрешением.

Пользователю показываются только разрешения, у которых уровень соответствует dangerous.

[grishkaa]

Можно поставить protectionLevel=«signature» и тогда никакому другому приложению это разрешение не дадут, даже если оно прописано у него в манифесте. Единственный способ получить разрешение с таким параметром из другого приложения — подписать другое приложение тем же сертификатом, которым подписано главное.

[lola_term]

Интересно, зачем нужны права на доступ? а именно:
к управлению сетями, личная информация, учетные записи — обычному приложению, допустим тому же официальному Chrome для андроид с PlayMarket
или FireFox открывает известные учетные записи, проверяет доступ к защищенному хранилищу, управление глобальными параметрами системы, запись звука, полный доступ к интернету управление NFC

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

[Newbilius]

Риторический вопрос. Первую его часть лучше задать авторам конкретных приложений (тот же доступ в сеть часто нужен для рекламных баннеров), а вторую — авторам ОС. :)

[forceLain]

Со второй частью вопроса как раз все понятно: Android старается предоставить возможность по максимуму заменить свои стандартные компоненты. Если бы приложение каждый раз запрашивало доступ к СМС, например, вместо того, что бы однажды и навсегда получить этот доступ (как оно сейчас есть), то невозможно было бы заменить стандартный СМС мессенджер. Он бы попросту каждый раз при получении СМС запрашивал доступ у пользователя, что бы её прочитать.

[zagayevskiy]

Если бы приложение каждый раз запрашивало доступ к СМС, например, вместо того, что бы однажды и навсегда получить этот доступ (как оно сейчас есть), то невозможно было бы заменить стандартный СМС мессенджер. Он бы попросту каждый раз при получении СМС запрашивал доступ у пользователя, что бы её прочитать.

Можно ведь запросить один раз (при первом СМС, например) и в дальнейшем не спрашивать. И в каком-то из обновлений 4.2+ так и было, ЕМНИП. А потом возможность просто убрали.

[forceLain]

Ну так а чем это будет отличаться от «запросить один раз при установке» как сейчас? :)

[zagayevskiy]

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

[forceLain]

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

[zyrik]

Поищите приложение AppOps. По-моему, оно работает на версиях Android'a 4.2-4.4 и позволяет для разных приложений выбрать некоторые разрешения. Запрещенные разрешения будут эмулироваться, например, если запретить чтения контактов приложению, то ему система будет выдавать пустой лист контактов.

[Virtyoz]

Время идёт, платформа развивается. Интересно, сколько ещё комментариев на хабре сбылось? :)

Если вдруг кто-то дойдёт до этого коммента, детали нового api:
developer.android.com/training/permissions/requesting
habr.com/post/278945

[d1g1]

Хотел бы еще внести маленькое дополнение.

Для ContentProvider значение android:exported по умолчанию равно «true» если SDK <= 16 и «false» если SDK >= 17.

Если android:targetSdkVersion не объявлен, то берется значение android:minSdkVersion.
Если android:minSdkVersion не объявлен, то по умолчанию оно будет восприниматься системой как «1».
Таким образом android:exported будет «true» для ContentProvider.