Потому что 5 лет назад разработчики Андроида приняли решение что привилегии даются при установке, а не в рантайме (ниже я давал ссылку на документацию для разработчиков под Андроид). Изменение поведения приведёт к поломке многих приложений и в первую очередь будут страдать пользователи. Обратная совместимость — вещь важная и необходимая. Если вам не нравятся права приложения — зачем вы тогда его устанавливаете? Будьте последовательными, не нравятся права — не устанавливайте приложение.
Сейчас нет возможности в Андроид связать права с фичей, т.е. несколько фич могут использовать одни права и одна фича может использовать много прав. Поэтому отключая одни права, можно сломать всё что угодно.
И ещё — получить рут на устройстве можно не обладая никакими правами (например, см. эксплойт для телефонов Samsung). А с рутом отсутствие прав — не проблема. Так что реальные злоумышленники, если захотят могут и так достучаться до ваших контактов.
Вам может быть и не нужно, что насчёт других пользователей? Например, кто-то попросил реализовать выгрузку закладок или заметок на диск (чтобы с облаком синхронизовать или на другое устройство перенести), разработчики фичу запилили. Но для этого требуются права для записи и чтения с SD карты и такие права только избранным пользователям дать нельзя чисто технически — либо у всех запрашивать, либо фичу не выпускать. Как вы думаете что разработчики выберут?
Вот если бы Андроид изменил структуру манифеста и позволил бы задавать права как не обязательные (например, атрибутом required=«false»), тогда проблему можно было бы обойти. Но этого пока не сделано.
Объясните только одно: зачем в рантайме проверять права доступа, если Андроид гарантирует, что права выданные при установке приложения не могут быть отозваны? Что если приложение требует доступ в интернет (и получило на это права) — мне перед каждым запросом всё равно нужно их проверять?
Не спорю, такое можно было бы делать (проверять права каждый раз) если бы изначально в Андроиде использовался такой подход. Сейчас же, по факту, тупые пользователи понаотключают прав, а потом будут жаловаться что приложения падают (в корпорациях, например, цикл разработки новой версии может занимать полгода и, получается, пользователю придётся жить полгода с падающим приложением).
Ещё пример из личного опыта — некоторые пользователи лезут в настройки и принудительно включают hardware acceleration, которое не работает и отключено для приложения. А потом пишут бар-репорты, что у них GUI в артефактах.
No checks with the user are done while an application is running: it either was granted a particular permission when installed, and can use that feature as desired, or the permission was not granted and any attempt to use the feature will fail without prompting the user
Т.е. получается быдлокодит как раз тот, кто эти права проверяет.
Иногда графической оболочки просто нет (например, на серверах она просто не нужна) или пользователь выполняет операции удалённо (например, через ssh) и ему доступна только консоль. В таком случае полезно иметь псевдогуёвое представление для упрощения работы.
Но, вроде как, Maven Enforcer Plugin может детектить различные версии транзитивных зависимостей и падать в случае обнаружения последних (так называемый Dependency Convergence). Правильно ли я понимаю, что в этом случае (при использовании dependency convergence rule) поведение будет таким же как и в Gradle со стратегией fail? (Пока не исправим — не будет сбоираться)
Т.е. вы предлагаете всегда собирать проект Gradle с использованием стратегии fail и руками управлять зависимостями? Или только при добавлении новых зависимостей проверять с fail, а далее переключаться на latest?
Как Gradle спасает в этом случае? Пока вы на грабли не встанете (с тем что, последняя версия библиотеки не совместима с предидущими), так и не будете знать о проблеме.
Был не прав — в случае обнаружения конфликта версий Maven возьмёт nearest, т.е. ближайшую к корню проекта. В случае указывания версии библиотеки в dependencyManagement/dependecnies Maven выберет именно её (линк). Тогда, действительно, не понятно в чём проблема автора статьи.
Maven позволяет собирать параллельно независимые модули (например, A — общий код(ядро), B зависит от A, С зависит от A, B и C — независимы. В этом примере модули B и C будут собираться параллельно после сборки A). Для этого ничего особенного делать не надо — просто запустить сборку с ключиком -T xx, где xx — параметр ключа.
1. Хотя бы то, что параметры intent'а выставлены корректно
2. Что невалидные данные не приводят к крешу (NPE)
3. Robolectric'ом можно проверить запускаемость активитей
Рекомендую вместо названия IntentUtils ипсользовать Intents, если ещё не поздно =). Так проще и понятнее (такой подход используется, например, в Guava). Если отдаёте библиотеку в открытый доступ — не плохо бы покрыть её тестами (там чуть-чуть же).
В целом, молодец, спасибо.
У Джошуа Блоха хорошо написано об этом методе: link
Краткая выдержка:
1. finalize() можно использовать только в двух случаях:
1.1. Проверка/подчистка ресурсов с логированием
1.2. При работе с нативным кодом, который не критичен к утечке ресурсов
2. finalize() замедляет работу GC по очистке объекта в 430 раз
3. finalize() может быть не вызван
Собственный опыт — за пять лет ни разу не переопределял finalize(). Собственно, переопределение finalize() — признак smelly кода.
Без обид — я имел ввиду, конечно, что заявление об оптимальности не может быть истинным пока не поставлена и не решена задача оптимизации. Опять же, нужно делать предположения об оппоненте — играет ли он наугад или же, зная вашу стратегию, специально подстраивается под неё. Немного погуглив нашёл ответ, хоть как-то затрагивающий теорию вероятностей: otvety.google.ru/otvety/thread?tid=4c354bc83317c41f&pli=1. Конечно, это далеко от идеала, но уже что-то. Конечно, для вероятность ещё можно посчитать практическим путём — написать программу, которая играет сама с собой разными методами и найти наиболее выигрышный из них (но опять же не факт что это будет оптимальным решением задачи).
К сожалению, не обладаю сейчас свободным временем для исследования, но думаю запишу куда-нибудь, если появится время — подумаю.
Сейчас нет возможности в Андроид связать права с фичей, т.е. несколько фич могут использовать одни права и одна фича может использовать много прав. Поэтому отключая одни права, можно сломать всё что угодно.
И ещё — получить рут на устройстве можно не обладая никакими правами (например, см. эксплойт для телефонов Samsung). А с рутом отсутствие прав — не проблема. Так что реальные злоумышленники, если захотят могут и так достучаться до ваших контактов.
Вот если бы Андроид изменил структуру манифеста и позволил бы задавать права как не обязательные (например, атрибутом required=«false»), тогда проблему можно было бы обойти. Но этого пока не сделано.
Не спорю, такое можно было бы делать (проверять права каждый раз) если бы изначально в Андроиде использовался такой подход. Сейчас же, по факту, тупые пользователи понаотключают прав, а потом будут жаловаться что приложения падают (в корпорациях, например, цикл разработки новой версии может занимать полгода и, получается, пользователю придётся жить полгода с падающим приложением).
Ещё пример из личного опыта — некоторые пользователи лезут в настройки и принудительно включают hardware acceleration, которое не работает и отключено для приложения. А потом пишут бар-репорты, что у них GUI в артефактах.
Ну и напоследок цитата с d.android.com:
Т.е. получается быдлокодит как раз тот, кто эти права проверяет.
Это каким образом такая атака может загрузить вредоносный код?
1. Не нужно интернет пермишена
2. Есть контактный адрес отправителя
ACRA из коробки позволяет это сделать.
Но, вроде как, Maven Enforcer Plugin может детектить различные версии транзитивных зависимостей и падать в случае обнаружения последних (так называемый Dependency Convergence). Правильно ли я понимаю, что в этом случае (при использовании dependency convergence rule) поведение будет таким же как и в Gradle со стратегией fail? (Пока не исправим — не будет сбоираться)
2. Что невалидные данные не приводят к крешу (NPE)
3. Robolectric'ом можно проверить запускаемость активитей
В целом, молодец, спасибо.
Краткая выдержка:
1. finalize() можно использовать только в двух случаях:
1.1. Проверка/подчистка ресурсов с логированием
1.2. При работе с нативным кодом, который не критичен к утечке ресурсов
2. finalize() замедляет работу GC по очистке объекта в 430 раз
3. finalize() может быть не вызван
Собственный опыт — за пять лет ни разу не переопределял finalize(). Собственно, переопределение finalize() — признак smelly кода.
К сожалению, не обладаю сейчас свободным временем для исследования, но думаю запишу куда-нибудь, если появится время — подумаю.