Background power mode android

Как работает SystemUI в Android

В этой статье я разберу архитектуру и принцип работы основного приложения Android — SystemUI. Меня заинтересовала эта тема, потому что мне интересно, как устроена система, которой пользуется такое огромное количество пользователей и для которой ежедневно выкатываются тысячи приложений в Google Play или просто на просторы интернета. Помимо этого меня интересует вопрос информационной безопасности Android и создаваемых под него приложений.

В системе Android, SystemUI — это приложение, путь к исходному коду которого находится в platform_frameworks_base/packages/SystemUI/, на девайсе оно находится в system/priv-app/-SystemUI.

priv-app — это каталог, где хранятся привилегированные приложения. К слову, по пути system/app лежат предустановленные приложения, а обычные приложения, которые мы устанавливаем на свой девайс самостоятельно, хранятся в data/app.

Тут сразу возникает вопрос: почему нельзя засунуть все предустановленные и привилегированные приложения в один каталог, зачем нужно это разделение?

Дело в том, что некоторые приложения более системные, чем другие:) И это разделение необходимо для того чтобы уменьшить покрытие эксплойтами системных приложений, для получения доступа к защищенным операциям. Можно создавать приложение, которое будет иметь специальный ApplicationInfo.FLAG_SYSTEM и в системе получит больше прав, однако apk файл с таким разрешением будет помещен в раздел system.

Итак, SystemUI — это apk-файл, который по сути своей обычное приложение. Однако, если посмотреть на сложное устройство SystemUI, перестает казаться, что это всего лишь простое приложение, верно?

Данное приложение выполняет весьма важные функции:

Запуск SystemUI

Как я и говорила выше, SystemUI не похож на обычное приложение, так что его запуск не сопровождается запуском активности, как это происходит у большинства приложений. SystemUI — это глобальный пользовательский интерфейс, который запускается во время процесса загрузки системы и не может быть завершен.

Если мы залезем в SystemServer, который является одним из двух столпов в мире Android (второй — Zygote, но об этом я расскажу как-нибудь в другой раз), то мы можешь найти место, где стартует SystemUI при загрузке системы.

Тут мы видим как запускается сервис SystemUI с помощью непубличного API startServiceAsUser. Если бы вы захотели использовать это, то вам пришлось бы обратиться к рефлексии. Но если вы решите использовать reflection API в Android — подумайте несколько раз, стоит ли это того. Подумайте раз сто:)

Итак, тут создается отдельный процесс для приложения и по факту каждый раздел SystemUI является отдельным сервисом или независимым модулем.

Метод start() вызывается для запуска каждой службы, которые перечислены ниже.

Регулирование громкости

Мы регулярно пользуемся кнопками громкости на своих устройствах, но не задумываемся какие процессы должны произойти в системе для того чтобы мы могли прибавить или убавить звук. Операция кажется довольно простой на словах, но если заглянуть в VolumeUI, который находится в подпапке SystenUI/volume, в разных режимах интерфейс имеет свою вариацию.

Я уже говорила о том, что сервисы SystemUI запускаются методом start(). Если мы посмотрим на класс VolumeUI, то он тоже наследуется от SystemUI.

Тут мы видим что с помощью mEnabled мы определяем, следует ли нам показывать панель с настройкой звука. И судя по VolumeDialogComponent, VolumeUI отображает звуковую панель в виде диалога. Но все действия относительно нажатия на клавиши громкости обрабатываются в PhoneWindow.

Насколько мы видим, KEYCODE_VOLUME_UP (+) не обрабатывается и перейдет в обработку KEYCODE_VOLUME_DOWN (-). И в обоих событиях, как в onKeyDown, так и в onKeyUp вызывается метод dispatchVolumeButtonEventAsSystemService.

Итак, тут у нас вызывается метод adjustVolume, для того чтобы мы могли проверить наш direction, которому будет присвоен параметр события.

В итоге когда мы доберемся до AudioService, где будет вызван sendVolumeUpdate, где помимо вызова метода postVolumeChanged, будет установлен интерфейс HDMI.

RingtonePlayer

RingtonePlayer в Android выполняет роль проигрывателя. Он так же наследуется от SystemUI и в методе start() мы видим:

Здесь у нас устанавливается mCallback, который по сути является экземпляром IRingtonePlayer.

В итоге можно управлять RingtonePlayerService с помощью Binder для воспроизведения звуковых файлов.

PowerUI

PowerUI отвечает за управление питанием и уведомлениями. Аналогично наследуется от SystemUI и имеет метод start().

Как мы видим из приведенного выше кода, происодит подписка на изменения Settings.Global.LOW_POWER_MODE_TRIGGER_LEVEL, а после — вызов mReceiver.init().

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

Задачи

Recents — это основная и часто используемая функция в мобильных устройствах на базе Android.

Главные функции:

• Отображение всех задач
• Переключение между задачами
• Удаление задач

Помимо этого Recents так же наследуется от SystemUI. В RecentsActivity происходит создание и обновление последних задач, чтобы мы могли увидеть их на нашем экране.

А в с помощью RecentTaskInfo мы можем получить информацию о конкретной задаче.

Вообще, запущенные задачи можно вынести в отдельную тему. Я изучила ее со всех сторон, так как хотела размывать экран приложения перед переходом приложения в background, чтобы в RecentsTask отображалась нечитаемая версия снапшота. Однако, проблема заключается в том, что снапшот приложения берется раньше, чем вызывается onPause(). Эту проблему можно решить несколькими способами. Либо выставлять флаг, чтобы система просто скрывала содержимое экрана с помощью

О чем я говорила в предыдущей статье, посвященной как раз снапшотам.

Можно вообще сделать так, чтобы конкретная activity приложения не отображалось в задачах, проставив в манифесте

Либо можно воспользоваться хитростью с помощью

Можно задать основной активности выше приведенный флаг excludeFromRecents = true, для того чтобы ее экран отсутствовал в запущенных задачах, но во время загрузки приложения запустить отдельную задачу, которая будет показывать либо размытый скриншот с основной активности, либо любое другое изображение. Более подробно, как это можно сделать описано в официальной документации на примере Google Drive.

Экран блокировки

Keyguard уже посложнее всех вышеприведенных модулей. Он представляет из себя сервис, который запускается в SystemUI, а управляется при помощи KeyguardViewMediator.

Однако на самом деле KeyguardService самостоятельно не работает с интерфейсом экрана блокировки, он лишь передает информацию в модуль StatusBar, где уже и производятся действия относительно визуального вида экрана и отображения информации.

Панель уведомлений

SystemBars имеет довольно сложное устройство и структуру. Его работа разделяется на два этапа:

1. Инициализация SystemBars
2. Отображение уведомлений

Если посмотреть на запуск SystemBars

То мы видим ссылку на ресурс из которого читается имя класса и создается его экземпляр.

Таким образом мы видим что тут вызывается StatusBar, который будет работать с выводом уведомлений и UI.

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

Источник

Background power mode android

Сообщение отредактировал esleer — 05.04.21, 23:58

С этого поста YouTube Vanced (Пост No_Hammer #73638538) разрешения не давал никакие, все завелось сразу. Android10, Самса A60

1) MicroG
2) Vanced
3) Downloader

Всем доброго времени клуб и отличного дня А может это зависить от настроек может быть в настройках видео что-то накрутить Надо. хотя у меня всё по дефолту стоит, но нет этого пункта Хоть убей 😀 прошивка кастомная Может в этом проблема, но я не думаю что из-за прошивки Дело конечно это же никак не взаимосвязано :unsure:
Так у меня на седьмом андроиде тоже самое, на аппарате huawei
Короче у меня это фича от лукавого работает через кнопку поделиться. Но затем эта падла, просто берёт и крашит приложение после того как скачает :rofl:
И вот ещё наблюдение, такое только в модах происходит, неважно от кого, а с гп, YouTube качает через кнопку поделиться, без вылетов, но самой кнопки также нет.

Сообщение отредактировал pro-droid — 24.05.20, 17:44

Источник

Работа с фоновыми задачами в Android 12: переезжаем с foreground service на expedited jobs

С релизом Android 12 приложения, где новая версия операционки будет указана в targetSdkVersion, получат запрет на запуск foreground-сервисов в бэкграунде. В качестве альтернативы Google предлагает WorkManager, который с появлением expedited jobs станет предпочтительным вариантом для запуска высокоприоритетных фоновых задач.

О нём и пойдёт речь в статье — под катом обсудим новые возможности инструмента, подключим его к приложению и реализуем миграцию с foreground-сервиса.

WorkManager и foreground service

Foreground service — это какой-либо сервис, о котором знает пользователь через нотификацию в статус-баре. Например, воспроизведение музыки или работа GPS в картах.

WorkManager — это API для планирования задач, которые будут выполняться, даже если выйти из приложения или перезагрузить устройство.

WorkManager уже давно является приоритетным способом выполнения длительных фоновых задач. К таким относятся синхронизация данных с бэкендом, отправка аналитики, периодическая проверка свободного места в системе с помощью PeriodicWork и так далее.

Но в WorkManager присутствовал и недостаток — не было никаких гарантий, что джоба начнётся незамедлительно после создания. В версии 2.3.0 разработчики добавили для воркеров метод setForegroundAsync(), который, по сути, превращал фоновую задачу в foreground-сервис и позволял немедленно приступить к её выполнению.

Такой подход ничем особо не отличался от разработки foreground-сервиса вручную, когда необходимо создавать объекты Notification и NotificationChannel при таргете выше, чем на Android Nougat.

Сейчас setForegroundAsync() объявлен устаревшим, а при попытке запустить сервис из бэкграунда на выходе будет ForegroundServiceStartNotAllowedException.

Expedited jobs

Этот тип джобов позволяет приложениям выполнять короткие и важные задачи, давая системе больше контроля над доступом к ресурсам. Он находится где-то между foreground-сервисами и привычными джобами WorkManager. От последних их отличает:

минимально отложенное время запуска;

обход ограничений Doze-mode на использование сети;

меньшая вероятность быть «убитыми» системой.

А ещё в них не поддерживаются ограничения по заряду батареи и режиму работы девайса:

У expedited job больший приоритет на ускоренный запуск, поэтому операционная система строже регулирует их количество. Например, если попытаться запланировать джобу при исчерпаном лимите, то сразу вернётся JobScheduler#RESULT_FAILURE.

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

Миграция foreground service на expedited job

Стандартный сервис для выполнения фоновых задач обычно выглядит примерно так:

А запускается так:

Поговорим о том, как перевести этот сервис на expedited job. Происходит это буквально в три простых шага.

1. Подключаем WorkManager к проекту:

2. Создаём класс, наследующийся от Worker (он будет выполнять задачу, которую раньше делал сервис):

3. Создаём WorkRequest и передаём его для запуска в WorkManager:

Здесь есть важный параметр OutOfQuotaPolicy, который отвечает за поведение при невозможности запустить джобу немедленно. Он существует в двух вариантах:

RUN_AS_NON_EXPEDITED_WORK_REQUEST — при заполненной квоте запустится обычная джоба, не expedited.

DROP_WORK_REQUEST — при заполненной квоте запрос на выполнение сразу зафейлится.

На этом, собственно, базовая миграция заканчивается.

Вместо заключения

Переехать на expedited job довольно легко, особенно, если в проекте уже подключен WorkManager.

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

Источник

How to Stop Android From Killing Apps Automatically in Background [All OEMs]

Last Updated on February 18, 2021 by Amar Ilindra 12 Comments

Android OEMs (Original Equipment Manufacturer) Huawei, Xiaomi, OnePlus, Samsung, Oppo, Vivo are literally turning smartphones into lazyphones. Have you ever notice your Android killing apps in the background and they suddenly stop working? I’m sure you must have seen this problem in automation apps like Notification History Log, Tasker, Wear apps, and more.

Do you know why these apps stop working on your device but continue to work flawlessly on devices running on Stock Android? If you don’t know, your device manufacturer is the culprit.

Google has already taken care of limiting background services and optimizing battery usage with Doze mode. But many OEMs have again added multiple layers of meaningless restrictions in the name of squeezing extra battery. These limitations are by default enabled for every app you download except popular apps (which are whitelisted internally) and users are unaware of it.

And for Android developers, it was a nightmare. Developers follow Google policies and they show persistent notification while running long background tasks. But even with persistent notifications, the background services are being killed by OEMs because an app is not on the whitelisted list.

One of our apps Notification History Log is also badly affected due to different restrictions imposed by different Android OEMs. The worst part is, each OEM has different implementations and no official APIs are available for requesting users to whitelist our app.

• If you are a user and notice an app stops working suddenly, please don’t leave 1-star reviews on Play Store. Try to contact the app developer first to understand why the app is misbehaving.
• If you are an OEM, please stop adding new restrictions on apps. Use Stock Android instead. It saves both you and developers a lot of time and money.

Since a lot of users and developers are looking for a solution to stop Android from killing apps in the background. We decided to write this guide to help users, developers, and our Notification History Log users.

Prevent Apps From Being Killed Automatically in your Android Smartphone

For convenience, we have taken the Notification History Log app as the app name and we’ll explain the steps in detail to whitelist it from all popular OEMs which are turning smartphones to lazyphones. If you don’t find your OEM in the list, choose “Others” to know the common steps.

Choose your manufacturer

• • 
  • 
  • 
  • 
  • 
  • 
  • 
  • 

Huawei

Huawei is well known for breaking app functionalities and developers will frequently get reports from Huawei users. We are not an exception. Over 50% of emails and 1-star reviews we receive are from Huawei devices. Unfortunately, there was no straightforward solution to whitelist Notification History Log or any other app in EMUI.

From EMUI 9, Huawei has added a new application called PowerGenie which will kill all apps unless it is whitelisted in PowerGenie app. Unfortunately, PowerGenie has no customization options available to add more apps to the whitelist and you can also uninstall/disable PowerGenie completely.

This means it is not possible to fix the problem correctly in EMUI 9. Still, it is recommended to try the common steps to temporarily solve the problem.

If you find Notification History Log or any other apps stopped working on your Huawei device, please follow the below steps to make changes in your phone settings:

Note : You might not find all the below-mentioned options on your mobile. You can safely ignore them if they are not available on your Huawei mobile.

Change 1:

1. Go to phone Settings
2. Select Advanced Settings.
3. Tap on Battery Manager.
4. Change the Power plan to Performance.

Change 2:

1. Go to phone Settings.
2. Select Advanced Settings.
3. Open Battery Manager and tap on Protected apps.
4. Set Notification History Log (or any app of your choice) as Protected.

Change 3:

1. Go to phone Settings
2. Select Apps.
3. Choose Notification History Log (or any app of your choice) from the list.
4. Tap on Battery.
5. Disable Power-intensive prompt.
6. Disable Close after screen locked.
7. Enable Keep running after screen off (if available).

Change 4:

1. Go to phone Settings
2. Tap on Apps.
3. Click the Settings / Gear icon at the bottom.
4. Under Advanced, select Special Access.
5. Now click on Ignore battery optimization and change “Allowed” to “All apps”.
6. Choose Notification History Log (or any app of your choice) from the list and set it to Allow.
7. Hit OK to confirm the changes.

Samsung

In the latest Samsung flagship devices, a new feature called Sleeping Apps is added. Apps that are included in this “Sleeping Apps” list will never run in the background, will never receive updates, and even can not show notifications. You need to first make sure the Notification History Log (or any app of your choice) is not added to “Sleeping Apps”.

Make the following changes in your Samsung device to stop apps from being killed automatically:

Change 1:

1. Go to phone Settings.
2. Open Device Care.
3. Tap on Battery.
4. Click on 3-vertical dots on the top right and select Settings.
5. Here you need to disable
   • Adaptive Battery
   • Put unused apps to sleep
   • Auto disable unused apps
6. After disabling the above options, now click on Sleeping Apps.
7. Click on the Trash icon on the top-right to remove all applications from sleep.

Change 2:

On Samsung Galaxy S8, there is yet another feature called App Power Monitor which keeps apps to sleep when not used for 3 continuous days. But there will be plenty of apps that work in the background to sync data, monitor notifications, alarms, etc, which will not be opened every day but still need to function. In this case, you need to disable App Power Monitor as explained below.

1. Open phone Settings
2. Tap on Device maintenance.
3. Select Battery.
4. Disable App Power Monitor.

Change 3:

On other Samsung devices, follow the steps below to disable battery optimization:

1. Go to phone Settings.
2. Tap on Applications.
3. Click 3-vertical dots on the top right corner and select Special Access.
4. Select Optimize Battery usage.
5. Select Notification History Log (or any app of your choice) from the list and change it to Don’t optimize.

Change 4:

On older version on Samsung devices, you need to disable power saving modes as follows:

1. Open phone Settings
2. Select Battery.
3. Click Power saving mode and turn it off.
4. Click Ultra power-saving mode and turn it off.

OnePlus

OnePlus is very popular for its stunning Oxygen OS UI and features. But coming to battery optimization, it has its own limits and disadvantages. Being a user, you need to make a few changes in your phone settings to stop OnePlus from killing the apps that run in the background.

Here are the most common changes you need to make to prevents apps from killing automatically:

Change 1:

1. Go to phone Settings.
2. Tap on Apps.
3. Click on Gear icon on the top right and tap on Special Access.
4. Click on Battery.
5. Choose Notification History Log from the list and change it to Not optimize.

Due to a bug in Oxygen OS, OnePlus might revert this change randomly anytime. So you need to keep an eye and change it again to “Not Optimize” if it reverts to default sometime later.

One quick solution to prevent this problem:

1. Open Notification History Log (or any other app) you wish to run in the background.
2. Tap on recent apps button to see the list of minimized apps.
3. Now click on the Lock button on the top-right of the app preview.

Once you lock the app, it will keep running in the background and battery optimization setting will never change to default.

Change 2:

On a few OnePlus models, you need to make sure App Auto-Launch is enabled for your app. To do this:

1. Go to phone Settings.
2. Tap on Apps.
3. Click on Gear icon on the top right and tap on App auto-launch.
4. Now enable App auto-launch for Notification History Log (or any app of your choice).

Change 3:

If you are still facing random killing of app’s background services, try doing the following change:

1. Go to phone Settings.
2. Tap on Battery.
3. Select Battery optimization.
4. From the top drop-down menu, change the type to All Apps.
5. Select Notification History Log (or any app of your choice) from the list and change it to Don’t optimize.

In a few Asus devices, Power Master app was pre-installed which will automatically kill background tasks when your phone screen is turned off and it also stops them from restarting. To make sure your Asus device will never kill the background running apps, you need to do the following changes on your device:

1. Open PowerMaster application.
2. Select Battery-saving options.
3. Turn off Clean up in suspend.
4. Turn off Auto-deny apps from auto starting.
5. Click back and now select Auto-start manager.
6. Tap on the Downloaded tab and enable Notification History Log (or any app of your choice).

Nokia

Few Nokia smartphones come with Power Saver application pre-installed which is responsible for killing apps that running in the background. Unfortunately, there is only a temporary solution available to fix this problem in Nokia devices:

1. Go to phone Settings.
2. Tap on Apps.
3. Select All Apps.
4. Tap on three vertical dots menu or gear icon on the top-right corner and select Show system.
5. Scroll down to tap on Power Saver application and Force Stop it.
6. If Uninstall button is available, you can uninstall Power Saver application to fix the problem permanently. Sadly, the uninstall option is enabled only on a few sets of Nokia devices.

Note: Power Saver application can anytime restart itself and you may need to force stop it whenever you notice the apps you use starts misbehaving.

Lenovo

Lenovo mobiles very rarely kill the background apps but there are few Lenovo devices that will instantly kill entire app processes when it is swiped away from running apps. Here is the quick solution for Lenovo users:

Change 1:

1. Go to phone Settings.
2. Select Apps.
3. Choose Notification History Log (or any app of your choice) from the list.
4. Tap on Battery.
5. Change “Not optimized” to All Apps.
6. Again select Notification History Log (or any app of your choice).
7. Change to Don’t Optimize and hit Save/Done.

Change 2:

1. Open Notification History Log (or any app of your choice).
2. Tap on recent apps button to see the list of minimized apps.
3. Click on the Lock button on top of the app preview.

Xiaomi

Xiaomi’s MIUI was loved by 50% of Android users and the rest of them just hate it. I’m sure 100% of developers hate MIUI for its poor APIs, documentation and bug tracking. For Notification History Log, we have completely excluded all Xiaomi mobiles (except Mi A series) from the list of supported devices.

Unfortunately for developers, no APIs are available for requesting users to make the changes or to check user settings information. Fortunately for users, they can do (a lot of) changes in their phone settings to stop MIUI from killing the background running apps:

Change 1:

1. Open Security App.
2. Tap on Permissions. (If you don’t find Permissions option on Security app home screen, it will be inside “Manage Apps” on few models)
3. Select Auto-start.
4. Now Enable auto-start for Notification History Log (or any app of your choice).

Change 2:

1. Open Security App.
2. Tap on Battery.
3. Select App Battery Saver.
4. Choose Notification History Log (or any app of your choice).
5. Set it to No Restrictions.

Change 3:

1. Open phone Settings.
2. Click on Apps.
3. Select Notification History Log (or your app of choice).
4. Tap on Other permissions.
5. Enable Start in background.

Change 4:

1. Open phone Settings.
2. Select Advanced Settings.
3. Tap on Battery manager.
4. Set the Power plan to Performance.

Change 5:

1. Open phone Settings.
2. Select Advanced Settings.
3. Tap on Battery manager.
4. Choose Protected Apps.
5. Make sure Notification History Log (or your app of choice) is added to list of protected apps.

Change 6:

1. Open phone Settings.
2. Click on Apps.
3. Select Notification History Log (or your app of choice).
4. Tap on Battery.
5. Enable Power-intensive prompt.
6. Enable Keep running after screen off.

Change 7:

1. Open phone Settings.
2. Select Additional Options.
3. Tap on Battery & Performance.
4. Open Manage apps battery usage.
5. Now disable Power Saving Modes.

Bonus: When you click on recent apps button at the bottom of your screen, drag the app preview downwards to pin the app. When you do this, the app will not be removed when you clear recent apps and background process of the app continue to work indefinitely.

Pixel, Nexus, and Other Stock Android Devices

Devices running on Stock Android very rarely notice apps killing in background issues. You need to first make sure you are not using any speed booster or RAM cleaner applications. If you use any similar applications which claim to improve your device speed, uninstall them immediately. They won’t work as promised and even sometimes slow down your device.

In devices running on Android Pie or higher, make sure you have NOT accidentally enabled background restrictions to Notification History Log (or any app of your choice). You can verify it at phone Settings > Apps > Notification History Log (or any app of your choice) > Advanced > Battery > Background restrictions.

If everything fails and you still face the problem, try disabling battery optimization as shown below:

1. Go to phone Settings.
2. Select Apps & notifications.
3. Choose Notification History Log (or your app of choice).
4. Tap on Battery.
5. Change the dowp-down value from “Not optimized” to All Apps.
6. Scroll down to select Notification History Log (or your app of choice).
7. Change to Don’t Optimize.
8. Hit the Done button to confirm the change.

Conclusion

Due to thousands of Android devices in the market and tens of OEMs, it is impossible to follow one single step to stop Android from killing apps in the background. And the worst part is, even devices from the same manufacturer come with different settings and options. I wish Google solves this fragmentation problem in Android and make it easier like iOS.

Being a user, all you have to do is, try the changes I have mentioned above for your device and see if it stop apps from being killed in the background. Since each device comes with different features and options, you might not find a few above settings on your mobile. In this case, you can either ignore it or check if any similar terms are available in your settings.

Источник