mediaserver Сканирование хранилища и индексация мультимедиа-файлов Тип файла: служба Комментарии Android обычно запускает его при загрузке и при изменении хранилища мультимедиа (например, отправка новых файлов с компьютера через mtp, извлечение и вставка SD-карты или USB-устройств хранения OTG, загрузка новых медиафайлов и т.д.) Причины, по которым возможна большая загрузка процессора: Явно - это когда разработчик приложения сделал это так, в этом случае только удаление этого приложения или обращение к разработчику может решить проблему. Когда приложение пассивно запускает медиа-сервер, например, когда приложение записывает ненужные или кэшируют медиа-файлы (изображения, звуки, видео) в каталогах, которые не исключаются медиа-сканером, что заставляет систему Android чаще выполнять повторное сканирование. Чтобы предотвратить это, вам нужно чтобы найти папку, в которую это приложение помещает ненужные файлы, и исключить ее из сканера мультимедиа, создав пустой файл с именем .nomedia внутри этой папки. На самом деле вы можете использовать этот метод, чтобы исключить любую папку из сканирования моим сканером мультимедиа. Дело в том, что проблема не в самом двоичном файле mediaserver, потому что этот двоичный файл может использоваться любым сторонним приложением, что затрудняет определение того, кто злоупотребляет его использованием. ------------------------- Медиа-сервер отвечает за индексацию изображений, видео и музыкальных файлов на устройстве. Затем такие программы, как медиа-галерея или музыкальный проигрыватель, запрашивают отфильтрованные списки определенных типов мультимедиа. Медиа-сервер сканирует и индексирует медиафайлы на внутреннем и съемном носителе. Иногда медиа-сканер использует много ресурсов ЦП в результате попытки сканирования одного или нескольких поврежденных файлов. Обычно это признак того, что ваша SD-карта начинает выходить из строя. Самое простое решение: если вы можете определить, где на карте памяти находятся ненужные файлы изображений, просто поместите файл .nomedia. Это позволяет избежать сканирования этой конкретной папки для индексации медиафайлов Примечание. она также не будет отображаться в галерее. Чтобы повысить безопасность устройства, Android 7.0 разбивает монолитный процесс mediaserver на несколько процессов с разрешениями и возможностями, ограниченными только теми, которые требуются каждому процессу. Эти изменения снижают уязвимости системы безопасности среды мультимедиа за счет: Эти изменения также повышают безопасность конечных пользователей, значительно снижая серьезность большинства уязвимостей безопасности, связанных с мультимедиа, обеспечивая безопасность устройств и данных конечных пользователей. OEM-производителям и поставщикам SoC необходимо обновить свои изменения HAL и инфраструктуры, чтобы сделать их совместимыми с новой архитектурой. В частности, поскольку код Android, предоставленный поставщиком, часто предполагает, что все выполняется в одном и том же процессе, поставщики должны обновить свой код, чтобы передать собственные дескрипторы ( native_handle ), которые имеют значение для разных процессов. Для эталонной реализации изменений, связанных с усилением защиты носителя, обратитесь к frameworks/av и frameworks/native. АРХИТЕКТУРНЫЕ ИЗМЕНЕНИЯ В предыдущих версиях Android использовался единый монолитный процесс mediaserver с большим количеством разрешений (доступ к камере, доступ к аудио, доступ к видеодрайверу, доступ к файлам, доступ к сети и т.д.). Android 7.0 разделяет процесс mediaserver на несколько новых процессов, каждый из которых требует гораздо меньшего набора разрешений: усиление защиты медиасервера [img] Рис. 1. Изменения в архитектуре для усиления защиты медиасервера Эта новая архитектура гарантирует, что даже если процесс будет скомпрометирован, вредоносный код не получит доступ ко всему набору разрешений, ранее имевшихся у медиасервера. Процессы ограничены политиками SElinux и seccomp. Примечание. Из-за зависимости от поставщика некоторые кодеки по-прежнему работают на mediaserver и, следовательно, предоставляют mediaserver больше разрешений, чем необходимо. В частности, Widevine Classic продолжает работать на mediaserver для Android 7.0. ИЗМЕНЕНИЯ МЕДИАСЕРВЕРА В Android 7.0 существует процесс mediaserver для управления воспроизведением и записью, например, передача и синхронизация буферов между компонентами и процессами. Процессы взаимодействуют через стандартный механизм Binder. В стандартном сеансе воспроизведения локального файла приложение передает дескриптор файла (FD) на mediaserver (обычно через Java API MediaPlayer), а mediaserver : В некоторых случаях кодек не используется (например, воспроизведение с разгрузкой, когда закодированные данные отправляются непосредственно на устройство вывода), или кодек может отображать декодированные данные напрямую, а не возвращать буфер декодированных данных (воспроизведение видео). ИЗМЕНЕНИЯ MEDIACODECSERVICE Служба кодеков — это место, где живут кодеры и декодеры. Из-за зависимости от поставщика не все кодеки еще находятся в процессе кодека. В Android 7.0: Незащищенные декодеры и программные кодировщики живут в процессе кодирования. Безопасные декодеры и аппаратные кодировщики находятся на mediaserver (без изменений). Приложение (или медиасервер) вызывает процесс кодека для создания кодека требуемого типа, а затем вызывает этот кодек для передачи закодированных данных и извлечения декодированных данных (для декодирования) или для передачи декодированных данных и извлечения закодированных данных (для кодирования). Передача данных в кодеки и из них уже использует общую память, поэтому этот процесс не меняется. ИЗМЕНЕНИЯ MEDIADRMSERVER Сервер DRM используется при воспроизведении контента, защищенного DRM, например фильмов в Google Play Movies. Он безопасно расшифровывает зашифрованные данные и, таким образом, имеет доступ к хранилищу сертификатов и ключей, а также к другим конфиденциальным компонентам. Из-за зависимости от поставщиков процесс DRM пока не используется во всех случаях. ИЗМЕНЕНИЯ АУДИОСЕРВЕРа В процессе AudioServer размещаются компоненты, связанные со звуком, такие как вход и выход звука, служба policymanager, определяющая маршрутизацию звука, и служба FM-радио. Дополнительные сведения об изменениях аудио и рекомендации по реализации см. в разделе Реализация аудио . ИЗМЕНЕНИЯ CAMERASERVER CameraServer управляет камерой и используется при записи видео для получения видеокадров с камеры, а затем передачи их на mediaserver для дальнейшей обработки. Подробные сведения об изменениях и рекомендации по внедрению изменений CameraServer см. в разделе Повышение безопасности Camera Framework . ИЗМЕНЕНИЯ EXTRACTORSERVICE Служба экстрактора содержит экстракторы , компоненты, которые анализируют различные форматы файлов, поддерживаемые медиа-фреймворком. Служба извлечения является наименее привилегированной из всех служб — она не может читать FD, поэтому вместо этого она обращается к интерфейсу Binder (предоставляемому ему mediaserver for каждого сеанса воспроизведения) для доступа к файлам. Приложение (или mediaserver ) вызывает процесс извлечения для получения IMediaExtractor , вызывает этот IMediaExtractor для получения IMediaSources для дорожки, содержащейся в файле, а затем вызывает IMediaSources для чтения данных из них. Для передачи данных между процессами приложение (или mediaserver ) включает данные в response-Parcel как часть транзакции Binder или использует разделяемую память: Использование разделяемой памяти требует дополнительного вызова Binder для освобождения разделяемой памяти, но это быстрее и потребляет меньше энергии для больших буферов. Использование in-Parcel требует дополнительного копирования, но работает быстрее и потребляет меньше энергии для буферов размером менее 64 КБ. Реализация Для поддержки переноса компонентов MediaDrm и MediaCrypto в новый процесс mediadrmserver поставщики должны изменить метод выделения безопасных буферов, чтобы разрешить совместное использование буферов между процессами. В предыдущих выпусках Android защищенные буферы выделялись на медиасервере с помощью OMX::allocateBuffer mediaserver и использовались во время расшифровки в том же процессе, как показано ниже: [img] Рис. 2. Android 6.0 и более раннее распределение буфера в медиасервере. В Android 7.0 процесс выделения буфера изменен на новый механизм, обеспечивающий гибкость при минимальном влиянии на существующие реализации. MediaDrm и MediaCrypto в новом процессе mediadrmserver буферы распределяются по-разному, и поставщики должны обновить безопасные дескрипторы буфера, чтобы их можно было транспортировать через связующее, когда MediaCodec вызывает операцию расшифровки на MediaCrypto. [img] Рисунок 3. Android 7.0 и более поздние версии распределения буфера в медиасервере. ИСПОЛЬЗОВАНИЕ РОДНЫХ ДЕСКРИПТОРОВ OMX::allocateBuffer allocateBuffer должен возвращать указатель на структуру native_handle , которая содержит файловые дескрипторы (FD) и дополнительные целочисленные данные. native_handle обладает всеми преимуществами использования FD, включая существующую поддержку связующего для сериализации/десериализации, обеспечивая при этом большую гибкость для поставщиков, которые в настоящее время не используют FD. Используйте native_handle_create() , чтобы выделить собственный дескриптор. Код фреймворка становится владельцем выделенной структуры native_handle и отвечает за высвобождение ресурсов как в процессе, в котором изначально выделена структура native_handle , так и в процессе, в котором она десериализуется. Фреймворк выпускает собственные дескрипторы с помощью native_handle_close() , за которым следует native_handle_delete() , и сериализует/десериализует native_handle с помощью Parcel::writeNativeHandle()/readNativeHandle() . Поставщики SoC, которые используют FD для представления защищенных буферов, могут заполнить FD в native_handle своим FD. Поставщики, которые не используют FD, могут представлять безопасные буферы, используя дополнительные поля в native_buffer . УСТАНОВКА МЕСТА РАСШИФРОВКИ Поставщики должны обновить метод дешифрования OEMCrypto, который работает с native_handle , чтобы выполнять любые специфичные для поставщика операции, необходимые для обеспечения возможности использования native_handle в новом пространстве процесса (изменения обычно включают обновления библиотек OEMCrypto). Поскольку allocateBuffer — это стандартная операция OMX, Android 7.0 включает новое расширение OMX ( OMX.google.android.index.allocateNativeHandle ) для запроса этой поддержки и вызов OMX_SetParameter, уведомляющий реализацию OMX о необходимости использования собственных дескрипторов. |
 |