Android 4.3 уже на полном ходу. В этом обновлении оказалось не только много исправлений, но и достаточно совсем новых функций, как, например, поддержка 4К разрешения. Под занавесом ряда улучшений остались незамеченными некоторые скрытые возможности обновления. Например, в предыдущих версиях Android была спрятана поддержка нескольких учетных записей, и только знающий человек мог воспользоваться этой фичей, на этот раз такой темной лошадкой оказался Permissions Manager .

И так, теперь его краткий смысл. Когда вы скачиваете приложение, каждое из них требует определенный уровень прав доступа. GPS приложения требуют доступ к вашим данным, чтобы определить ваше место положение. В некоторых случаях давать доступ к личным данным имеет смысл, но для большинства приложений это абсурдно. Например, Facebook требует получить доступ к истории ваших звонков, а вот с какой целью непонятно. Смысл Permissions Manager заключается в том, чтобы контролировать процесс наделения прав доступа. Если вы не хотите, чтобы Facebook узнал вашу историю звонков, при помощи Permissions Manager Android вы можете отключить эту возможность.

Эта функция доступна для всех пользователей Android 4.3, поэтому если вы успели обновиться, тогда Permissions Manager уже доступен для вас. Как им пользоваться? Самое главное условие - это наличие Android 4.3.

1. Установили или обновились до версии Android 4.3.

2. Скачиваем и устанавливаем это приложение . Это приложение дает доступ к так называемому “App ops”, другими словами Permissions Manager.

Теперь у меня есть Permissions Manager. Что дальше?

Установка была чрезвычайно простой, теперь надо научиться им пользоваться. Первым делом, что вы увидите, это список приложений и 4 вкладки: Location, Personal, Messaging, Device. Это позволяет сортировать ваши приложения по установленным к ним правам доступа. Если вы скачаете Google Hangouts, это приложение попадет в категорию Messaging, приложение для камеры - скорее всего в Device.

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

Последнее о чем хотелось бы упомянуть, это то, что Permissions Manager не сразу видит все доступные права и разрешения. Например, “камера” и “история звонков” не видимы до тех пор, пока вы не экспортируете свои контакты на Facebook. Также помните о том, что Permissions Manager ещё сырой, поэтому будь готовы к тому, что отключение некоторых прав может повлечь за собой никакой рекции.

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

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

Благодаря своим уникальным возможностям, приложение получило широкое распространение и отличные оценки от пользователей. Они все с радостью стали редактировать доступы программ, чтобы те не особо захламляли устройство. Полезность приложения сложно переоценить, ведь оно по-настоящему помогает реальному пользователю. Также оно не занимает много места и поэтому пригодится практически каждому.

Иногда ошибки app.permissions.sh.dll и другие системные ошибки DLL могут быть связаны с проблемами в реестре Windows. Несколько программ может использовать файл app.permissions.sh.dll, но когда эти программы удалены или изменены, иногда остаются "осиротевшие" (ошибочные) записи реестра DLL.

В принципе, это означает, что в то время как фактическая путь к файлу мог быть изменен, его неправильное бывшее расположение до сих пор записано в реестре Windows. Когда Windows пытается найти файл по этой некорректной ссылке (на расположение файлов на вашем компьютере), может возникнуть ошибка app.permissions.sh.dll. Кроме того, заражение вредоносным ПО могло повредить записи реестра, связанные с HP Web Jetadmin. Таким образом, эти поврежденные записи реестра DLL необходимо исправить, чтобы устранить проблему в корне.

Редактирование реестра Windows вручную с целью удаления содержащих ошибки ключей app.permissions.sh.dll не рекомендуется, если вы не являетесь специалистом по обслуживанию ПК. Ошибки, допущенные при редактировании реестра, могут привести к неработоспособности вашего ПК и нанести непоправимый ущерб вашей операционной системе. На самом деле, даже одна запятая, поставленная не в том месте, может воспрепятствовать загрузке компьютера!

В связи с подобным риском мы настоятельно рекомендуем использовать надежные инструменты очистки реестра, такие как WinThruster (разработанный Microsoft Gold Certified Partner), чтобы просканировать и исправить любые проблемы, связанные с app.permissions.sh.dll. Используя очистку реестра , вы сможете автоматизировать процесс поиска поврежденных записей реестра, ссылок на отсутствующие файлы (например, вызывающих ошибку app.permissions.sh.dll) и нерабочих ссылок внутри реестра. Перед каждым сканированием автоматически создается резервная копия, позволяющая отменить любые изменения одним кликом и защищающая вас от возможного повреждения компьютера. Самое приятное, что устранение ошибок реестра может резко повысить скорость и производительность системы.

Предупреждение: Если вы не являетесь опытным пользователем ПК, мы НЕ рекомендуем редактирование реестра Windows вручную. Некорректное использование Редактора реестра может привести к серьезным проблемам и потребовать переустановки Windows. Мы не гарантируем, что неполадки, являющиеся результатом неправильного использования Редактора реестра, могут быть устранены. Вы пользуетесь Редактором реестра на свой страх и риск.

Перед тем, как вручную восстанавливать реестр Windows, необходимо создать резервную копию, экспортировав часть реестра, связанную с app.permissions.sh.dll (например, HP Web Jetadmin):

1. Нажмите на кнопку Начать .
2. Введите "command " в строке поиска... ПОКА НЕ НАЖИМАЙТЕ ENTER !
3. Удерживая клавиши CTRL-Shift на клавиатуре, нажмите ENTER .
4. Будет выведено диалоговое окно для доступа.
5. Нажмите Да .
6. Черный ящик открывается мигающим курсором.
7. Введите "regedit " и нажмите ENTER .
8. В Редакторе реестра выберите ключ, связанный с app.permissions.sh.dll (например, HP Web Jetadmin), для которого требуется создать резервную копию.
9. В меню Файл выберите Экспорт .
10. В списке Сохранить в выберите папку, в которую вы хотите сохранить резервную копию ключа HP Web Jetadmin.
11. В поле Имя файла введите название файла резервной копии, например "HP Web Jetadmin резервная копия".
12. Убедитесь, что в поле Диапазон экспорта выбрано значение Выбранная ветвь .
13. Нажмите Сохранить .
14. Файл будет сохранен с расширением.reg .
15. Теперь у вас есть резервная копия записи реестра, связанной с app.permissions.sh.dll.

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

В этой статье мы рассмотрим три самых важных изменения в новом Android, которые не могут быть проигнорированы ни одним разработчиком, который поставил у себя в проекте targetSdk = 23 и выше.
Doze Mode — режим «отключки», в который переходят все устройства на Marshmallow после некоторого времени обездвижения без зарядки.

App Standby — автоматическое лишение приложений доступа к ресурсам устройства, всех которые давно не открывал пользователь.

Runtime Permissions — новая модель запроса разрешений. Теперь мы, как разработчики, каждый раз обращаясь, например, к микрофону устройства, должны проверять, есть ли у нашего приложения разрешение на доступ к нему.

В Google в новом релизе Android сделали очень важный шаг в сторону оптимизации работы батареи. Все мы знаем, как пользователи любят повонять в комментариях высказываниями: «Дурацкие Google Play Services» жрут 25% батареи моего ******* S III, гопники, верните мне мой драгоценный айфон, нет сил, терпеть издевательства от Гугл". Только вот эти пользователи не ставили себе никогда Battery Historian и не в курсе, что жрут батарею бесплатные игры от сомнительных авторов и такие же сделанные на коленке живые обои, например. Но пользователь этого не знает, и как бороться с кучей левых приложений, беспощадно съедающих батарею, он не в курсе.

Ну теперь пользователям об этом заботиться и не придется. С приходом двух новых режимов Doze Mode и App Standby операционная система перекрывает кислород всем чрезмерно жрущим заряд приложениям. Как? Читаем далее:

Doze Mode

Когда устройство на Android Marshmallow лежит без движения и без зарядки, спустя час оно переходит в Doze Mode. Режим отключки, когда почти все приложения перестают жрать батарею.

Это происходит не сразу, а по шагам:

ACTIVE — Устройство используется или на зарядке
INACTIVE — Устройство недавно вышло из активного режима (пользователь выключил экран, выдернул зарядку и т.п.)
...30 минут
IDLE_PENDING — Устройство готовится перейти в режим ожидания
...30 минут
IDLE — Устройство в режиме бездействия
IDLE_MAINTENANCE — Открыто короткое окно, чтобы приложения выполнили свою работу

Мы можем продебажить наши приложения, переключаясь последовательно между этими шагами с помощью:
$ adb shell dumpsys deviceidle step

В момент, когда устройство переходит в состояние IDLE:

• Доступ приложению к сети отключен, пока приложение не получит high-priority GCM-push.
• Система игнорирует Wake lock’и. Приложения могут сколько угодно пытаться запросить пробуждение процессора — они их не получат.
• Alarm’ы запланированные в AlarmManager не будут вызываться, кроме тех, которые будут обновлены с помощью setAndAllowWhileIdle().
• Система не производит поиска сетей Wi-Fi.
• NetworkPolicyManagerService: пропускает только приложения из белого списка.
• JobSchedulerService: все текущие задачи отменяются. Новые откладываются до пробуждения.
• SyncManager: все текущие отменяются, новые откладываются до пробуждения.
• PowerManagerService: только задачи приложений из белого списка вызовутся.

Соответственно, если наше приложение чат, то мы можем отправить с сервера push с полем priority = high .
А если у нас приложение будильник, то мы должны обязательно вызвать для Alarm setAndAllowWhileIdle() или setExactAndAllowWhileIdle() .

Во многих других случаях мы вообще не должны об этом переживать, после того, как пользователь возьмет устройство в руки, все заснувшие alarm"ы и SyncAdapter"ы проснутся и сделают свою работу. (Да-да я знаю, что после выхода из doze mode все начинает синкаться и даже Nexus 9 минуты две тормозит)

App Standby

Но не только при попадании устройство в Doze Mode наши приложения будут лишены возможности разряжать батарею. Второй режим под название App Standby отправляет в такую же изоляцию приложения, которые не подходят под условия:

• Пользователь явно запустил приложение.
• Приложение имеет процесс, работающий в данный момент на переднем плане (Activity или foreground service, или используется другой activity или foreground service’ом).
• Приложение создало уведомление, которое висит в списке уведомлений.
• Пользователь принудительно добавил приложение в список исключений оптимизации в настройках системы

Исключения

Возможно сейчас разработчики коммерческих voip нервно начали продумывать, как запретить обновляться своим пользователям на пугающий своей жесткостью Android Marshmallow. Но не волнуйтесь, есть специальный Whitelist, в который пользователь руками может добавить исключения. Приложениям из Whitelist не страшны ни Doze Mode ни App Standby.

Чтобы проверить, попало ли наше приложение в Whitelist вызываем метод isIgnoringBatteryOptimizations() .

Пользователь может сам руками добавить/удалить из списка в настройках Settings > Battery > Battery Optimization
Но мы можем его сами попросить с помощью интента ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS или запросив пермишен REQUEST_IGNORE_BATTERY_OPTIMIZATIONS , который покажет диалог на автоматическое добавление в вайтлист с разрешения пользователя.

Runtime Permissions

Мы подобрались к самому известному изменению в Android Marshmallow. Более того это изменение требует от нас наибольшего вовлечения в перелопачивание кода приложения. Кратко говоря: халява кончилась.

Да-да, каждый раз, когда наше приложение обращается, например, с запросом на местоположение пользователя, мы должны проверить, есть ли у приложения разрешение от пользователя на это действие. Если есть — обращаемся к нужным нам системным ресурсам, если нет — запрашиваем. Так же пользователь может навсегда приложению запретить доступ, тогда единственный наш шанс — это попросить его самого зайти в настройки и снять запрет, показав ему объясняющее сообщение, зачем нам нужен доступ.

Стоит отметить, что Permissions в Android делятся на два типа:

1. Нормальные разрешения , вроде доступа к сети и bluetooth.
2. Опасные разрешения . В этот список входят разрешения на: календарь, камеру, контакты, местоположение, микрофон, телефон, сенсоры, смс и внешнее хранилище

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

Итак, последовательность наших шагов:

• Описать только PROTECTION_NORMAL запросы в manifest
• Пользователь их все подтвердит при установке
• Когда приложению нужен доступ к одному или нескольким разрешениям из группы опасных, проверить, нет ли разрешения
• Если разрешения нет — запросить
• Если разрешения не будет — объяснить, на что это повлияет
• Если разрешение получено — продолжить работу

Чтобы проверить доступность разрешения дергаем ContextCompat.checkSelfPermission (Context context, String permission) .
Чтобы запросить разрешения, показав системный диалог, вызываем ActivityCompat.requestPermissions() ;
Результат этого запроса придет в асинхронный колбэк в активити onRequestPermissionsResult() , в нем мы узнаем решение пользователя по каждому из запрошенных разрешений.

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

Если есть возможность, вместо запроса воспользоваться внешним Intent. Например, для фото или видео часто нет смысла встраивать камеру в приложение, гораздо проще воспользоваться внешним приложением

Запрашивать разрешение, только перед тем, когда оно понадобится. Запрашивать при старте приложения все разрешения нелогично (из тех, которые нам нужны), их смысл как раз в том, что мы запрашиваем их в контексте их использования.Например, пользователю становится понятно зачем его банковскому клиенту доступ к контактам — чтобы выбрать одного при шаринге по ФИО

Пояснять пользователю, для чего запрашивается разрешение. Если пользователь все же запретил приложению доступ, а без него оно не может, оно должно максимально понятно объяснить, что без этого разрешения оно работать дальше не будет

Сегодня мы поговорили о самых заметных изменениях в Android Marshmallow. На днях я добавлю статью про остальные фичи и изменения, важные для нас, как для разработчиков. Спасибо за внимание и скорейшую оптимизацию ваших приложений под новый Android!

Одним из интереснейших методов безопасности операционной системы Андроид является система разрешений (permissions ), используемых приложениями. Когда OS ANDROID только появилась, её разработчики придумали – выделить все возможные функции, доступ к которым необходим приложению, и позволить пользователю их контролировать. Было это реализовано довольно интересно. Список возможных разрешений создан разработчиками Google и зафиксирован в документации. Он очень гибкий, в нем есть всё, что нужно для обеспечения какого угодно сложного функционала. Вместе с тем он грамотно разграничен.

Например, если программа работает с СМС, то ему можно дать права только на чтение сообщений, или только на их отправку, или только на уведомление о событии, которое связано с СМС. Это разграничение очень хорошо позволяет избегать злоупотребления привилегиями со стороны приложений. Ещё во время создания программы разработчик выделяет все функции, которые потребуются его программе. Этот список прописывается в файле AndroidManifest.xml, который на этапе сборки программы помещается в его APK-файл. Когда пользователь Андроид устройства будет устанавливать очередное приложение, то вышеупомянутый список, заданный его создателем, будет отображаться на экране. И только после того, как пользователь согласится дать все эти права устанавливаемому приложению, оно будет установлено. Считается, что именно на этом этапе большинство пользователей избежит вирусов, заподозрив программу в плохом поведении и отклонив установку.

С технической точки зрения, обойти существующий механизм прав доступа приложений к функциональности системы Андроид очень непросто. Так как менеджмент разрешений осуществляется на самом низком уровне ядром Linux, программе обязательно нужны права рут , чтобы повлиять на это. Хорошо формализованная система permissions облегчает реализацию инструментов безопасности сторонними разработчиками. Перспективным направлением является создание программ, которые позволяют пользователям тонко настраивать права доступа каждого отдельного приложения, предотвращая любые утечки информации с устройства.

Права доступа (permission) на папки и файлы в Андроид

Права доступа разделяются на две группы зто:
1.Права доступа к файлам
2.Права доступа к папке (директории)

Права доступа к файлам могут иметь такие атрибуты:
r - право на чтение данных. (read)
w - право на изменение содержимого или запись, но не удаление. (write)
x - право на исполнение файла. (xxxxxx)

Права доступа к папке (директории):
r - право на чтение папки (директории).
w - право на изменение содержимого директории можно создавать и удалять объекты в этой директории.
x - право, которое позволяет вам войти в директорию.

Сами права доступа подразделяются на три категории:
«user » - u владелец файла.
«group » - g член той же группы, к которой принадлежит владелец.
«world » - o все остальные.

Порядок записи прав доступа:
сначала права для владельца - «u »
затем для группы - «g »
и в конце права для всех остальных - «o »

Например: предположим что у вас на работе есть компьютер, вы его владелец, он состоит в локальной сети (группа) а есть пользователи, которые хотят что либо на вашем компьютере сделать. По всем этим категориям задаются права на файлы и папки в виде RWX которые дают какие либо права на выполнение чего либо, если в заданных правах RWX присутствует знак «-» то это означает что право отсутствует.
Например: rwx r-- r-- означает что владелец файла имеет все права: право на чтение, запись в него и исполнение, а все остальные пользователи только право на чтение.

Помимо буквенных выражений есть числовые выражения:
r - (читать) это 4
w (запись) это 2
x (исполнение) это 1
«- » ничего не делать тоесть знак дефиса, 0
И их сумма означает конечные права
7 (rwx) = 4 + 2 +1 (полные права)
5 (r-x)= 4 + 0 + 1 (чтение и выполнение)
6 (rw-) = 4 + 2 + 0 (чтение и запись)
4 (r--) =4 + 0 + 0 (только чтение)

Часто используемые параметры:
400 (-r--------) - владелец будет иметь право чтения, никто кроме него не имеет права выполнять никакие действия.
644 (-rw-r--r--) - все пользователи имеют право чтения, а владелец может редактировать.
660 (-rw-rw----) - владелец и группа могут читать и редактировать, все остальные не имеют никаких прав.
664 (-rw-rw-r--) - все пользователи имеют право чтения, а владелец и группа могут редактировать.
666 (-rw-rw-rw-) - все пользователи могут читать и редактировать.
700 (-rwx------) - владелец может читать, записывать и запускать на выполнение, у других нет права выполнять никакие действия.
744 (-rwxr--r--) - все пользователи могут читать, а владелец имеет право редактировать и запускать на выполнение.
755 (-rwxr-xr-x) - каждый пользователь может читать и запускать на выполнение, владелец может редактировать.
777 (-rwxrwxrwx) - каждый пользователь может читать, редактировать и запускать на выполнение.
sudo passwd root - пароль суперпользователя root.