Home » Misc » Android shared library что это за программа и нужна ли она

Android shared library что это за программа и нужна ли она


Что за программа «Shared Library» на Андроид и нужна ли она

Главная » Андроид

На чтение 2 мин Просмотров 917 Опубликовано

Существует множество приложений в телефоне и не каждый пользователь смартфона знает, для чего нужные некоторые из них. Например, Shared Library, которая является библиотекой и работает на старых версиях Андроида, чтобы сделать доступ новых возможным. Какие особенности у применения программы и как она работает?

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

Этапы процедуры, которые помогут воспользоваться фрагментом на старом телефоне:

  1. Для начала нужно добавить в код проверку системы и после показателя результата выполнить другой код. Если Андроид 11 или выше, то использовать фрагмент необходимо иначе Activity. Задача вполне выполнима, то не будет простой, ведь можно ошибиться и задача прервётся.

    При запуске программы на устаревшей версии в этот момент придётся отказаться о новшестве и пользоваться только тем, что имеется;

  2. Также можно забить на телефоне и позиционировать собственное приложение только для новой. Тогда потеряется некоторая часть потенциального пользователя;
  3. Специалисты рекомендуют воспользоваться библиотекой, ведь она содержит классы, а именно аналоги новых последних версий, что станут работать на мобильном устройстве.

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

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

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

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

Оцените автора

Как работает Android, часть 1 / Хабр

В этой серии статей я расскажу о внутреннем устройстве Android  —  о процессе загрузки, о содержимом файловой системы, о Binder и Android Runtime, о том, из чего состоят, как устанавливаются, запускаются, работают и взаимодействуют между собой приложения, об Android Framework, и о том, как в Android обеспечивается безопасность.

Статьи серии:


  • Как работает Android, часть 1
  • Как работает Android, часть 2
  • Как работает Android, часть 3
  • Как работает Android, часть 4
  • …


Немного фактов

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

Android  —  свободный и открытый проект. Большинство исходного кода (который можно найти на https://source.android.com) распространяется под свободной лицензией Apache 2.0.

Компания Android Inc. была основана в 2003 году и в 2005 году куплена Google. Публичная бета Android вышла в 2007 году, а первая стабильная версия  —  в 2008, с тех пор мажорные релизы выходят примерно раз в год. Последняя на момент написания стабильная версия Android  —  7. 1.2 Nougat.


Android is Linux

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

Среди исходной команды разработчиков Android был Robert Love, один из самых известных разработчиков ядра Linux, да и сейчас компания Google остаётся одним из самых активных контрибьюторов в ядро, поэтому неудивительно, что Android построен на основе Linux.

Как и в других Linux-системах, ядро Linux обеспечивает такие низкоуровневые вещи, как управление памятью, защиту данных, поддержку мультипроцессности и многопоточности. Но  —  за несколькими исключениями  —  вы не найдёте в Android других привычных компонентов GNU/Linux-систем: здесь нет ничего от проекта GNU, не используется X.Org, ни даже systemd. Все эти компоненты заменены аналогами, более приспособленными для использования в условиях ограниченной памяти, низкой скорости процессора и минимального потребления энергии  — таким образом, Android больше похож на встраиваемую (embedded) Linux-систему, чем на GNU/Linux.

Другая причина того, что в Android не используется софт от GNU  —  известная политика «no GPL in userspace»:


We are sometimes asked why Apache Software License 2.0 is the preferred license for Android. For userspace (that is, non-kernel) software, we do in fact prefer ASL 2.0 (and similar licenses like BSD, MIT, etc.) over other licenses such as LGPL.

Android is about freedom and choice. The purpose of Android is promote openness in the mobile world, and we don’t believe it’s possible to predict or dictate all the uses to which people will want to put our software. So, while we encourage everyone to make devices that are open and modifiable, we don’t believe it is our place to force them to do so. Using LGPL libraries would often force them to do just that.

Само ядро Linux в Android тоже немного модифицировано: было добавлено несколько небольших компонентов, в том числе ashmem (anonymous shared memory), Binder driver (часть большого и важного фреймворка Binder, о котором я расскажу ниже), wakelocks (управление спящим режимом) и low memory killer. Исходно они представляли собой патчи к ядру, но их код был довольно быстро добавлен назад в upstream-ядро. Тем не менее, вы не найдёте их в «обычном линуксе»: большинство других дистрибутивов отключают эти компоненты при сборке.

В качестве libc (стандартной библиотеки языка C) в Android используется не GNU C library (glibc), а собственная минималистичная реализация под названием bionic, оптимизированная для встраиваемых (embedded) систем  —  она значительно быстрее, меньше и менее требовательна к памяти, чем glibc, которая обросла множеством слоёв совместимости.

В Android есть оболочка командной строки (shell) и множество стандартных для Unix-подобных систем команд/программ. Во встраиваемых системах для этого обычно используется пакет Busybox, реализующий функциональность многих команд в одном исполняемом файле; в Android используется его аналог под названием Toybox. Как и в «обычных» дистрибутивах Linux (и в отличие от встраиваемых систем), основным способом взаимодействия с системой является графический интерфейс, а не командная строка. Тем не менее, «добраться» до командной строки очень просто  —  достаточно запустить приложение-эмулятор терминала. По умолчанию он обычно не установлен, но его легко, например, скачать из Play Store (Terminal Emulator for Android, Material Terminal, Termux). Во многих «продвинутых» дистрибутивах Android  —  таких, как LineageOS (бывший CyanogenMod)  —  эмулятор терминала предустановлен.

Второй вариант  —  подключиться к Android-устройству с компьютера через Android Debug Bridge (adb). Это очень похоже на подключение через SSH:

user@desktop-linux$ adb shell android$ uname Linux

Из других знакомых компонентов в Android используются библиотека FreeType (для отображения текста), графические API OpenGL ES, EGL и Vulkan, а также легковесная СУБД SQLite.

Кроме того, раньше для реализации WebView использовался браузерный движок WebKit, но начиная с версии 7.0 вместо этого используется установленное приложение Chrome (или другое; список приложений, которым разрешено выступать в качестве WebView provider, конфигурируется на этапе компиляции системы). Внутри себя Chrome тоже использует основанный на WebKit движок Blink, но в отличие от системной библиотеки, Chrome обновляется через Play Store  —  таким образом, все приложения, использующие WebView, автоматически получают последние улучшения и исправления уязвимостей.


It’s all about apps

Как легко заметить, использование Android принципиально отличается от использования «обычного Linux» —  вам не нужно открывать и закрывать приложения, вы просто переключаетесь между ними, как будто все приложения запущены всегда. Действительно, одна из уникальных особенностей Android — в том, что приложения не контролируют напрямую процесс, в котором они запущены. Давайте поговорим об этом подробнее.

Основная единица в Unix-подобных системах  —  процесс. И низкоуровневые системные сервисы, и отдельные команды в shell’е, и графические приложения  —  это процессы. В большинстве случаев процесс представляет собой чёрный ящик для остальной системы  —  другие компоненты системы не знают и не заботятся о его состоянии. Процесс начинает выполняться с вызова функции main() (на самом деле _start), и дальше реализует какую-то свою логику, взаимодействуя с остальной системой через системные вызовы и простейшее межпроцессное общение (IPC).

Поскольку Android тоже Unix-подобен, всё это верно и для него, но в то время как низкоуровневые части  —  на уровне Unix  —  оперируют понятием процесса, на более высоком уровне  —  уровне Android Framework  —  основной единицей является приложение. Приложение  —  не чёрный ящик: оно состоит из отдельных компонентов, хорошо известных остальной системе.

У приложений Android нет функции main(), нет одной точки входа. Вообще, Android максимально абстрагирует понятие приложение запущено как от пользователя, так и от разработчика. Конечно, процесс приложения нужно запускать и останавливать, но Android делает это автоматически (подробнее я расскажу об этом в следующих статьях). Разработчику предлагается реализовать несколько отдельных компонентов, каждый из которых обладает своим собственным жизненным циклом.


In Android, however, we explicitly decided we were not going to have a main() function, because we needed to give the platform more control over how an app runs. In particular, we wanted to build a system where the user never needed to think about starting and stopping apps, but rather the system took care of this for them… so the system had to have some more information about what is going on inside of each app, and be able to launch apps in various well-defined ways whenever it is needed even if it currently isn’t running.

Для реализации такой системы нужно, чтобы приложения имели возможность общатся друг с другом и с системными сервисами  —  другими словами, нужен очень продвинутый и быстрый механизм IPC.

Этот механизм  —  Binder.


Binder

Binder  —  это платформа для быстрого, удобного и объектно-ориентированного межпроцессного взаимодействия.

Разработка Binder началась в Be Inc. (для BeOS), затем он был портирован на Linux и открыт. Основной разработчик Binder, Dianne Hackborn, была и остаётся одним из основных разработчиков Android. За время разработки Android Binder был полностью переписан.

Binder работает не поверх System V IPC (которое даже не поддерживается в bionic), а использует свой небольшой модуль ядра, взаимодействие с которым из userspace происходит через системные вызовы (в основном ioctl) на «виртуальном устройстве» /dev/binder. Со стороны userspace низкоуровневая работа с Binder, в том числе взаимодействие с /dev/binder и marshalling/unmarshalling данных, реализована в библиотеке libbinder.

Низкоуровневые части Binder оперируют в терминах объектов, которые могут пересылаться между процессами. При этом используется подсчёт ссылок (reference-counting) для автоматического освобождения неиспользуемых общих ресурсов и уведомление о завершении удалённого процесса (link-to-death) для освобождения ресурсов внутри процесса.

Высокоуровневые части Binder работают в терминах интерфейсов, сервисов и прокси-объектов. Описание интерфейса, предоставляемого программой другим программам, записывается на специальном языке AIDL (Android Interface Definition Language), внешне очень похожем на объявление интерфейсов в Java. По этому описанию автоматически генерируется настоящий Java-интерфейс, который потом может использоваться и клиентами, и самим сервисом. Кроме того, по .aidl-файлу автоматически генерируются два специальных класса: Proxy (для использования со стороны клиента) и Stub (со стороны сервиса), реализующие этот интерфейс.

Для Java-кода в процессе-клиенте прокси-объект выглядит как обычный Java-объект, который реализует наш интерфейс, и этот код может просто вызывать его методы. При этом сгенерированная реализация прокси-объекта автоматически сериализует переданные аргументы, общается с процессом-сервисом через libbinder, десериализует переданный назад результат вызова и возвращает его из Java-метода.

Stub работает наоборот: он принимает входящие вызовы через libbinder, десериализует аргументы, вызывает абстрактную реализацию метода, сериализует возвращаемое значение и передаёт его процессу-клиенту. Соответственно, для реализации сервиса программисту достаточно реализовать абстрактные методы в унаследованном от Stub классе.

Такая реализация Binder на уровне Java позволяет большинству кода использовать прокси-объект, вообще не задумываясь о том, что его функциональность реализована в другом процессе. Для обеспечения полной прозрачности Binder поддерживает вложенные и рекурсивные межпроцессные вызовы. Более того, использование Binder со стороны клиента выглядит совершенно одинаково, независимо от того, расположена ли реализация используемого сервиса в том же или в отдельном процессе.

Для того, чтобы разные процессы могли «найти» сервисы друг друга, в Android есть специальный сервис ServiceManager, который хранит, регистрирует и выдаёт токены всех остальных сервисов.

Binder широко используется в Android для реализации системных сервисов (например, пакетного менеджера и буфера обмена), но детали этого скрыты от разработчика приложений высокоуровневыми классами в Android Framework, такими как Activity, Intent и Context. Приложения могут также использовать Binder для предоставления друг другу собственных сервисов  —  например, приложение Google Play Services вообще не имеет собственного графического интерфейса для пользователя, но предоставляет разработчикам других приложений возможность пользоваться сервисами Google Play.

Подробнее про Binder можно узнать по этим ссылкам:


  • Android Binder — Embedded Linux Wiki
  • Android Interface Definition Language, IBinder
  • Deep Dive into Android IPC/Binder Framework
  • Android Binder — Android Interprocess Communication
  • An Overview of Android Binder Framework
  • Binders & Window Tokens

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

Как общие библиотеки Android могут быть использованы для кражи данных — Naked Security

Android, Потеря данных, Google, Вредоносное ПО, Мобильная версия, Угрозы безопасности, SophosLabs, Уязвимость

от Билл Бреннер

Пользователи Android знакомы с рутиной: загружаете приложение, и появляется окно с запросом разрешения на общение с другими приложениями. Зная, что приложению нужен этот доступ для правильной работы, пользователь не задумываясь нажимает «ОК». Но что происходит, когда одно приложение злоупотребляет этим доступом, чтобы вмешиваться в другое?

Ответ, по мнению исследователей Оксфордского университета Винсента Тейлора, Аластера Бересфорда и Ивана Мартиновича, заключается в том, что само Android-устройство может быть скомпрометировано, а данные пользователя украдены. Они называют этот тип атаки внутрибиблиотечным сговором (ILC) и описывают его следующим образом в статье, опубликованной 11 августа:

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

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

Они также проанализировали 15 000 популярных приложений (с более чем миллионом загрузок каждое). Среди прочего, они обнаружили, что библиотека .com/facebook была самой популярной — она использовалась в 11,9% приложений, которые они рассмотрели. Также широкое распространение получили библиотеки для Google Analytics (9,8 %) и Flurry (6,3 %).

См. также: Отчет SophosLabs исследует 10 самых популярных вредоносных программ для Android разных рекламных серверов в день».

Кому выгодно?

Один из вопросов, на который пытались ответить исследователи, заключался в том, кому будет выгодно использовать библиотеки и приложения таким образом. Они считают, что ответ – рекламная и аналитическая индустрия. Они написали:

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

Даже если это улучшение небольшое, при переносе на экосистему приложений, состоящую из миллионов приложений и миллиардов устройств, ILC может принести (или уже приносит) непредвиденную прибыль для рекламных сетей.

Что делать?

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

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

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

Кроме того, продолжающееся присутствие вредоносных приложений для Android свидетельствует о необходимости использования антивирусного ПО для Android, например нашего бесплатного Sophos Mobile Security для Android.

Заблокировав установку вредоносных и нежелательных приложений, даже если они получены из Google Play, вы избавите себя от множества проблем.

По большому счету, средний пользователь Android не будет знать, какие методы использовало вредоносное ПО, чтобы добраться до порога его устройства, будь то внутрибиблиотечный сговор или что-то еще. Но они могут многое сделать, чтобы не допустить его проникновения, особенно когда речь идет о приложениях, которые они выбирают. Для этого вот еще несколько общих советов:

  • Придерживайтесь Google Play.  Это не идеально, но Google прилагает немало усилий, чтобы предотвратить появление вредоносного ПО или удалить его из Play Маркета, если оно появится. В отличие от этого, многие альтернативные рынки представляют собой немногим больше, чем бесплатные для всех, где создатели приложений могут загружать все, что хотят, и часто это делают.
  • Избегайте приложений с низкой репутацией.  Если о новом приложении еще ничего не известно, не устанавливайте его на рабочий телефон, потому что ваш ИТ-отдел не скажет вам спасибо, если что-то пойдет не так.
  • Исправление раннее, исправление часто.  Покупая новую модель телефона, проверьте отношение производителя к обновлениям и скорость выхода исправлений. Почему бы не включить «более быстрое и эффективное исправление» в свой список желательных функций наряду или впереди аппаратных достижений, таких как «улучшенная камера» и «экран с более высоким разрешением»?

Shared Libraries на Android

В этом документе описываются некоторые хитрости, хитрости и особенности того, как мы поставляем нативный код в Chrome на Android.

Содержание

  • Упаковка библиотеки
  • Упаковка Crashpad
  • Информация о отладке
  • Повествования и кадры
  • .

    Упаковка библиотеки

    • Android J & K (ChromePublic.apk):
      • libchrome.so хранится в сжатом виде и извлекается Android во время установки.
    • Android L & M (ChromeModernPublic.apk):
      • libchrome. so хранится внутри apk в несжатом виде (с именем Crazy.libchrome.so , чтобы избежать распаковки).
      • Загружается прямо из apk (без распаковки) с помощью mmap() 'ing.
    • Android N, O & P (MonochromePublic.apk):
      • libmonochrome.so хранится в несжатом виде (атрибут AndroidManifest.xml отключает извлечение) и загружается непосредственно из apk (функции теперь поддерживаются системным компоновщиком).
    • Android Q (TrichromeChrome.apk+TrichromeLibrary.apk):
      • libmonochrome.so хранится в apk общей библиотеки (TrichromeLibrary.apk), а не в apk Chrome, чтобы его можно было использовать совместно с TrichromeWebView . Он хранится в несжатом виде и загружается прямо из apk так же, как и на N-P. Trichrome использует ту же нативную библиотеку, что и Monochrome, поэтому он по-прежнему называется libmonochrome.so .

    Упаковка Crashpad

    • Crashpad — это встроенная библиотека, обеспечивающая аварийный дамп вне процесса. Когда запрашивается дамп (например, после сбоя), запускается процесс обработчика Crashpad для создания дампа.
    • Chrome и ChromeModern (Android от J до M):
      • libcrashpad_handler.so — это автономный исполняемый файл, содержащий весь код аварийного дампа. Он хранится в сжатом виде и автоматически извлекается системой, что позволяет выполнять его напрямую для создания аварийного дампа.
    • Monochrome (от N до P) и SystemWebView (от L до P):
      • Весь код Crashpad связан с основной собственной библиотекой пакета (например, libmonochrome.so). Когда запрашивается дамп, выполняется /system/bin/app_process, загружая CrashpadMain.java, который, в свою очередь, использует JNI для вызова собственного кода аварийного дампа. Этот подход требует создания переменных CLASSPATH и LD_LIBRARY_PATH, чтобы app_process мог найти CrashpadMain.java и любые нативные библиотеки (например, системные библиотеки, общие библиотеки, разделенные apk и т. д.), от которых зависит основная нативная библиотека пакета.
    • Monochrome, Trichrome и SystemWebView (Q+):
      • Весь код обработчика Crashpad связан с собственной библиотекой пакета. libcrashpad_handler_trampoline.so — это минимальный исполняемый файл, упакованный с основной нативной библиотекой, хранящийся в несжатом виде и оставленный без извлечения. Когда запрашивается дамп, выполняется /system/bin/linker для загрузки батута из APK, который, в свою очередь, dlopen() является основной нативной библиотекой для загрузки оставшегося кода обработчика Crashpad. Батут используется для дедупликации общего кода между Crashpad и основной нативной библиотекой, упакованной с ним. Этот подход не используется для P-, потому что компоновщик не поддерживает загрузку исполняемых файлов в своей командной строке до Q. Этот подход также требует создания подходящего LD_LIBRARY_PATH для поиска любых общих библиотек, от которых зависит Chrome/WebView.

    Информация об отладке

    Что это?

    • Разделы ELF, которые предоставляют информацию об отладке и символизации (например, возможность конвертировать адреса в номера функций и строк).

    Как мы это используем:

    • Отладочная информация ELF слишком велика для передачи на устройства, даже для локальной разработки.
    • Все наши APK содержат файлы .so с отладочной информацией, удаленной с помощью полосы 9.0103 .
    • Нераспакованные библиотеки хранятся по адресу out/Default/lib.unstripped .
      • Многие из наших скриптов жестко запрограммированы искать их там.

    Информация о раскрутке и указатели кадров

    Что это такое:

    • Информация о раскрутке — это данные, которые описывают, как раскручивать стек. Это:
      • Требуется поддержка исключений C++ (которые Chrome не использует).
      • Его также можно использовать для создания трассировки стека.
      • Обычно он хранится в разделе ELF с именем .eh_frame и .eh_frame_hdr , но arm32 хранит его в .ARM.exidx и . ARM.extab .
        • Вы можете увидеть эти разделы через: readelf -S libchrome.so
    • «Указатели кадров» — это соглашение о вызовах, которое гарантирует, что каждый вызов функции имеет адрес возврата, помещенный в стек.
      • Указатели кадров также можно использовать для создания трассировки стека (но без записей для встроенных функций).

    Как мы их используем:

    • Мы отключаем информацию о раскручивании (ищем exclude_unwind_tables ).
    • Для всех архитектур, кроме arm64, мы отключаем указатели кадров, чтобы уменьшить размер двоичного файла (ищите enable_frame_pointers ).
    • Сбои устраняются в автономном режиме с помощью minidump_stackwalk , который может создать трассировку стека с учетом моментального снимка памяти стека и неразрезанной библиотеки (см. //docs/testing/using_breakpad_with_content_shell.md)
    • Чтобы облегчить профилирование кучи, мы отправляем информацию о раскрутке в каналы arm32 canary и dev в виде отдельного файла: assets/unwind_cfi_32

    Разрешение собственных методов JNI

    • () — единственный экспортируемый символ (применяется скриптом компоновщика).
    • Собственные методы, зарегистрированные явно во время запуска сгенерированным кодом.
      • Требуется явное создание, так как среда выполнения Android использует системные dlsym() , который не знает о библиотеках, открытых Crazy-Linker.
  • Для MonochromePublic.apk и TrichromeChrome.apk:
    • JNI_OnLoad() и Java_* символы экспортируются скриптом компоновщика.
    • Ручная регистрация JNI не выполняется. Символы лениво разрешаются средой выполнения.

Упакованные релокации

  • Все варианты lib(mono)chrome.so включают «упакованные релокации» или «APS2 релокации» для сохранения двоичного размера.
    • Обратитесь к этому исходному файлу для объяснения формата.
  • Для обработки этих перемещений:
    • Pre-M Android: необходимо использовать наш собственный компоновщик.
    • M+ Android: системный компоновщик понимает формат.
  • Чтобы узнать, запакованы ли релокации, найдите LOOS+# при запуске: readelf -S libchrome.so
  • Android P+ поддерживает даже лучший формат, известный как RELR.
    • Мы, скорее всего, переключим не-монохромные apk на его использование, как только он будет реализован в лд .

RELRO Sharing

Что это?

  • RELRO относится к сегменту ELF GNU_RELRO . Он содержит данные, которые компоновщик помечает как доступные только для чтения после применения перемещений.
    • Чтобы проверить размер сегмента: readelf --segments libchrome.so
    • Для lib(mono)chrome.so на arm32 это около 2 Мб.
  • Если два процесса отображают этот сегмент в одно и то же виртуальное адресное пространство, то страницы памяти внутри сегмента, которые содержат только относительные перемещения (99% из них) будут побайтно идентичными.
    • Примечание. Для процессов fork() ed все страницы уже являются общими (через семантику копирования при записи fork() ), поэтому совместное использование RELRO к ним не применяется.
  • «Совместное использование RELRO» — это когда этот сегмент копируется в общую память и совместно используется несколькими процессами.

Как это работает?

  • Для Android < N (сумасшедший компоновщик):
    1. Браузерный процесс: libchrome.so загружается нормально.
    2. Процесс браузера: GNU_RELRO сегмент скопирован в ashmem (общая память).
    3. Процесс браузера (только младшие версии): страницы частной памяти RELRO заменены страницами ashmem (используя munmap() и mmap() ).
    4. Процесс браузера: загрузите адрес и разделяемую память fd, переданную средствам визуализации / процессу графического процессора.
    5. Процесс визуализации: сумасшедший компоновщик пытается выполнить загрузку по заданному адресу загрузки.
      • Загрузка может завершиться ошибкой из-за рандомизации адресного пространства, из-за чего по этому адресу уже загружено что-то еще.
    6. Процесс визуализации: Если загрузка по нужному адресу прошла успешно:
      • Компоновщик помещает GNU_RELRO в частную память и применяет перемещения как обычно.
      • После этого страницы памяти сравниваются с разделяемой памятью, и все идентичные страницы заменяются на ashmem (используя munmap() и mmap() ).
  • Более подробное описание см. в комментариях в Linker.java.
  • Для Android N-P:
    • ОС поддерживает на диске файл RELRO с содержимым сегмента GNU_RELRO.
    • Все приложения Android, содержащие WebView, загружают libmonochrome.so по одному и тому же виртуальному адресу и применяют общий доступ RELRO к файлу RELRO, отображаемому в памяти.
    • Chrome использует MonochromeLibraryPreloader для вызова того же кода загрузки библиотеки WebView.
      • Когда Monochrome является поставщиком WebView, libmonochrome.so загружается с применением системных кэшированных RELRO.
    • После этого вызывается System.loadLibrary() .
      • Если Monochrome является поставщиком WebView, это вызывает только JNI_OnLoad, так как библиотека уже загружена. В противном случае это загружает библиотеку, и совместное использование RELRO не происходит.
  • Для Android O-P (где есть зигота WebView):
    • Для процессов без рендеринга применяется описанная выше логика Android N+.
    • Для процессов рендеринга ОС запускает все процессы монохромного рендеринга на fork() Создание зиготы WebView вместо обычной зиготы приложения.
      • В этом случае совместное использование RELRO было бы избыточным, поскольку память всего процесса совместно используется с зиготой с семантикой копирования при записи.
  • Для Android Q+ (Trichrome):
    • TrichromeChrome больше не передает данные RELRO в WebView, и совместное использование RELRO не происходит. TrichromeWebView работает так же, как и на Android N-P.
    • Процессы рендеринга TrichromeChrome больше не fork() ed из зиготы WebView. TrichromeWebView работает так же, как и на Android N-P.

Предварительная выборка библиотеки

  • Во время запуска мы fork() процесс, который считывает байт из каждой страницы памяти библиотеки (или только упорядоченный диапазон библиотеки).
    • См. //base/android/library_loader/.

Исторические лакомые кусочки

Только новые статьи

Введите свой e-mail

Видео-курс

Blender для новичков

Ваше имя:Ваш E-Mail:

Содержание, карта.