Всем привет! Совсем скоро состоится важное событие – выход Android O. Поддержка новых версий операционной системы – обязанность любого серьезного продукта. Каждое обновление Android заставляет многих разработчиков серьезно поработать для сохранения работоспособности имеющихся функций и привнесения нового благодаря возможностям новых версий Android.
В данной статье мы рассмотрим основные изменения Android O и оценим их возможное влияние.
Работая над Android O, разработчики Google в первую очередь решали проблему быстрого расхода заряда аккумулятора на Android-устройствах, поэтому основные изменения связаны с оптимизацией фоновых задач и расхода ресурсов приложения.
Изменения в Android O можно разделить на две категории:
Потенциально «ломающие» текущую работоспособность и требующие дополнительных усилий для поддержки;
Угроза Target >= O Target < O Эффект Background Location Limits Affected Affected Ограничение на запрос геолокации Background Execution Limits Affected OK Изменение списка доступных бродкастов в манифесте;
Изменение времени работы сервисов в фоне.Notification Channels Affected OK Доработки для каналов нотификаций WindowManager Affected OK Влияние на работу перекрывающих окон Privacy (Build.Serial/net.dns/e.t.c.) Affected Affected Изменение доступности пользовательских идентификаторов AccountManager.
getAccounts()Affected OK Запрос списка аккаунтов на устройстве возвращает null
- Возможности для реализации новых функций.
Новые возможности Применение Android Enterprise Улучшение контроля над девайсом Autofill Framework Автозаполнение полей ввода Notification Channels Улучшение UX Picture in Picture Улучшение UX Adaptive Icon Консистентность с прошивкой вендора Accessibility button and fingerprint gestures Улучшение UX (accessibility кнопка в navigation bar, отлавливание жестов по сканеру отпечатка пальцев) Webview Apis (напр., Safebrowsing) Улучшение встроенных возможностей Webview Pinning shortcuts and Widgets Программное создание ярлыков и виджетов в лаунчере
На наш взгляд это наиболее значимые (по крайней мере для «Лаборатории Касперского») изменения в Android O. Рассмотрим каждое по отдельности.
Background Location Limits
Это ограничение на количество запросов местоположения для приложений, находящихся в фоне. Так, начиная с Android O и независимо от установленного TargetSDK, приложения смогут получать всего несколько обновлений местоположения в час. При этом, эти ограничения не распространяются на приложения, для которых справедлив хотя бы один из следующих параметров:
- Приложение не в фоне (запущено Activity, которое находится в состоянии Started или Paused);
- Приложение имеет активный Foreground-сервис;
- Другое Foreground-приложение имеет соединение с текущим (как через bind service, так и через content provider).
Таким образом, для Foreground-приложений поведение будет таким же, как и на предыдущих версиях Android.
В случае, если foreground service отсутствует, то запрос геолокации будет изменен:
- Fused Location Provider (FLP)
- Для Background-приложений система будет определять новое местоположение только несколько раз в час, даже если приложение явно запросило больше обновлений
- Для Foreground-приложений логика работы останется без изменений
- Geofencing
- Background-приложения смогут получать обновления от geofencing-api чаще, чем обновления от Fused Location Provider
- GNSS Measurements and GNSS Navigation Message
- Для приложений, находящихся в фоне не будут приходить обновления для сервисов GnssMeasurement и GnssNavigationMessage
- Location Manager
- Для Background-приложений система будет определять новое местоположение только несколько раз в час
Background execution limits
Ограничение на фоновую работу приложения – ключевое изменение Android O, которое будет заметно в большой степени лишь при переходе на targetSdk “O”. В случае, если targetSdk <= 25, то если приложение находится в фоне и было переведено системой в Cached-состояние (когда система может свободно убить процесс в любой момент), и при этом оно не имеет активных компонентов, система отпустит все WakeLock (индикатор, что приложение не должно быть в состоянии сна) этого приложения. Важно отметить, что в случае, если приложение не targetSDK < O, то в настройках можно выставить политику поведения такую же, как если бы приложение было бы с targetSDK O.
Для приложений с targetSdk “O” background execution limits состоят из двух категорий:
- Ограничение фоновых сервисов
После того как приложение перешло в background, у него есть «окно» в несколько минут, в течение которого сервисы могут запускаться и работать. После истечения этого интервала все сервисы останавливаются, а запуск новых будет приводить к падению приложения. Google старается минимизировать количество работающих фоновых сервисов и предлагает использовать JobScheduler и GcmNetworkManager.
В случае если необходимо выполнять длительные задачи в фоне, рекомендуется использовать foregroundService, который будет явно говорить пользователю, что приложение работает.
Стоит обратить внимание, что после того как вызвалиContext.startForegroundService()необходимо в течение 5 секунд вызватьstartForeground(), в противном случае система может показать ANR. - Ограничений на регистрацию broadcasts в манифесте
Новая версия Android продолжает дело, начатое Android 7.0 (наверняка все помнят приложения, которые переподнимались при каждой смене мобильной станции). Но если в 7-ой версии в манифесте нельзя было зарегистрировать всего лишь несколько бродкастов, то теперь таких бродкастов стало большинство.
Notification Channels
Notification Channels — инструмент для группировки нотификаций в тематические группы, которыми пользователь сможет управлять напрямую. Если приложение собрано с target >= O, тогда необходимо поддержать хотя бы один из каналов нотификаций. В случае, если targetApi < O, тогда работа с нотификациями внутри продукта останется прежней.
WindowManager
В Android O вводится новый тип окон (для targetSDK O), которые могут быть выведены поверх других окон – TYPE_APPLICATION_OVERLAY. При этом несколько старых типов окон стали deprecated, и теперь при их использовании генерируется RuntimeException.
Эти типы окон теперь могут использоваться только системными приложениями:
Privacy (Build.Serial/net.dns/e.t.c.)
В Android O появляются некоторые улучшения, призванные помочь пользователю управлять доступом к своим идентификаторам. Эти улучшения включают:
- Ограничение на использование постоянных (не сбрасываемых) устройство-зависимых идентификаторов
- Обновление системой Wi-Fi стека, связанного с изменениями прошивки Wi-Fi-чипсета на устройствах типа Pixel, Pixel XL и Nexus 5x для рандомизации MACадресов во время сканирований сетей
- Обновление в механизме, при помощи которого приложения запрашивали информацию об учётной записи и предоставление большего контроля над данными пользователя
AccountManager.getAccounts()
Начиная с Android O, разрешения GET_ACCOUNTS недостаточно для получения доступа к списку учетных записей. Теперь существует два варианта для приложений с targetSDK O:
- Использовать
AccountManager.newChooseAccountIntent(). - Использовать метод, определяемый аутентификатором, для доступа к учетной записи.
Android Enterprise
Google активно развивает Android for Work. В Android O они предоставили больше возможностей для контроля устройства. Например, для рабочего профиля можно заводить отдельную блокировку со своими настройками, узнавать информацию о доступных обновлениях системы.
Autofill Framework
C появлением Autofill Framework API появилась возможность более удобного заполнения пользовательских данных в приложения, чем при использовании Accessability. При вызове фреймворка нужно будет сопоставить packageName продукта, для которого произошел вызов на автозаполнение, после чего предоставить данные для ввода. Для верной идентификации полей логина и пароля нужно создать и поддерживать базу с resourceId контролов или другой служебной информацией, позволяющей верно идентифицировать UI-элементы для автозаполнения.
Picture in Picture
Android O позволяет запускать активности в режиме Picture-In-Picture, который является специальным типом multi-window mode. Google рекомендует использовать данный режим исключительно для приложений, отображающих видео.
Adaptive Icon
Начиная с Android O для приложения можно предоставить еще один вариант Launcher Icon, который система сможет по маске легко обрезать до формы, которая используется производителем устройства. Также при наличии такой иконки система сможет делать некоторые анимации иконок приложений.
Pinning shortcuts and Widgets
Новая возможность Android O — программное создание ярлыков и виждетов в лаунчере. Ярлык представляет собой отдельную иконку, позволяющую по клику выполнить задачу в приложении по заданному интенту. Для успешного прикрепления виджета или ярлыка требуется согласие пользователя в системном диалоге-подтверждении.
Вывод
Время, когда Android позволял делать все что угодно, уходят в прошлое. Android расширяет «легальные» инструменты для создания новых функций, закрывает бреши для хаков и заставляет работать честно. Android O ломает часть существующих приложений, но старается сделать конечных пользователей счастливее. Ура, спасибо!
Желаю всем писать хорошие приложения, думать о пользователях и быть счастливыми владельцами Android-устройств.
P.S.
Автор статьи — Александр Шиндин ayushindin.
Саша написал статью и смело заболел, поэтому доверил выложить статью на Хабр мне =)
Пожелаем ему скорейшего выздоравления!
Комментарии (34)
snuk182
01.08.2017 22:19Google старается минимизировать количество работающих фоновых сервисов и предлагает использовать JobScheduler и GcmNetworkManager.
То есть совсем режется возможность запускать вечноживущие сервисы?
agent10
01.08.2017 23:19+1Вы так спрашиваете как-будто это плохо:)
qrck13
01.08.2017 23:25Это и не всегда хорошо. Было бы здорово, если бы они дали пользователю право выбора — разрешить приложению работать в фоне или нет, и по умолчанию — что бы было запрещено. Бывают легитимные ситуации, когда я, как пользователь, очень хотел бы что бы приложение работало в фоне, и не зудело постоянно висящим уведомлением.
agent10
01.08.2017 23:34А можете пример дать, когда действительно это надо(без висящего уведомления)? Я лично не могу придумать особо. Пользователь же всё равно не видит результат вашей фоновой задачи пока не вернётся в приложение, а когда вернётся хз ещё…
dukei
02.08.2017 00:56+1Например, обновление информации на виджетах. Пользователь не желает трогать приложение, но информация на виджетах должна быть все время актуальна.
В последних версиях андроида такие приложения засыпают, виджеты не обновляются, а при входе в приложение начинают все обновляться, что может быть не быстро. А актуальную информацию хочется видеть быстро, для чего приложение и работает в фоне.
qrck13
02.08.2017 09:07+1Например приложения для работы со смарт-гаджетами (кроме Android Wear). Меня лично все время раздражает висящее уведомление от Pebble, которое висит там только за тем, что бы OS не прибила сервис. Своему Android Wear приложению Google как-то разрешили висеть в фоне и не быть убитым.
Или например — есть у меня приложение для календаря, расширяющее его фукнциональность, для чего приложению нужен переодический рескан calendar provider-а. Сейчас все прекрасно работает, приложение раз в 30 минут просыпается на 10 секунд, проверить изменения в календаре, и засыпает дальше. Судя по системной статистике — батарейки на это уходит доля процента в день. Я так полагаю — мне теперь прийдется каждый раз показывать уведомление о том, что «я тут что-то делаю в фоне» при каждом таком просыпании. Пользователи то переживут, но недовольных много будет, да и выглядит это как-то криво.
(10 секунд — это на очень загруженном календаре с многими сотнями событий в месяц, как у меня, если событий меньше — то тратится еще меньше времени).
ulintb
02.08.2017 10:48+2Так для переодических тасков есть JobScheduler + Alarm для старых версий. Зачем держать сервис в фоне все время? Тем более что он и так уже с 6-й версии в сон уходит без WakeLock'а, а с ним батарею жрет.
qrck13
02.08.2017 14:10Сервис и так не висит постоянно. Он просыпается по таймеру, но вот на те 10 секунд работы приходится запускать сервис фоновый, т.к. иначе прилетит сразу ANR. А теперь получается (если я все правильно понимаю) нельзя запустить фоновый сервис по таймеру, только foreground сервис.
ulintb
02.08.2017 16:31Из броадкаста разрешается стартовать сервис на несколько минут, поэтому в вашем случае ничего не поменяется.
snuk182
02.08.2017 11:32+1Любой мессенжер, который не хочет зависить от сторонних, пусть и гугловых, пуш-сервисов. Предугадывая претензии «будет жрать», отвечу — не будет, если нормально написать.
Аналогичное предложенному тут решение было в ранних версиях Windows Phone, но в более поздних таки добавили полноценный неприбиваемый сокет, хоть и неконтролируемый извне и весьма дико выглядящий.
По поводу экономии ресурсов путем прибивания фоновых задач — очень понравился подход Huawei, который предлагает пользователю в настройках питания опции убивания приложения, когда оно не на экране. При этом эта опция включена по умолчанию везде, кроме некоторого списка популярных приложений. В отличие от сторонних менеджеров активности, которые мониторят запуск программ и прибивают их сразу же, что нерационально, встроенная в ядро Android система даже не дает ничему не разрешенному запускаться.
rjhdby
02.08.2017 16:39Например мое приложение для волонтерской программы попавшим в ДТП мотоциклистам. Одна из востребованных пользователями опций — отсылка пуша только если ДТП произошло рядом с ними (расстояние настраивается), а на моте в городе даже 10 минут — это 10 километров при неспешной езде.
lorc
02.08.2017 17:51Запустите foreground сервис. Я, как пользователь, хочу видеть какие программы сейчас реально работают.
q1p
02.08.2017 06:16Как по мне, можно более элегантно решить проблему надоедливого уведомления для foreground service при помощи группировки оных в какую-нибудь секцию в шторке уведомлений (рядом с WiFi, BT и т.п.). Там это не так бросается в глаза, но в то же время может быть более доступным и кастомизируемым (положение, видимость).
Конечно, это yet another icon в шторке, и тем не менее, так аккуратнее и остается понимание того, какие приложения сейчас работают, imho.
madkite
02.08.2017 17:34Так они же ввели Notification Channels — если разработчик приложения сделает иконку foreground сервиса и другие нотификации в разных channel-ах, то пользователь легко может скрыть только channel с foreground сервисом.
bartwell
02.08.2017 10:37+1Время, когда Android позволял делать все что угодно, уходят в прошлое.
Лично для меня как пользователя была бы удобной возможность самостоятельно выбирать, что запрещать, а что нет. Например, мне было не очень удобно, когда они решили запретить сторонним приложениям управлять режимом полета.
F0iL
02.08.2017 11:52+2Вот здесь, кстати, поддержу. Не могу представить себе случая когда зловредам понадобится переводить аппарат в режим полета, зато, к примеру, это теперь мешает сделать приложение для использования телефона в качестве пассивного GPS-маяка в автомобиле (который изредка выходил бы на связь по расписанию).
sergeyfitis
02.08.2017 19:59+1Большинству пользователей или до лампочки(им некогда смотреть) эти настройки или они тупые(ну бывает), включают все настройки подряд и потом жалуются на слабую батарею. Я поддерживаю Google в этих ограничениях. Идут по стезе яблочной компании, потому что поняли, что на разработчиков положится нельзя в плане экономии ресурсов устройства.
Acuna
03.08.2017 02:39Это Вы говорите о приложениях, которые отключали бы режим полета, тем самым тратя батарею (если я правильно Вас понял), однако речь идет о приложениях, которые наоборот включали бы его. У меня рутнутый девайс и сторонняя шторка, которая может включать/выключать его, однако это занимает секунд 5, ибо ждет освобождения процессов. И зачем, спрашивается?
F0iL
02.08.2017 11:57+3И все-таки, даже после улучшения и доработок контроля разрешений, до идеала еще очень далеко. Да, теперь приложения отдельно запрашивают доступ к камере, файловой системе или контактам, но подавляющее большинство при отказе в разрешении просто перестает работать.
Проблему бы решило некое подобие sandbox'а: чтобы при запросе прав доступа были вариант «Разрешить», «Запретить» и «Пусть играется в песочнице».
Программе за каким-то фигом захотелось залезть в список моих контактов? Окей, вот тебе доступ, только контактов что-то нету особо, или есть только несколько фейковых. Понадобился доступ к смс? Вот тебе доступ к сообщениям, только вот не приходило нам сообщений за последнее время что-то (или покажем приложению только те, на которые явно поставил галочку пользователь). Хочется доступа к камере? Вот тебе доступ, только камера у нас снимает заранее заданную статичную картину. И так далее.
attuda
02.08.2017 16:30+3… и захватывающая гонка вооружений: «создать достоверную песочницу» vs «определить, что приложение запущено в песонице и упасть назло хитрому юзеру!»
sergeyfitis
02.08.2017 21:10такое поведение породит только больше проблем как для нас(разработчиков) так и для пользователей, будут миллионы проблем из-за "неверно предоставленного разрешения", недопонимания как это должно работать и тд. Разрешение либо есть, либо его нет.
F0iL
03.08.2017 11:12Если переживать за неопытных пользователей — можно сделать чтобы подобное было отключено по умолчанию, но включалось при наличии понимания своих действий и осознанного желания (как «Настройки для разработчиков» в Andoid, например).
В конце концов, на ПК никого не пугает наличие таких вещи как chroot/fakeroot и sandboxie, и с этим нет никаких проблем.
Bringoff
07.08.2017 09:37подавляющее большинство при отказе в разрешении просто перестает работать.
вы пользуетесь какими-то неправильными приложениями. У меня таким, насколько помню, страдало всего одно.
Acuna
03.08.2017 02:34+1На самом деле для разрабов жарко процесс идет: последний SDK для него признал ProgressDialog deprecated, вместо этого рекомендуется использовать прогресс-бары прямо в адаптерах, но так как все эти рекомендации до сих пор чисто на бумаге уже кучу времени — пока приходится созерцать эти deprecated везде без возможности исправления, дабы не изобретать велосипеды. Для перфекционистов, привыкших иметь галочки перед каждым файлом в проекте, это сущее мученье)
Acuna
03.08.2017 02:41+1И да, удивлен, что название его еще не расшифровано, хотя уже известно в определенных кругах. Oreo. И не благодарите)
LionZXY
04.08.2017 11:32Или Octopus
Acuna
04.08.2017 20:27Да, но оно скорее всего отметется, ибо в Oreo больше сладкого (это печенье черного цвета с белой прослойкой), чем в Octopus, а попробуй докажи юзерам, что Octopus — это на самом деле сладость такая, в форме осминога, мол, вы ничего не понимаете в нейминге.
sergeyfitis
05.08.2017 15:46Или Oatmeal cookie — так называется желтое лого android 8. Название было на IO 2017
Acuna
08.08.2017 22:53Извиняюсь, забыл ответить… Oatmeal cookie, судя по названию — это овсяное печенье? Тоже может быть, правда сладостью это не назовешь) А это из выступления каких лиц на IO?
sergeyfitis
10.08.2017 14:32What's new in notifications, launcher icons, and shortcuts. Тайминг на видео 13:24
FlamyXD
Интересные изменения. Жаль только, что не доберется до моего смартфона.