Open system settings android

Настройки в Android-приложениях

Интересуюсь темой разработки под Android. Пишу небольшое приложение. Столкнулся с тем, что не до конца понимаю как правильно делать настройки для приложения. Немного погуглил, нашел статью, которая помогла разобраться. Решил перевести статью для русскоязычного сообщества, включив некоторые комментарии к оригиналу.

Настройки являются важной частью приложений на Android (и не только на Android — здесь и далее примечание переводчика). Это очень важно — позволять пользователям изменять настройки приложения, в зависимости от их предпочтений.

Существует два пути работы с настройками в Android — можно создать файл preferences.xml в директории res/xml, либо работать с настройками из кода. В данной статье я покажу как работать с настройками, используя preferences.xml файл.

Элементы настроек имеют следующие атрибуты:

• android:key — имя настройки, по поторому в дальнейшем можно получить ее значение
• android:title — заголовок элемента настройки
• android:summary — краткое описание элемента настройки
• android:defaultValue — значение по умолчанию

В настоящее время доступны следующие типы элементов настроек:

• CheckBoxPreference — простой чекбокс, который возвращает значения true или false.
• ListPreference — группа переключателей (radioGroup), из которых может быть выбран только один элемент. Атрибут android:entries указывает на массив со значениями в res/values/arrays.xml, а android:entryValues на массив с подписями.
• EditTextPreference — показывает диалоговое окно с полем ввода. Возвращает строку в качестве значения.
• RingtonePreference — группа переключателей с выбором рингтона.
• Preference — настройка, работающая как кнопка.
• PreferenceScreen — экран с настройками. Когда один PreferenceScreen вложен в другой, то открывается новый экран с настройками.
• PreferenceCategory — категория настроек.

Экран с настройками	EditTextPreference
ListPreference	RingtonePreference
PreferenceScreen

Скриншоты выше были сгенерированы при помощи следующего preferences.xml:

Атрибуты android:entries и android:entryValues у ListPreference ссылаются на @array/listArray и @array/listValues соответственно. Значения берутся из res/values/arrays.xml, который в нашем случае выглядит следующим образом:

Для того, чтобы показать пользователю экран с настройками, небходимо создать активити, унаследованное от PreferenceActivity. Пример активити:

А вызвать активити с настройками можно, нажав на кнопку на нашем главном активити:

Для того, чтобы использовать выставленными в настройках значениями, добавим метод getPrefs() в главное активити, который нужно вызывать на событии onStart(). Нужно использовать именно onStart(), а не onCreate(), для того, чтобы быть уверенным в том, что используются актуальные настройки, а не те, что были во время создания гланого активити. Наш метод getPrefs() может выглядеть примерно вот так:

Источник

How to open Android Settings programmatically with Java

Carlos Delgado

Learn how to open dinamically the settings of Android in your app easily

In case your app needs that your user make some changes in the Settings menu i.e to set a default app to open a specific type of files etc, you may like to make this task easier for your user by starting the Settings menu of Android dinamically from your app.

Show system settings

To display the Settings page programmatically, you can use the startActivityForResult method with an Intent object and a constant of the Settings, the following example should open the general settings menu of Android:

The usage of the ACTION_SETTINGS constant with startActivityForResult will show system settings. The Settings provider contains global system-level device preferences.

Access specific settings areas

The following list contains all the constants that provide access to different areas of the settings menu:

Note: not all the constants are available on every Android version. In case you need more information visit the official documentation here.

Constants of android.provider.Settings

Activity Action: Show settings for accessibility modules.

Activity Action: Show add account screen for creating a new account.

Activity Action: Show settings to allow entering/exiting airplane mode.

Activity Action: Show settings to allow configuration of APNs.

Activity Action: Show screen of details about a particular application.

Activity Action: Show settings to allow configuration of application development-related settings.

Activity Action: Show settings to allow configuration of application-related settings.

Activity Action: Show battery saver settings.

Activity Action: Show settings to allow configuration of Bluetooth.

Activity Action: Show settings for video captioning.

Activity Action: Show settings to allow configuration of cast endpoints.

Activity Action: Show settings for selection of 2G/3G.

Activity Action: Show settings to allow configuration of date and time.

Activity Action: Show general device information settings (serial number, software version, phone number, etc.).

Activity Action: Show settings to allow configuration of display.

Activity Action: Show Daydream settings.

Activity Action: Show settings to configure the hardware keyboard.

Activity Action: Show Home selection settings.

Activity Action: Show screen for controlling background data restrictions for a particular application.

Activity Action: Show screen for controlling which apps can ignore battery optimizations.

Activity Action: Show settings to configure input methods, in particular allowing the user to enable input methods.

Activity Action: Show settings to enable/disable input method subtypes.

Activity Action: Show settings for internal storage.

Activity Action: Show settings to allow configuration of locale.

Activity Action: Show settings to allow configuration of current location sources.

Activity Action: Show settings to manage all applications.

Activity Action: Show settings to manage installed applications.

Activity Action: Show Default apps settings.

Activity Action: Show screen for controlling which apps can draw on top of other apps.

Activity Action: Show screen for controlling which apps are allowed to write/modify system settings.

Activity Action: Show settings for memory card storage.

Activity Action: Show settings for selecting the network operator.

Activity Action: Show NFC Sharing settings.

Activity Action: Show NFC Tap & Pay settings

This shows UI that allows the user to configure Tap&Pay settings.

Activity Action: Show NFC settings.

Activity Action: Show Notification listener settings.

Activity Action: Show Do Not Disturb access settings.

Activity Action: Show the top level print settings.

Activity Action: Show settings to allow configuration of privacy options.

Activity Action: Show settings to allow configuration of quick launch shortcuts.

Activity Action: Ask the user to allow an app to ignore battery optimizations (that is, put them on the whitelist of apps shown by ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS ).

Activity Action: Show settings for global search.

Activity Action: Show settings to allow configuration of security and location privacy.

Activity Action: Show system settings.

Activity Action: Show the regulatory information screen for the device.

Activity Action: Show settings to allow configuration of sound and volume.

Activity Action: Show settings to allow configuration of sync settings.

Activity Action: Show settings to control access to usage information.

Activity Action: Show settings to manage the user input dictionary.

Activity Action: Modify Airplane mode settings using a voice command.

Activity Action: Modify Battery Saver mode setting using a voice command.

Activity Action: Modify do not disturb mode settings.

Activity Action: Show settings to configure input methods, in particular allowing the user to enable input methods.

Activity Action: Show settings to allow configuration of VPN.

Activity Action: Show VR listener settings.

Activity Action: Allows user to select current webview implementation.

Activity Action: Show settings to allow configuration of a static IP address for Wi-Fi.

Activity Action: Show settings to allow configuration of Wi-Fi.

Activity Action: Show settings to allow configuration of wireless controls such as Wi-Fi, Bluetooth and Mobile networks.

Activity Extra: Limit available options in launched activity based on the given account types.

Activity Extra: Enable or disable Airplane Mode.

Activity Extra: Limit available options in launched activity based on the given authority.

Activity Extra: Enable or disable Battery saver mode.

Activity Extra: Enable or disable Do Not Disturb mode.

Activity Extra: How many minutes to enable do not disturb mode for.

Activity Category: Show application settings related to usage access.

Metadata key: Reason for needing usage access.

For example, you can open directly the Language Settings of the device (to change language) executing:

With the introduction of new Android APIs, there will be more settings available areas with different constants, read the official documentation of android provider settings here.

Add the permissions if required

For some special areas of the Android Settings, you will need permissions. For example, to open the bluetooth settings you’ll need to add the following bluetooth permissions in your app manifest:

And then you’ll be able to open the bluetooth settings:

Otherwise you’ll get the following exception:

Источник

Как работает 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 является одной из самых важных частей этой системы и мне понравилось изучать ее. Из-за того что материала на эту тему очень мало, если вы заметите какие-либо ошибки, прошу исправить меня.

Источник