Содержание статьи
Для этой заметки я отобрал три особенности свежих версий Android, которые кажутся мне наиболее странными и мешающими. У каждой из них есть свои причины для появления, и в большинстве случаев эти причины вызваны низкой компетентностью разработчиков софта и самих пользователей. Поэтому в некотором смысле это предвзятая статья (как и подобает колонке), написанная опытным юзером и для опытных юзеров.
Запрос полномочий
«В Android 6.0 наконец-то появилась система запроса полномочий приложений, не прошло и десяти лет». Примерно в таком ключе отзывались пользователи об одном из главных новшеств Android 6.0 — тех самых окошках с вопросом: «Приложение XXX хочет получить доступ к камере. Разрешить?» Дескать, наконец-то у юзеров появился контроль над сторонними приложениями, какой у пользователей iPhone был еще в iOS 6.
Действительно, на первый взгляд очень нужное и правильное нововведение. Но если копнуть глубже, окажется, что его полезность стремится к нулю. Начнем с того, зачем такая система вообще нужна. А нужна она для очень простой вещи — позволить пользователю контролировать, к каким функциям смартфона приложение может получить доступ, а к каким нет. И здесь возникает первая проблема: если каждое установленное приложение начинает запрашивать права на доступ к чему-либо, очень скоро пользователь привыкает давать добро машинально.
Да, для определенной группы заботящихся о своей конфиденциальности людей такая система будет иметь смысл. Однако для подавляющего большинства она быстро превращается в раздражающий фактор. Причем в том числе и для тех, кто не хочет, чтобы установленные ими приложения не использовали функции смартфона не по назначению. Такие люди так или иначе пользуются проверенным софтом и не устанавливают непонятно что непонятно откуда.
Второе: сама система запроса прав очень обобщена. Фактически десятки различных разрешений, которые могут получить приложения, здесь сведены всего к семи. Это значит, что, если, например, мессенджер хочет получить возможность перехватывать СМС для получения кода авторизации (стандартная практика), он запрашивает у пользователя разрешение на доступ к функциональности СМС, которая автоматически открывает ему доступ к отправке СМС и чтению базы СМС. И если раньше при установке приложения пользователь мог увидеть таблицу со всеми разрешениями и убедиться, что приложение действительно желает всего лишь перехватывать СМС, то все, что ему остается теперь, — это дать приложению полный доступ ко всем функциям СМС сразу.
Третье: новая система запроса полномочий не работает со старым софтом. Это значит, что если приложение не было собрано для Android 6.0 и выше (targetSdkVersion=23), то оно вообще не будет запрашивать полномочия у пользователя для получения доступа к нужным функциям. То есть все будет ровно так, как и было до версии 6.0. А самое главное, что возможность собрать приложение с targetSdkVersion ниже 23 никуда не делась (и не денется в ближайшие годы), любой желающий может скачать самую свежую Android Studio и собрать с ее помощью приложение для Android 5.1, которое будет прекрасно работать в Android 6/7 и не требовать от пользователя подтвердить свои полномочия.
Говоря иначе, система запроса полномочий не только не защищает от приложений, использующих возможности смартфона против владельца, но и создает ложную иллюзию безопасности. Пользователь думает, что контролирует ситуацию, но на самом деле это не так.
 |
 |
| Запрос на доступ к камере и все разрешения приложения «Камера» | |
Энергосбережение
Главное преимущество Android в сравнении с другими мобильными ОС — полнота доступных разработчикам приложений инструментов. Другими словами, Android по своему духу намного ближе к полноценной настольной ОС, чем iOS и Windows Mobile. Приложения здесь могут спокойно работать в фоне, сторонние приложения по минимуму ограничены в действиях и могут использовать возможности системы наравне со стоковым софтом. Диалер, домашний экран, камеру, приложение для обмена сообщениями — все это пользователь может заменить на сторонний софт безо всяких ограничений.
Но где есть свобода, там есть и ответственность. Как только Android начал набирать популярность, всплыла довольно серьезная проблема: многие разработчики просто злоупотребляли возможностями системы и создавали софт, который в том числе мог серьезно снижать продолжительность работы устройства от батареи. Сделать это несложно — достаточно просто написать фоновую службу, которая будет захватывать wakelock (не позволяет устройству уснуть) и постоянно делать какую-то работу.
В большинстве случаев такой софт был результатом простого профанства, в некоторых — злым умыслом. Но как бы там ни было, именно такой софт закрепил за Android репутацию прожорливой до батареи системы, что заставило Google отреагировать. Поначалу меры борьбы были довольно мягкими: отзыв слишком продолжительных вейклоков, объединение задач, принудительное завершение слишком долго работающих служб. Но в конце концов все это привело к появлению режима агрессивного энергосбережения Doze в Android 6.0.
Принцип работы Doze довольно прост. Если в течение часа не включать смартфон и не брать его в руки (в Android 6.0), система отключает доступ в интернет и усыпляет все приложения и службы, независимо от того, имеют они вейклоки или нет. Затем время от времени смартфон просыпается (сначала через час, затем реже), позволяя службам сделать свою работу, и снова засыпает. В дополнение к Doze также существует механизм App Standby, делающий примерно то же самое, но в отношении отдельно взятых фоновых служб и вне зависимости от того, включил ты смартфон или нет.
В теории Doze позволяет свести затраты энергии смартфона к минимуму и не беспокоиться о том, что на утро заряд смартфона снизится процентов эдак на десять. Но есть две проблемы. Первая: эффект от включения Doze будет заметен, только когда на смартфон установлено большое количество не очень качественного софта, жадного до батареи. Для пользователей, которые следят за тем, что они устанавливают, и не пытаются инсталлировать любой, необходимый только один раз в год софт, он не даст практически никакого эффекта.
Вторая проблема: Doze убивает функциональность целого класса приложений, которые необходимы многим пользователям. Фактически весь «серверный» софт, позволяющий обратиться к смартфону по сети и получить от него ответ, летит в трубу. SSH-сервер, веб-сервер, приложения для отслеживания устройства и удаленного управления им — все это благодаря Doze будет работать крайне нестабильно и с чудовищными задержками ответа (в один-два часа и более).
Для решения этой проблемы Google предлагает разработчикам два варианта: либо использовать высокоприоритетные push-уведомления, чтобы разбудить устройство, либо просить пользователей добавить приложения в исключения режима Doze. Проблема первого метода в том, что он работает через сервер Google и, как следствие, требует, чтобы на устройстве были установлены сервисы Google. И это та самая причина, почему мессенджер Signal не будет работать на планшетах и смартфонах Amazon: он использует push-уведомления только для того, чтобы разбудить смартфон. Более того, push-уведомления не решают проблему запрета на доступ в интернет. Другими словами, получив push-уведомление, приложение не сможет отправить ответ на сторонний сервер до тех пор, пока пользователь не включит устройство либо не появится «окно выхода из режима Doze».
Второй вариант плох тем, что сам интерфейс исключения приложения из режима Doze находится довольно глубоко (Батарея → Кнопка «Меню» → Экономия заряда батареи → Все приложения) и не до всех пользователей удается донести информацию о том, как это сделать. К тому же исключение приложения из режима Doze вовсе не гарантирует, что оно будет нормально функционировать в фоне. Оно получит возможность захватывать вейклоки и работать с сетью, но совсем не факт, что система разбудит его в нужный момент. А это опять же возвращает нас к push-уведомлениям: сначала смартфон надо разбудить.
Вообще, борьба за аккумуляторы пользователей для Google в последнее время стала святой. Теперь они напрямую призывают разработчиков отказаться от использования фоновых служб в пользу так называемого JobScheduler’а, системы, сильно напоминающей механизм, доступный приложениям в iOS: вместо того чтобы работать в фоне, приложение добавляет свои задачи в JobScheduler, информируя его, при каких условиях эти задачи следует запускать (время, подключение к сети, подключение к заряднику и так далее).
Сам по себе JobScheduler — отличная идея, но, если в будущем Google станет еще больше урезать возможности системы в плане работы приложений в фоне, они убьют одну из лучших черт Android как операционной системы.
 |
 |
| Панель управления режимом Doze | |
Закрытие исходных текстов
Android — операционная система с открытым исходным кодом. И это один из основных аргументов Google в пользу выбора ее ОС. Действительно, коды Android полностью открыты, любой желающий может их изучить или даже собрать собственную прошивку на их основе, как это делают разработчики CyanogenMod (теперь уже LineageOS) и других кастомных прошивок.
Более того, даже компании-производители не обязаны лицензировать Android у Google и платить ей роялти — бери и пользуйся, с тем лишь требованием, что вместе с Play Store производитель обязан установить на смартфон большую часть других приложений Google плюс соблюсти требования Google к аппаратной и программной части (например, реализовать безопасный сканер отпечатков пальцев, соблюдая правила, описанные в документе, не нарушать API Android, оснастить смартфон необходимыми сенсорами и датчиками).
В целом вполне обоснованные требования компании, которая распространяет ОС абсолютно бесплатно, а деньги зарабатывает на предоставлении доступа к сервисам. Вот только чем больше внимания Google уделяет своим фирменным приложениям, тем сильнее она забывает об их открытых аналогах в Android. После появления Google Keyboard стандартная клавиатура Android практически перестала развиваться, функциональность стандартной камеры Android даже близко не дотягивает до функциональности Google Camera, та же история с диалером, СМС-приложением, почтовым клиентом и домашним экраном, а поисковая строка Google, замененная на закрытый Google Now, так и вообще застряла во времени Android 2.3.
Ну ладно, это всего лишь приложения. Все-таки все их можно заменить, главное, что сама система остается открытой, так что сообщество может продолжать пилить чистые кастомные прошивки. Но и здесь засада. Огромный пласт функциональности, которая может показаться стандартной для Android, — это вовсе не Android, а Google Mobile Services — компонент системы, устанавливаемый вместе с маркетом и Google-софтом.
Сервисы Google отвечают за множество самых разных системных функций: подключение к аккаунту Google, аутентификацию (в том числе двухфакторную и по снимку лица), синхронизацию календаря и контактов, поиск украденного смартфона, push-уведомления, работу системы онлайн-проверки приложений на вирусы и огромное множество других.
Придуманные изначально как система связи смартфона с экосистемой Google, эти сервисы сегодня используются в том числе для реализации новой функциональности в старых версиях Android (в отличие от самого Android, Google может их обновлять самостоятельно и незаметно для юзера на всех подключенных устройствах). И эти сервисы закрыты. Другими словами, Google не позволяет провести их аудит и даже прямо запрещает в условиях пользовательского соглашения ставить их альтернативную реализацию.
Итого. Мы имеем формально открытую систему, которую Google в любой момент может закрыть благодаря используемой лицензии Apache 2.0, многие компоненты которой уже не развиваются или находятся в заброшенном состоянии, а другие существуют только в виде проприетарных библиотек без возможности создания альтернативы.
 |
 |
| Сервисы Google | |
Выводы
Подводя итог, скажу, что, хоть Android все больше превращается в со всех сторон урезанную ОС, Google вносит изменения в систему очень аккуратно, оставляя возможность вернуть старую функциональность или каким-то образом обойти новые механизмы. Так что, несмотря на общий тренд, пока Android продолжает оставаться тем самым Android’ом, что не может не радовать.
