Android O: особенности поддержки новой операционной системы

    Всем привет! Совсем скоро состоится важное событие – выход Android O. Поддержка новых версий операционной системы – обязанность любого серьезного продукта. Каждое обновление Android заставляет многих разработчиков серьезно поработать для сохранения работоспособности имеющихся функций и привнесения нового благодаря возможностям новых версий Android.


    В данной статье мы рассмотрим основные изменения Android O и оценим их возможное влияние.


    image


    image


    Работая над Android O, разработчики Google в первую очередь решали проблему быстрого расхода заряда аккумулятора на Android-устройствах, поэтому основные изменения связаны с оптимизацией фоновых задач и расхода ресурсов приложения.


    Изменения в Android O можно разделить на две категории:


    1. Потенциально «ломающие» текущую работоспособность и требующие дополнительных усилий для поддержки;


      Угроза 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

    2. Возможности для реализации новых функций.
      Новые возможности Применение
      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 состоят из двух категорий:


    1. Ограничение фоновых сервисов
      После того как приложение перешло в background, у него есть «окно» в несколько минут, в течение которого сервисы могут запускаться и работать. После истечения этого интервала все сервисы останавливаются, а запуск новых будет приводить к падению приложения. Google старается минимизировать количество работающих фоновых сервисов и предлагает использовать JobScheduler и GcmNetworkManager.
      В случае если необходимо выполнять длительные задачи в фоне, рекомендуется использовать foregroundService, который будет явно говорить пользователю, что приложение работает.
      Стоит обратить внимание, что после того как вызвали Context.startForegroundService() необходимо в течение 5 секунд вызвать startForeground(), в противном случае система может показать ANR.
    2. Ограничений на регистрацию 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.
    Саша написал статью и смело заболел, поэтому доверил выложить статью на Хабр мне =)
    Пожелаем ему скорейшего выздоравления!

    Метки:
    «Лаборатория Касперского» 245,42
    Ловим вирусы, исследуем угрозы, спасаем мир
    Поделиться публикацией
    Комментарии 34
    • +2
      Интересные изменения. Жаль только, что не доберется до моего смартфона.
      • 0
        Google старается минимизировать количество работающих фоновых сервисов и предлагает использовать JobScheduler и GcmNetworkManager.

        То есть совсем режется возможность запускать вечноживущие сервисы?
        • +1
          Вы так спрашиваете как-будто это плохо:)
          • 0
            Это и не всегда хорошо. Было бы здорово, если бы они дали пользователю право выбора — разрешить приложению работать в фоне или нет, и по умолчанию — что бы было запрещено. Бывают легитимные ситуации, когда я, как пользователь, очень хотел бы что бы приложение работало в фоне, и не зудело постоянно висящим уведомлением.
            • 0
              А можете пример дать, когда действительно это надо(без висящего уведомления)? Я лично не могу придумать особо. Пользователь же всё равно не видит результат вашей фоновой задачи пока не вернётся в приложение, а когда вернётся хз ещё…
              • +1
                Например, обновление информации на виджетах. Пользователь не желает трогать приложение, но информация на виджетах должна быть все время актуальна.

                В последних версиях андроида такие приложения засыпают, виджеты не обновляются, а при входе в приложение начинают все обновляться, что может быть не быстро. А актуальную информацию хочется видеть быстро, для чего приложение и работает в фоне.
                • +1
                  Например приложения для работы со смарт-гаджетами (кроме Android Wear). Меня лично все время раздражает висящее уведомление от Pebble, которое висит там только за тем, что бы OS не прибила сервис. Своему Android Wear приложению Google как-то разрешили висеть в фоне и не быть убитым.

                  Или например — есть у меня приложение для календаря, расширяющее его фукнциональность, для чего приложению нужен переодический рескан calendar provider-а. Сейчас все прекрасно работает, приложение раз в 30 минут просыпается на 10 секунд, проверить изменения в календаре, и засыпает дальше. Судя по системной статистике — батарейки на это уходит доля процента в день. Я так полагаю — мне теперь прийдется каждый раз показывать уведомление о том, что «я тут что-то делаю в фоне» при каждом таком просыпании. Пользователи то переживут, но недовольных много будет, да и выглядит это как-то криво.

                  (10 секунд — это на очень загруженном календаре с многими сотнями событий в месяц, как у меня, если событий меньше — то тратится еще меньше времени).
                  • +2

                    Так для переодических тасков есть JobScheduler + Alarm для старых версий. Зачем держать сервис в фоне все время? Тем более что он и так уже с 6-й версии в сон уходит без WakeLock'а, а с ним батарею жрет.

                    • 0

                      Сервис и так не висит постоянно. Он просыпается по таймеру, но вот на те 10 секунд работы приходится запускать сервис фоновый, т.к. иначе прилетит сразу ANR. А теперь получается (если я все правильно понимаю) нельзя запустить фоновый сервис по таймеру, только foreground сервис.

                      • 0
                        Из броадкаста разрешается стартовать сервис на несколько минут, поэтому в вашем случае ничего не поменяется.
                  • +1
                    Любой мессенжер, который не хочет зависить от сторонних, пусть и гугловых, пуш-сервисов. Предугадывая претензии «будет жрать», отвечу — не будет, если нормально написать.
                    Аналогичное предложенному тут решение было в ранних версиях Windows Phone, но в более поздних таки добавили полноценный неприбиваемый сокет, хоть и неконтролируемый извне и весьма дико выглядящий.

                    По поводу экономии ресурсов путем прибивания фоновых задач — очень понравился подход Huawei, который предлагает пользователю в настройках питания опции убивания приложения, когда оно не на экране. При этом эта опция включена по умолчанию везде, кроме некоторого списка популярных приложений. В отличие от сторонних менеджеров активности, которые мониторят запуск программ и прибивают их сразу же, что нерационально, встроенная в ядро Android система даже не дает ничему не разрешенному запускаться.
                    • 0
                      тот же Adguard, например
                      • 0
                        Например мое приложение для волонтерской программы попавшим в ДТП мотоциклистам. Одна из востребованных пользователями опций — отсылка пуша только если ДТП произошло рядом с ними (расстояние настраивается), а на моте в городе даже 10 минут — это 10 километров при неспешной езде.
                        • 0
                          Запустите foreground сервис. Я, как пользователь, хочу видеть какие программы сейчас реально работают.
                        • +1
                          Торрентокачалка?
                        • 0

                          Как по мне, можно более элегантно решить проблему надоедливого уведомления для foreground service при помощи группировки оных в какую-нибудь секцию в шторке уведомлений (рядом с WiFi, BT и т.п.). Там это не так бросается в глаза, но в то же время может быть более доступным и кастомизируемым (положение, видимость).
                          Конечно, это yet another icon в шторке, и тем не менее, так аккуратнее и остается понимание того, какие приложения сейчас работают, imho.

                          • 0

                            Так они же ввели Notification Channels — если разработчик приложения сделает иконку foreground сервиса и другие нотификации в разных channel-ах, то пользователь легко может скрыть только channel с foreground сервисом.

                      • +1
                        Время, когда Android позволял делать все что угодно, уходят в прошлое.

                        Лично для меня как пользователя была бы удобной возможность самостоятельно выбирать, что запрещать, а что нет. Например, мне было не очень удобно, когда они решили запретить сторонним приложениям управлять режимом полета.
                        • +2
                          Вот здесь, кстати, поддержу. Не могу представить себе случая когда зловредам понадобится переводить аппарат в режим полета, зато, к примеру, это теперь мешает сделать приложение для использования телефона в качестве пассивного GPS-маяка в автомобиле (который изредка выходил бы на связь по расписанию).
                          • +1

                            Большинству пользователей или до лампочки(им некогда смотреть) эти настройки или они тупые(ну бывает), включают все настройки подряд и потом жалуются на слабую батарею. Я поддерживаю Google в этих ограничениях. Идут по стезе яблочной компании, потому что поняли, что на разработчиков положится нельзя в плане экономии ресурсов устройства.

                            • 0
                              Это Вы говорите о приложениях, которые отключали бы режим полета, тем самым тратя батарею (если я правильно Вас понял), однако речь идет о приложениях, которые наоборот включали бы его. У меня рутнутый девайс и сторонняя шторка, которая может включать/выключать его, однако это занимает секунд 5, ибо ждет освобождения процессов. И зачем, спрашивается?
                          • +3
                            И все-таки, даже после улучшения и доработок контроля разрешений, до идеала еще очень далеко. Да, теперь приложения отдельно запрашивают доступ к камере, файловой системе или контактам, но подавляющее большинство при отказе в разрешении просто перестает работать.
                            Проблему бы решило некое подобие sandbox'а: чтобы при запросе прав доступа были вариант «Разрешить», «Запретить» и «Пусть играется в песочнице».
                            Программе за каким-то фигом захотелось залезть в список моих контактов? Окей, вот тебе доступ, только контактов что-то нету особо, или есть только несколько фейковых. Понадобился доступ к смс? Вот тебе доступ к сообщениям, только вот не приходило нам сообщений за последнее время что-то (или покажем приложению только те, на которые явно поставил галочку пользователь). Хочется доступа к камере? Вот тебе доступ, только камера у нас снимает заранее заданную статичную картину. И так далее.
                            • +3
                              … и захватывающая гонка вооружений: «создать достоверную песочницу» vs «определить, что приложение запущено в песонице и упасть назло хитрому юзеру!»
                              • 0

                                такое поведение породит только больше проблем как для нас(разработчиков) так и для пользователей, будут миллионы проблем из-за "неверно предоставленного разрешения", недопонимания как это должно работать и тд. Разрешение либо есть, либо его нет.

                                • 0
                                  Если переживать за неопытных пользователей — можно сделать чтобы подобное было отключено по умолчанию, но включалось при наличии понимания своих действий и осознанного желания (как «Настройки для разработчиков» в Andoid, например).
                                  В конце концов, на ПК никого не пугает наличие таких вещи как chroot/fakeroot и sandboxie, и с этим нет никаких проблем.
                                  • 0

                                    Слишком много работы для малого количества людей

                                • 0
                                  подавляющее большинство при отказе в разрешении просто перестает работать.
                                  вы пользуетесь какими-то неправильными приложениями. У меня таким, насколько помню, страдало всего одно.
                                • +1
                                  На самом деле для разрабов жарко процесс идет: последний SDK для него признал ProgressDialog deprecated, вместо этого рекомендуется использовать прогресс-бары прямо в адаптерах, но так как все эти рекомендации до сих пор чисто на бумаге уже кучу времени — пока приходится созерцать эти deprecated везде без возможности исправления, дабы не изобретать велосипеды. Для перфекционистов, привыкших иметь галочки перед каждым файлом в проекте, это сущее мученье)
                                  • +1
                                    И да, удивлен, что название его еще не расшифровано, хотя уже известно в определенных кругах. Oreo. И не благодарите)
                                    • 0

                                      Или Octopus

                                      • 0
                                        Да, но оно скорее всего отметется, ибо в Oreo больше сладкого (это печенье черного цвета с белой прослойкой), чем в Octopus, а попробуй докажи юзерам, что Octopus — это на самом деле сладость такая, в форме осминога, мол, вы ничего не понимаете в нейминге.
                                      • 0

                                        Или Oatmeal cookie — так называется желтое лого android 8. Название было на IO 2017
                                        image

                                        • 0
                                          Извиняюсь, забыл ответить… Oatmeal cookie, судя по названию — это овсяное печенье? Тоже может быть, правда сладостью это не назовешь) А это из выступления каких лиц на IO?
                                          • 0

                                            What's new in notifications, launcher icons, and shortcuts. Тайминг на видео 13:24

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

                                      Самое читаемое