Apex com android runtime

Apex com android runtime

• В Клубе действуют Правила Форума.
• В Клубе действуют Правила раздела Трепалка.
• И давайте без политики в Клубе!

Сообщение отредактировал OutS — 25.08.21, 11:41

Ну что ж, раз появилась смежная тема ( спасибо Юре), можно обсудить тут один очень актуальный для новейших устройств вопрос.
Apex File Format, в который засунули наш и без того капризный core-oj.jar 😀

Добавлено 21.02.2021, 22:22:

У кого такая беда и умеет (или имеет желание) собирать образы, пишите. Попробуем пересобрать образ apex_payload.img в составе apex’а и собрать новый образ system.new.dat.br.
Добьем таки повисший вопрос — загрузится ли пересобранная система

Русm, Блин, Руст, у меня такого ещё нет, у ещё руки пока никак не дойдут на 11 прошиться даже 😀 Могу предположить только. А что если пересобрать этот образ с патченным кором и прошить вместе со всей системой? По идее так должно быть норм.
ПыСы. Пока писал и ты уже добавил :rofl:

Сообщение отредактировал OutS — 21.02.21, 22:26

Есть несколько соображений по этому поводу и не только у меня, но нет в данный момент устройства с прошивкой MIUI. Сам сейчас на AOSP и устройство постоянно нужно для связи. Нет возможности ставить MIUI и переодически убивать её кривым апексом

Добавлено 21.02.2021, 22:28:

так про то и речь. В теме Модификаций каждый раз кто-то заходит с вопросом по core-oj.jar в apex, не читая начинает открывать всем собравшимся Америку, а после указывния товарищу о данном обсуждении и просьбе собрать что-то, сливается :rofl:

Собственно от того, что я поставлю на свой Mi9 MIUI, толку мало. MIUI 12.5 на Android OS 11 у нас не внесла этих изменений и core-oj.jar лежит в открытом виде.

Сообщение отредактировал Русm — 21.02.21, 22:32

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

Добавлено 21.02.2021, 22:36:

Хм, щас попробую удалить их и заново пропатчить core-oj.jar. Отпишусь

Сообщение отредактировал Rodger_Rulez — 21.02.21, 22:41

Rodger_Rulez,
Да, мне скидывали такие скриншоты. Видимо он ещё и одекс по типу OS 10, где dex лежит как и самом целевом файле apk/jar и ещё имеет vdex файлы, которые можно просто сносить целиком и не заморачиваться с деодексом

Добавлено 21.02.2021, 22:43:

Rodger_Rulez,
Если есть время, поставь ещё Xposed и проверь этот модуль Каталог модулей для Xposed framework (Пост Русm #99128810) на OS 11

Добавлено 21.02.2021, 22:45:

SafetyNet отвалится. Скорее всего достаточно будет снести xposed и почистить данные GMS и GPay, но может придётся и прошивку переустанавливать. Если SafetyNet актуален для тебя

Rodger_Rulez,
Ставишь сам riru основной, который бывший riru core, актуальный riru EdXposed, который Yahfa, EdXposed Manager и этот модуль.
Первые две позиции берёшь в репо через сам Magisk, на манагер сейчас кину ссылку, на Core Patch дал ссылку ранее

Сообщение отредактировал Русm — 21.02.21, 22:53

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

Добавлено 21.02.2021, 23:03:

значит подождём того, кому GPay не нужен 😀

Да и плясать там особо нечего на OS 11. Делов на пять минут. Главное самому не мудрить с Magisk и лишними модулями, которых полно в инструкциях по овер 100 шагов настройки SafetyNet 😀

Сообщение отредактировал Русm — 21.02.21, 23:10

Ну во! Первая польза от Клуба :good: Так держать, товарищи!

Сообщение отредактировал OutS — 21.02.21, 23:38

Rodger_Rulez,
Собственно с таким core и не должно быть проблем. Если все сделано правильно

Вопрос с core в apex file format остаётся актуальным

Сообщение отредактировал Русm — 21.02.21, 23:40

OutS, вот бы ещё твой патчер под все изменения подогнать. Хотя, может он и норм отработает теперь. Ведь названия методов не поменялись если старым разбирать)

А не, там поменялось что-то все же, когда патчили, то один метод не находило. Приложения не понижались, а если руками по Ману делать, то там с понижением метод поменялся. Во, вспомнил пока писал)

Добавлено 21.02.2021, 23:43:

Русm, это да, как оказалось, все старыми тулзами разбирается и собирается. Не всегда «новое — лучше» 😀

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

Сообщение отредактировал Rodger_Rulez — 21.02.21, 23:53

Привет всем.
Немного мыслей по поводу core-oj.jar
Самый капризный файл для патчей. И на 11-ом Андроиде не стал исключением. Но как оказалось, его можно побороть.
Давно уже известно, что его разбирать надо не удаляя отладочную информацию.
BAT 3.7.9, смали 2.4.0. Подопытный не разбирается, в логе куча разных ошибок. Но. сменив смали на 2.3.4 он превосходно разбирается. Равно как и обратный процесс происходит без запинки.
Патчил руками. И система завелась.
Впрочем, отсылать к подобной информации уже есть.
Как сказал уже Outs, после замен jar’ов загрузка долгая. Я сам по началу думал, что бутлупу словил.

Сообщение отредактировал MraG — 21.02.21, 23:55

Источник

APEX in Android Q: What Could Be The Biggest Thing Since Project Treble

Implementing APEX is probably the biggest headache Google has faced since the introduction of Project Treble. What is APEX, and how will its introduction change Android?

The idea behind APEX by itself is rather common in everyday GNU/Linux distributions: package updates targeting specific sections of the Linux library set. But that’s something Google never tried to do given that Android has used a RO (read-only) partition where all the system libraries and frameworks are stored versus the usual RW (read-write) partitions used in most Linux distributions, rendering the standard upgrade process unsuitable.

Libraries are precompiled code that can be used in other programs. Commonly used methods can be made into libraries for Android apps to call, reducing the size of APKs as the same code won’t need to be re-implemented across multiple apps. You can find many pre-installed system libraries in the /system/lib and /system/lib64 directories. Android system libraries usually aren’t updated individually—rather, they get updated as part of Android platforms upgrades via an OTA update. On the other hand, libraries in Linux distros may be updated individually. With the introduction of APEX, system libraries in Android can be updated individually like Android apps. The main benefit of this is that app developers will be able to take advantage of updated libraries without waiting for an OEM to roll out a full system upgrade. Let’s dive into more technical detail about how APEX works.

How will APEX change the way libraries are updated?

APEX is an ecosystem that forced (or rather, is forcing) Google to reconsider the way Android loads all the libraries and files from a non-standard partition different from /system.

First of all, we have to specify the difference between a shared library and a static library. A shared library is a library (usually a file named libkind.so) that doesn’t include all the code needed to run in itself but is “linked” to other libraries actually providing the code, while a static library is, as you can guess, a library that doesn’t depend on any other libraries and has everything included statically within the file.

Android has historically configured the library path (known as LD_LIBRARY_PATH in the Linux world) with a single file called ld.config.txt [0] to configure the allowed search paths for the shared libraries needed by either binary or another library. These paths are hardcoded in the configuration and aren’t expandable. This layout, including the read-only system partition, leads to un-updateable libraries unless the user installs an OTA Android update. Google fixed this issue allowing to extend the search path by letting the single APEX packages provide their own ld.config.txt that included the extra (and updated) libraries paths contained in them.

While this move fixed one of the main issues, there were still a few serious issues to overcome. First of all: ABI (application binary interface) stability. Libraries should always export a stable set of interfaces to allow other apps and libraries to continue to work with the same protocol even with the upgraded library. Google is actively working on that by trying to create a stable C interface between APEXed libraries.

But an APEX isn’t limited to libraries and binaries alone. In fact, it can contain configuration files, timezone updates, and some Java frameworks (conscrypt at the time of writing).

Here are a few examples of the current APEX packages provided by AOSP:

• com.android.runtime: ART and bionic runtime (binaries and libraries)
• com.android.tzdata: TimeZone and ICU data (libraries and configuration data)
• com.android.resolv: Library used by Android to resolve network related requests (libraries)
• com.android.conscrypt: A Java Security Provider (Java framework)

How is an APEX package installed and structured?

An APEX package is a simple zip archive (like an APK) that can be installed by our handy ADB (at this point in development) and, later on, by the user themselves via a package manager (like Google Play or manually through the Android package installer).

The ZIP layout is as follows:

Let’s dive into that.

The apex_manifest.json specifies the package name and version.

The apex_payload.img is a micro-filesystem image (formatted as EXT4).

The other files are part of the verification process used to install the package. Let’s have a look.

The presence of AndroidManifest.xml, even if it’s used mainly in applications, helps us understand that most of the implementation used for a standard APK installation is reused even for these packages. In fact, only the extension is being checked to differentiate between them.

The META-INF/ directory has the package certificate and uses the same mechanism as normal APKs. So these packages are verified by a private/public key pair at runtime before the user is allowed to install an update. But that wasn’t enough for Google, so they added 2 more layers of security. They’re using dm-verity to check the integrity of the image and AVB (Android Verified Boot) verifications to make sure the image comes from a trusted source. In the worst case scenario, the APEX package will be rejected.

If all the verification steps are successful, the image will be marked as valid and will replace the system variant at the next reboot.

How is an image installed at boot?

Let’s start by taking a look at the APEXes currently installed on my device (an emulator)

As you can see, the pre-installed packages are stored in /system/apex/ and all of them are currently on version number 1. But what happens when an APEX is activated? We’ll again be using com.android.tzdata as an example.

Let’s reboot the device and analyze the logcat.

The first 2 lines provide enough information to understand the package’s origin and where it’s going to be installed: /apex/, a new directory introduced in Android Q that will be used to store the activated packages.

After the package has been successfully verified with AVB and the public key matches, the APEX is mounted using a loop device to /dev/block/loop0, making the EXT4 file system accessible to the system. A loop device is a pseudo-device that makes a file accessible as a block device, making the contents of that file accessible as a mount point.

At this point, the APEX is still not used because of the @1 suffix (that indicates the package version). To finally let the system know that our package has been successfully activated, it’ll be bind-mounted to /apex/com.android.tzdata where Android actively expects tzdata to live. A bind mount overlays an existing directory or file under a different point. [1]

The APEX implementation is entirely contained in a single repository under AOSP. [2] The apexd (APEX daemon) directory has the code running on Android. The apexer directory has the code used by the build system to create the APEX packages.

What’s the purpose?

At this point, all I can do is speculate. My best guess is that Google is trying to create a core set of APEX packages that can be updated by Google to possibly create a unified base core of Android shared between vendors, making “system” only updates possible, but using single package updates.

Are all devices going to support APEX?

No. For example, apexd requires /data/apex to be available right after boot to update all the Android modules. With FDE (Full-disk Encryption), /data/apex is encrypted until the device is unlocked by the user, rendering APEX basically useless as only the system APEX variants will be loaded at boot. Other than that, all devices should be supporting APEX, but they need a few kernel patches (many of which are fixes found by Google while playing with loop devices). [3] [4]

Источник