Как отключить предупреждение о громкости на Android —
Многие пользователи Android хотят знать, как отключить предупреждение о безопасной громкости на устройствах Android. Это может раздражать, когда вы хотите максимизировать громкость и должны принять диалог, чтобы поднять громкость на определенную величину. Причина, по которой телефоны Android делают это, связана с правилами, установленными Европейским комитетом по электротехнической стандартизации, которые предписывают, что устройства воспроизведения мультимедиа должны иметь максимальное выходное значение 85 дБ — 85 дБ, а пользователь должен принять предупреждение.
Это затрудняет работу пользователей Android, особенно если вы, например, запускаете воспроизведение мультимедиа на удаленном устройстве Bluetooth. К счастью, существует множество способов навсегда отключить предупреждение о предельном уровне громкости, и в этом руководстве по Appual вы найдете для этого корневые и некорневые методы.
Как отключить предупреждение о громкости на No Root Android
Требования:
Первое, что вам нужно сделать, это загрузить все требования, а затем включить отладку по USB на вашем Android-устройстве.
Зайдите в Настройки> О программе> нажмите номер сборки 7 раз, пока не активируется режим разработчика. Затем перейдите в «Настройки»> «Параметры разработчика»> «Включить отладку по USB».
Нам нужно предоставить WRITE_SECURE_SETTINGS приложению AutoTools, потому что в основном мы настраиваем флаг в настройке манифеста Android. Класс Global — приложения почти никогда не имеют разрешения изменять что-либо в манифесте Android, потому что это даст приложению огромное количество контроля над вашим устройством, но, к счастью, с АБР мы можем предоставить это разрешение.
Так что запустите терминал ADB на вашем компьютере (удерживая Shift + правый клик внутри вашего основного пути ADB и выберите «Открыть окно команд здесь»).
В терминале ADB введите следующую команду:
Теперь, когда AutoTools может записывать в манифест, мы собираемся настроить Tasker, чтобы он давал команду AutoTools на отключение безопасного звука при загрузке.
Запустите приложение Tasker и создайте новый профиль, нажав значок + в правом нижнем углу.
Добавить новый Событие контекст и перейти к Tasker> Monitor Start. Мы собираемся использовать контекст события для запуска при запуске Tasker, а не при загрузке телефона, потому что это более надежный метод — но Tasker запускается при загрузке телефона в любом случае, так что это почти то же самое.
Нажмите кнопку назад и создайте новый задача связан с этим профилем. На экране создания задачи нажмите значок + в нижней средней части экрана, чтобы создать новый действие.
Для действия установите его на Задача> Ждать и подождите 30 секунд. При этом применяется правило «30 секунд после загрузки», которое Android использует для установки безопасного уровня громкости.
Далее вам нужно будет создать новый действие и перейти к Плагин> Автоинструменты> Настройки безопасности. Нажмите кнопку карандаша, чтобы открыть меню конфигурации для AutoTools.
Идти к Пользовательские настройки и настроить его именно такой:
Убедитесь, что вы все правильно вставили, иначе это не сработает.
Теперь вернитесь в главное меню Tasker, и мы создадим новый профиль. Это будет для людей, которые почти никогда не перезагружают свои устройства Android — причина, по которой мы должны это сделать, заключается в том, что Android автоматически сбрасывает безопасный предел громкости через 20 часов. Когда вы перезагружаете свой телефон, мы, конечно, сбрасываем этот лимит, но если вы почти никогда не перезагружаете свое устройство Android, нам нужен отдельный профиль Tasker, чтобы периодически сбрасывать таймер на пределе безопасной громкости.
В Tasker создайте новый профиль с Время контекст.
Установите для параметра «Редактирование времени» одинаковое время для «От» и «До» — это потому, что мы хотим, чтобы Задача запускалась только один раз в определенное время. 23:59 хорошо, как видно на скриншоте ниже.
Для задачи действие, просто делай то же, что и для предыдущего профиля.
Перезагрузите телефон, и предупреждение о безопасной громкости должно быть отключено!
Как отключить предупреждение о томе на Android с рутом
Для устройств на базе Android это гораздо проще — буквально тонна загружаемых настроек и модулей для достижения того, что мы хотим. Лучший способ будет через Xposed.
Если на вашем Android-устройстве не установлена программа Xposed, полезно прочитать следующие руководства Appual:
В любом случае, после того, как вы установили Xposed на ваше устройство Android, появятся многочисленные модули Xposed, которые отключат предупреждение о безопасной громкости. Лучшие из них:
GravityBox (в разделе «Media Tweaks» опция предупреждения о безопасной громкости не найдена) — для GravityBox выберите модуль, соответствующий вашей версии Android! Например, GravityBox [N] для устройств Androud Nougat, GravityBox [MM] для устройств Marshmallow и т. Д.
После установки модуля по вашему выбору, просто включите его и перезагрузите телефон, чтобы активировать его, затем настройте модуль при необходимости (например, GravityBox — NSVW должен работать немедленно).
How to Automatically Disable the High Volume Warning without Root
Those of you who live in one of the member nations of the European Union have probably come across the warning when trying to raise the volume ofВ your headphone as shown in the feature image above.
According to regulations set by the European Committee for Electrotechnical Standarisation (CENELEC), all electronic devices capable of media playback sold after February 2013 must have a default output volumeВ level of a maximum 85 dB. Users can choose to override the warning to increase the volume to a maximum of 100 dB, but in doing so the warning must re-appear after 20 hours of music playback.
While we aren’t going to get into a debate about the efficacy of this regulation in promoting good health, users who frequently choose to bypass this warning often wonder if this process can be automated. There are many cases where it is rather annoying having to manually agree to override the volume limit, such as when you start music playback remotely on a Bluetooth device, so we wanted to set about figuring out a way to automatically bypass this warning.
Solutions to bypass the “safe volume limit” already exist if you search our forums, but so far all of the solutions have required you to install an Xposed Module. This necessarily limits who can use it, as the Xposed Framework requires you to have root access (which means an unlocked bootloader on most phones) as well as being on pre-Nougat versions of Android. But after digging into AOSP and various system settings, I’ve discovered a way to bypass the high volume/safe audio limitВ on all devices without requiring root.
By following this guide, you accept any risks involved with listening to media at high volume levels.
Safe Audio Warning Bypass Tutorial
If you’ve read my previous article on enabling Immersive Mode without root access, then you may have started playing around with some of the settings you can find hidden on your phone. If you haven’t, I highly recommend you do, as I’ve found that almost every device has a ton of goodies just waiting to be discovered. This trick is no different as we’ll be using a system property to bypass the safe audio warning.
Specifically, we will be modifying the System.Global propertyВ audio_safe_volume_state both on boot and periodically so Android will always think you have consented to bypass the warning. This property is defined in AOSP, which we’re reproducing below. There are several states this property can take, ranging from 0-3. 30 seconds after boot or after every 20 hours of continuous music playback, the state is set to ‘0’ or ‘not configured.’ It is then set to ‘1’ for ‘disabled’ or ‘3’ for ‘enabled’ depending on your Mobile Country Code. If you live in the E.U., this property is set to ‘3’ by default but is changed to ‘2’ for ‘inactive’ whenever the user manually bypasses the volume warning.В We will be changing the value of this property to the ‘inactive’ state (changing it to ‘disabled’ never worked for me, in case you’re wondering).
Safe Media Volume Implementation in AOSP
You’ll first need to installВ Tasker and AutoToolsВ so we can automate this trick. Technically, any other automation app apart from Tasker can be used, but I’m only familiar with Tasker so you’ll have to make adjustments on your own if you prefer using a different app. AutoTools, though, is critical to this trick as this plug-in will allow us to control Secure Settings on our device.
As explained in my article on toggling Immersive Mode, we need toВ grant theВ WRITE_SECURE_SETTINGS permission to AutoTools. This is because the command for controlling the safe audio volume stateВ is defined under theВ Settings.Global class, though the exact syntax for the command is hidden in AOSP (just like it was for Immersive Mode). If you’ve already granted the WRITE_SECURE_SETTINGS permission to AutoTools after having read my previous tutorial on Immersive Mode, then you can skip the next section. If not, then you’ll have to set it up.
Granting Secure Settings Permission to AutoTools
Under Android’s permission management system, applications define the permissions they want to be granted in the Manifest file. Users can then grant or deny permissions on installation (pre-Marshmallow) or on demand (Marshmallow+). However, there are certain permissions that applications cannot be granted even if they request it in the Manifest, such as WRITE_SECURE_SETTINGS. This is because granting any application a permission as powerful as this would give that app a ton of control over your device.
But there is one workaround that we can use to grant the WRITE_SECURE_SETTINGS permission to any app we want. By using ADB‘s package manager (pm) tool, we can grant any permission to any application we want (provided that application requests that permission in the Manifest file).
The first thing you’ll need to do is install the ADB binaryВ onto your computer followed by the right driver for your device. Then, enable USB Debugging in Developer Options (go to Settings –> About Phone and tap on Build number 7 times if you haven’t already) and connect your phone to your computer. Finally, send the following command once you’ve opened up a terminal:
adb shell pm grant com.joaomgcd.autotools android.permission.WRITE_SECURE_SETTINGS
Now AutoTools will have the ability to change any Global, Secure, or System setting on your device. There are various ways you can play around with these settings, and the list of available settings in each category completely depends on your device and software build, but that discussion is for another time. In any case, we’ll move on show you how to use AutoTools to control the safe volume state.
Disabling Safe Audio Warning on Boot
Here’s the description of the profile for those of you who are familiar with Tasker. If you aren’t familiar with Tasker, read on for step-by-step instructions.
Disable Safe Audio on Boot
Open up Tasker so we can create a new profile. At the bottom right hand corner tap on theВ + icon to create a new profile. AddВ an newВ Event context and go toВ Tasker –> Monitor Start. We are using this Event context which triggers when Tasker starts up rather than the Event context which activates when the phone boots because the former is far more reliable than the latter.
In any case, press the back button as we will now create a Task associated with this profile. Name the Task anything as it doesn’t matter. Once you enter the Task creation screen, press on theВ + icon in the bottom middle of the screen to create a new Action. For the first action, go toВ Task –> Wait and have it wait forВ 30 seconds. This accounts for the “30 second after boot” rule used in Android to set the safe volume state.
Next, create a new Action and go toВ Plugin –> AutoTools –> Secure Settings. Press the pencil to open the configuration screen for AutoTools. Go toВ Custom Setting. For theВ Setting Type enterВ Global. For theВ Name enterВ audio_safe_volume_state. For the Input Type make itВ int. For the Value make itВ 2. Check to make sure you put everything correctly, the configuration should match the middle screenshot below. The command must be sent exactly as I’ve written or it will not have any affect.
Once you’re done, back out to the main menu of Tasker as we’ll need to create another profile. The one we just created accounts for when the safe volume state is set 30 seconds after boot, but for those of you who almost never reboot your device we’ll make another profile to periodically set this value.
Disable Safe Audio Warning Periodically
Here’s the description of the profile for those of you who are familiar with Tasker. If you aren’t familiar with Tasker, read on for step-by-step instructions.
Disable Safe Audio Periodically
Create a new profile, this time with aВ Time context. Unfortunately I’m not aware of any method to get the current cumulative time of media playback without root, so we’ll instead just periodically set the safe volume state to inactive once every 24 hours (… it’s not like you guys actually listen to 20 hours of music within a 24 hour period, right?). Anyways, Tasker’s interface for setting a periodic Task is kind of terrible, but the gist of it is that you want to set the “From” and the “To” time to the same time. This way, Tasker will treat it like you want the Task to only trigger once at a set time (I made it 1 minute before midnight).
As for the Task, just copy what you did for Action #2 in the previous profile. There’s no new or different Action in this case, as all we’re doing is changing the value of this Global system property once every 24 hours.
Now that you’ve set up both of these profiles, you’re done!В Reboot your phone and you should now no longer see the “safe volume” warning when you plug in your headphones.
Download and Import to Tasker
We hope you find this tip useful. Let us know in the comments below if this works for you!
Как отключить предупреждение о вреде долгого прослушивания аудио (Android)
Наверное, многие, кто слушает музыку (и не только) с Android-устройства, сталкивались с таким предупреждением:
В этой статье мы рассмотрим, почему и когда возникает данное предупреждение, и как сделать так, чтобы оно больше не возникало.
Появляется оно только при прослушивании аудио через внешнее устройство (наушники/колонки). Для тех, кто не встречался с таким, небольшое пояснение: представьте, что вы слушаете музыку в наушниках, довольно громкую. Внезапно звук становится тише. Вы пытаетесь прибавить громкость, используя кнопки на корпусе, но не выходит. Достав устройство из кармана и сняв блокировку, вы и увидите такое предупреждение. Только после согласия с ним можно будет прибавить громкость обратно.
Да, предупреждение разумное, но появляется оно в непредсказуемый момент, иногда самый неподходящий: когда вы в общественном транспорте/за рулём/зимой на улице/когда у вас грязные руки и т.д. Доставать устройство, снимать блокировку, соглашаться с предупреждением, класть устройство обратно в этих случаях неудобно. А в случае, если подключены колонки, а не наушники, сообщение не совсем уместно.
Почему оно возникает
Данное предупреждение — не собственная инициатива авторов платформы. Всё дело в том, что существует WHO-ETU стандарт “безопасного прослушивания” (safe listening). В европейских и некоторых других странах его выполнение обязательно. В стандарте описывается, как долго можно прослушивать аудио в зависимости от громкости с минимальным риском снижения слуха. Например, для взрослого человека безопасная недельная “доза” звука — 1.6 Pa 2 h, что эквивалентно 20 часам прослушивания на громкости 83 dB.
Реализация
Такая реализация довольно простая и не учитывает, например, в течение какого времени пользователь прослушал эти 20 часов: возможно, за пару дней, а, может, слушал по 6-7 минут в течение полугода (в соответствии со стандартом это не является угрозой для слуха).
Логика safe listening сосредоточена в классе классе AudioService.java, в нём можно увидеть соответствующие поля:
Метод проверки превышения лимита выглядит так:
Как отключить предупреждение
Посмотрим, где изначально задаётся значение:
Чтобы отключить предупреждение, нужно установить значение audio.safemedia.bypass=true в файле system/build.properties. Но для этого нужны root-права. Если их нет, то нужно разбираться дальше и искать другой способ.
Как отключить предупреждение без root
Давайте посмотрим, что происходит при закрытии диалога с предупреждением по нажатию ОК, и попробуем это воспроизвести:
Вызов заканчивается исключением
java.lang.SecurityException: Only SystemUI can disable the safe media volume: Neither user 10307 nor current process has android.permission.STATUS_BAR_SERVICE.
Разрешение STATUS_BAR_SERVICE имеет protectionLevel=«signature|privileged», получить его не получится.
Прочитать значение Settings.Secure.UNSAFE_VOLUME_MUSIC_ACTIVE_MS можно так:
То же самое, используя adb:
Оно имеет protectionLevel=«signature|privileged|development», а значит его можно выдать приложению используя adb:
Само значение записать можно так:
То же самое можно сделать с помощью adb:
Сбрасывать лучше в 1, как это сделано в AudioManager, а не в 0. Так как 0 соответствует состоянию ACTIVE.
Есть подходящий метод в AudioManager.java
Остаётся один способ заставить AudioService прочитать новое значение — его перезапуск. Просто так перезапустить системный сервис нельзя. Нужно или перезагрузить устройство, или переключиться на другого пользователя, а затем вернуться обратно.
Теперь настало время проверить теорию.
Устанавливаем unsafe_volume_music_active_ms = 71 990 000 (останется 10 секунд, в течение которых можно прослушивать музыку на высокой громкости)
Перезапускаем устройство (можно вместо этого переключиться на другого пользователя, а потом вернуться):
Подключаем наушники, включаем музыку погромче. В течение минуты появляется диалог.
Теперь повторяем те же действия, но присваиваем unsafe_volume_music_active_ms = 1. Включаем музыку, ждём минуту. Диалог не появляется.
Итоги
Чтобы отключить предупреждение, можно сделать следующее:
При наличии root-прав
Установить значение audio.safemedia.bypass=true в файле system/build.properties
Я написала код простого приложения, которое делает эту работу, и напоминает о необходимости перезагрузить устройство/перелогиниться.
Почему в Kubernetes так сложно с хранилищами?
Когда пришли оркестраторы контейнеров, вроде Kubernetes, подход к разработке и деплою приложений изменился кардинально. Появились микрослужбы, а для разработчика логика приложения больше не связана с инфраструктурой: создавай себе приложения и предлагай новые функции.
Kubernetes абстрагируется от физических компьютеров, которыми управляет. Только скажите ему, сколько надо памяти и вычислительной мощности, — и все получите. Ифраструктура? Не, не слыхали.
Управляя образами Docker, Kubernetes и приложения делает переносимыми. Разработав контейнерные приложения с Kubernetes, их можно деплоить хоть куда: в открытое облако, локально или в гибридную среду, — и при этом не менять код.
Мы любим Kubernetes за масштабируемость, переносимость и управляемость, но вот состояния он не хранит. А ведь у нас почти все приложения stateful, то есть им нужно внешнее хранилище.
В Kubernetes очень динамичная архитектура. Контейнеры создаются и уничтожаются в зависимости от нагрузки и указаний разработчиков. Поды и контейнеры самовосстанавливаются и реплицируются. Они, по сути, эфемерны.
Внешнему хранилищу такая изменчивость не по зубам. Оно не подчиняется правилам динамического создания и уничтожения.
Чуть только надо развернуть stateful-приложение в другую инфраструктуру: в другое облако там, локально или в гибридную модель, — как у него возникают проблемы с переносимостью. Внешнее хранилище можно привязать к конкретному облаку.
Вот только в этих хранилищах для облачных приложений сам черт ногу сломит. И поди пойми хитровыдуманные значения и смыслы терминологии хранилищ в Kubernetes. А еще есть собственные хранилища Kubernetes, опенсорс-платформы, управляемые или платные сервисы…
Казалось бы, разверни базу данных в Kubernetes — надо только выбрать подходящее решение, упаковать его в контейнер для работы на локальном диске и развернуть в кластер как очередную рабочую нагрузку. Но у базы данных свои особенности, так что мысля — не айс.
Контейнеры — они же так слеплены, что своё состояние не сохраняют. Потому-то их так легко запускать и останавливать. А раз нечего сохранять и переносить, кластер не возится с операциями чтения и копирования.
С базой данных состояние хранить придется. Если база данных, развернутая на кластер в контейнере, никуда не переносится и не запускается слишком часто, в игру вступает физика хранения данных. В идеале контейнеры, которые используют данные, должны находиться в одном поде с базой данных.
В некоторых случаях базу данных, конечно, можно развернуть в контейнер. В тестовой среде или в задачах, где данных немного, базы данных комфортно живут в кластерах.
Для продакшена обычно нужно внешнее хранилище.
Kubernetes общается с хранилищем через интерфейсы плоскости управления. Они связывают Kubernetes с внешним хранилищем. Привязанные к Kubernetes внешние хранилища называются плагинами томов. С ними можно абстрагировать хранение и переносить хранилища.
Раньше плагины томов создавались, привязывались, компилировались и поставлялись с помощью кодовой базы Kubernetes. Это очень ограничивало разработчиков и требовало дополнительного обслуживания: хочешь добавить новые хранилища — изволь менять кодовую базу Kubernetes.
Теперь деплой плагины томов в кластер — не хочу. И в кодовой базе копаться не надо. Спасибо CSI и Flexvolume.
Собственное хранилище Kubernetes
Как Kubernetes решает вопросы хранения? Решений несколько: эфемерные варианты, постоянное хранение в постоянных томах, запросы Persistent Volume Claim, классы хранилищ или StatefulSets. Поди разберись, в общем.
Постоянные тома (Persistent Volumes, PV) — это единицы хранения, подготовленные админом. Они не зависят от подов и их скоротечной жизни.
Persistent Volume Claim (PVC) — это запросы на хранилище, то есть PV. С PVC можно привязать хранилище к ноде, и эта нода будет его использовать.
С хранилищем можно работать статически или динамически.
При статическом подходе админ заранее, до запросов, готовит PV, которые предположительно понадобятся подам, и эти PV вручную привязаны к конкретным подам с помощью явных PVC.
На практике специально определенные PV несовместимы с переносимой структурой Kubernetes — хранилище зависит от среды, вроде AWS EBS или постоянного диска GCE. Для привязки вручную нужно указать на конкретное хранилище в файле YAML.
Статический подход вообще противоречит философии Kubernetes: ЦП и память не выделяются заранее и не привязываются к подам или контейнерам. Они выдаются динамически.
Для динамической подготовки мы используем классы хранилища. Администратору кластера не нужно заранее создавать PV. Он создает несколько профилей хранилища, наподобие шаблонов. Когда разработчик делает запрос PVC, в момент запроса один из этих шаблонов создается и привязывается к поду.
Вот так, в самых общих чертах, Kubernetes работает с внешним хранилищем. Есть много других вариантов.
CSI — Container Storage Interface
Есть такая штука — Container Storage Interface. CSI создан рабочей группой CNCF по хранилищам, которая решила определить стандартный интерфейс хранения контейнеров, чтобы драйверы хранилища работали с любым оркестратором.
Спецификации CSI уже адаптированы для Kubernetes, и есть куча плагинов драйвера для деплоя в кластере Kubernetes. Надо получить доступ к хранилищу через драйвер тома, совместимый с CSI, — используйте тип тома csi в Kubernetes.
С CSI хранилище можно считать еще одной рабочей нагрузкой для контейнеризации и деплоя в кластер Kubernetes.
Если хотите подробностей, послушайте, как Цзе Юй рассказывает о CSI в нашем подкасте.
Опенсорс-проекты
Инструменты и проекты для облачных технологий шустро плодятся, и изрядная доля опенсорс-проектов — что логично — решают одну из главных проблем продакшена: работа с хранилищами в облачной архитектуре.
Самые популярные из них — Ceph и Rook.
Ceph — это динамически управляемый, распределенный кластер хранилища с горизонтальным масштабированием. Ceph дает логическую абстракцию для ресурсов хранилища. У него нет единой точки отказа, он сам собой управляет и работает на базе ПО. Ceph предоставляет интерфейсы для хранения блоков, объектов и файлов одновременно для одного кластера хранилища.
У Ceph очень сложная архитектура с RADOS, librados, RADOSGW, RDB, алгоритмом CRUSH и разными компонентами (мониторы, OSD, MDS). Не будем углубляться в архитектуру, достаточно понимать, что Ceph — это распределенный кластер хранилища, который упрощает масштабируемость, устраняет единую точку отказа без ущерба для производительности и предоставляет единое хранилище с доступом к объектам, блокам и файлам.
Естественно, Ceph адаптирован для облака. Деплоить кластер Ceph можно по-разному, например с помощью Ansible или в кластер Kubernetes через CSI и PVC.
Архитектура Ceph
Rook — это еще один интересный и популярный проект. Он объединяет Kubernetes с его вычислениями и Ceph с его хранилищами в один кластер.
Rook — это оркестратор облачных хранилищ, дополняющий Kubernetes. С ним пакуют Ceph в контейнеры и используют логику управления кластерами для надежной работы Ceph в Kubernetes. Rook автоматизирует деплой, начальную загрузку, настройку, масштабирование, перебалансировку, — в общем все, чем занимается админ кластера.
С Rook кластер Ceph можно деплоить из yaml, как Kubernetes. В этом файле админ в общих чертах описывает, что ему нужно в кластере. Rook запускает кластер и начинает активно мониторить. Это что-то вроде оператора или контролера — он следит, чтобы все требования из yaml выполнялись. Rook работает циклами синхронизации — видит состояние и принимает меры, если есть отклонения.
У него нет своего постоянного состояния и им не надо управлять. Вполне в духе Kubernetes.
Rook, объединяющий Ceph и Kubernetes, — это одно из самых популярных облачных решений для хранения: 4000 звезд на Github, 16,3 млн загрузок и больше сотни контрибьюторов.
Проект Rook уже приняли в CNCF, а недавно он попал в инкубатор.
Больше о Rook вам расскажет Бассам Табара в нашем эпизоде о хранилищах в Kubernetes.
Если в приложении есть проблема, нужно узнать требования и создать систему или взять нужные инструменты. Это относится и к хранилищу в облачной среде. И хотя проблема не из простых, инструментов и подходов у нас завались. Облачные технологии продолжают развиваться, и нас обязательно ждут новые решения.
