true_engineering Feb 12 2014 at 10:01

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

6 min

39K

True Engineering corporate blogDevelopment for Android*

+37

Comments 17

akira Feb 12 2014 at 11:32

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

Propheta13 Feb 12 2014 at 11:41

В случае сервиса я бы еще указал 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 Feb 12 2014 at 11:47

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

forceLain Feb 12 2014 at 11:53

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

knott Feb 12 2014 at 15:59

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

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

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

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

zyrik Feb 12 2014 at 22:33

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

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

grishkaa Feb 13 2014 at 00:53

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

lola_term Feb 12 2014 at 12:51

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

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

Newbilius Feb 12 2014 at 14:20

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

forceLain Feb 12 2014 at 14:32

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

zagayevskiy Feb 12 2014 at 14:35

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

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

forceLain Feb 12 2014 at 14:37

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

zagayevskiy Feb 12 2014 at 14:44

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

forceLain Feb 12 2014 at 14:49

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

zyrik Feb 12 2014 at 22:25

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

Virtyoz Jun 21 2018 at 10:40

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

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

d1g1 Feb 12 2014 at 18:01

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

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

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