Инструкции по сборке Android из исходников

andrwgldmn · 17.12.2018

Adb & fastboot для Linux

Код:

sudo apt-get install android-tools-adb
sudo apt-get install android-tools-fastboot

чтобы видеть ссылку, вы должны быть зарегистрированы

Выбираем свою версию и меняем цифру в команде установки
Android 4.4 - Java 6
Android 5.x-6.x - Java 7
Android 7.x - Java 8

Код:

sudo add-apt-repository ppa:openjdk-r/ppa
sudo apt-get update
sudo apt-get install openjdk-7-jdk

Выбираем на

чтобы видеть ссылку, вы должны быть зарегистрированы

нужную версию Toolchain, например

чтобы видеть ссылку, вы должны быть зарегистрированы

и загружаем в нужную вам директорию:

Код:

cd ~/Android/utility
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6
cd ~/

Всё, наш Toolchain установился в ~/Android/utility/arm-eabi-4.6

Код:

sudo apt-get install git-core gnupg flex bison gperf build-essential zip curl zlib1g-dev libc6-dev lib32ncurses5-dev ia32-libs x11proto-core-dev libx11-dev lib32readline5-dev lib32z-dev libgl1-mesa-dev g++-multilib mingw32 tofrodos python-markdown libxml2-utils xsltproc

Если вы на Ubuntu 10.10 выполните:

sudo ln -s /usr/lib32/mesa/libGL.so.1 /usr/lib32/mesa/libGL.so

Если вы на Ubuntu 11.10 установите:

sudo apt-get install libx11-dev:i386

Код:

sudo apt-get install git-core gnupg flex bison gperf build-essential zip curl libc6-dev libncurses5-dev:i386 x11proto-core-dev libx11-dev:i386 libreadline6-dev:i386 libgl1-mesa-glx:i386 libgl1-mesa-dev g++-multilib mingw32 tofrodos python-markdown libxml2-utils xsltproc zlib1g-dev:i386

После этого выполните:

sudo ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 /usr/lib/i386-linux-gnu/libGL.so

Код:

sudo apt-get install git-core gnupg flex bison gperf build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip imagemagick

чтобы видеть ссылку, вы должны быть зарегистрированы

>

чтобы видеть ссылку, вы должны быть зарегистрированы

>

чтобы видеть ссылку, вы должны быть зарегистрированы

В процессе наполнения

Lord_X · 02.01.2019

При выборе выдает такое сообщение

Снимок экрана от 2019-01-02 10-17-05.png

Блин. Тут неувязка получается. j5lte это j500. А нужно j5xnlte - это j510
нашел нужный. ) перезаписал в папку device/samsung/j5xnlte
Только в списке не появилось j5xnlte
Наверное подгрузку конфигов перезапустить...

Перезапустил. Устройства изменились на нужные. Но все равно ошибка.

andrwgldmn · 02.01.2019

L Lord, нужно переделать дерево под cypher, на гитхабе этого rom можешь посмотреть деревья и немножко подумать

andrwgldmn · 03.01.2019

Немного о языке Android Init

Что это:
Язык Init Android состоит из пяти основных классов операторов: Действия, Команды, Службы, Параметры и Импорт.
Строки, начинающиеся с # являются комментариями.

Свойства системы могут быть расширены с использованием синтаксиса ${property.name}. Это также работает в тех случаях, когда требуется конкатенация, например,
import /init.recovery.${ro.hardware}.rc
Действия и Службы объявляют новый раздел. Все команды или опции относятся к разделу, который был недавно объявлен. Команды или параметры перед первым разделом игнорируются.
Службы имеют уникальные имена. Если вторая служба определена с тем же именем, что и существующая, она игнорируется и мы получим сообщение об ошибке.

.rc файлы инициализации:
Язык init используется в текстовых файлах с расширением .rc. Как правило, их несколько в разных местах системы, как будет описано ниже.
/init.rc является основным файлом .rc и подгружается бинарником init в начале его выполнения. Он отвечает за первоначальный запуск системы.
Устройства, которые монтируют /system, /vendor на первичном этапе инициализации, загружают все файлы, содержащиеся в каталогах /{system, vendor, odm}/etc/ init/, сразу после загрузки /init.rc.
Устаревшие устройства без первичного этапа инициализации выполняют следующие действия:

/init.rc импортирует /init.${ro.hardware}.rc , который является основным файлом, предоставленным производителем.
Во время команды mount_all исполняемый файл init загружает все файлы, содержащиеся в каталогах /{system, vendor, odm}/etc/init/. Эти каталоги предназначены для всех действий и служб, используемых после монтирования файловой системы.

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

Файлы в этих папках:

/system/etc/init/ предназначен для основных системных элементов, таких как SurfaceFlinger, MediaService и logcatd.
/vendor/etc/init/ предназначен для элементов от производителя чипа, таких как Действия или демоны, необходимые для основных функций SoC.
/odm/etc/init/ предназначен для элементов от производителя устройства, таких как Действия или демоны, необходимые, например, для датчика движения или других периферийных функций.

Все сервисы, бинарники которых находятся в разделах system, vendor или odm, должны иметь свои записи сервисов, помещенные в соответствующий файл init.rc, расположенный в каталоге /etc/init/ раздела, в котором они находятся.

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

В команде mount_all есть две опции «early» и «late», которые можно установить после необязательных путей. Если задано «--early», бинарник init пропустит записи о монтировании с флагом «latemount» и вызовет состояние шифрования fs. При установленном «--late» бинарник init будет монтировать только записи с флагом «latemount», но пропустит импорт файлов rc. По умолчанию опция не установлена, и mount_all обработает все записи в fstab.

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

Каждое действие в очереди последовательно удаляется из очереди после его выполнения, и каждая команда в этом действии выполняется последовательно. Init обрабатывает другие действия (создание/уничтожение устройства, настройка свойств, перезапуск процесса) «между» выполнением команд в действиях.

Действия имеют форму:

Код:

on <trigger> [&& <trigger>]*
   <command>
   <command>
   <command>

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

Например, если файл содержит:

Код:

on boot
   setprop a 1
   setprop b 2

on boot && property:true=true
   setprop c 1
   setprop d 2

on boot
   setprop e 1
   setprop f 2

Затем, когда запускается триггер boot и предполагается, что свойство true равно true, порядок выполняемых команд будет следующим:

Код:

setprop a 1
setprop b 2
setprop c 1
setprop d 2
setprop e 1
setprop f 2

Службы - это программы, которые запускает init .
Они принимают форму:

Код:

service <name> <pathname> [ <argument> ]*
   <option>
   <option>

Параметры- это модификаторы служб. Они влияют на то, как и когда init запускает службу.

Установка параметров при выполнении сервиса:

Код:

capabilities <capability> [ <capability>\* ]

«Параметр» должен быть параметром Linux без префикса «CAP_», например «NET_ADMIN» или «SETPCAP»

Указание имена классов для сервиса:

Код:

class <name> [ <name>\* ]

Все службы в названном классе могут быть запущены или остановлены вместе. Служба находится в классе «default», если она не указана с помощью опции класса. Дополнительные имена классов помимо (обязательного) первого используются для группировки служб. Класс animation должен включать в себя все службы, необходимые как для анимации загрузки, так и для анимации выключения. Поскольку эти службы могут быть запущены очень рано во время загрузки и могут работать до последнего этапа выключения, доступ к разделу /data не гарантируется. Эти сервисы могут проверять файлы в /data, но они не должны держать файлы открытыми и должны работать, когда /data недоступен.

Если службе нужна консоль:

Код:

console [<console>]

Необязательный второй параметр выбирает конкретную консоль вместо стандартной. Значение по умолчанию «/dev/console» можно изменить, установив параметр ядра «androidboot.console». Во всех случаях ведущий «/dev/» должен быть опущен, поэтому «/dev/tty0» будет указано как «console tty0».

Это служба, критическая для устройства:

Код:

critical

Если она падает более четырех раз за четыре минуты, устройство перезагрузится в bootloader.

Эта служба не будет автоматически запускаться со своим классом:

Код:

disabled

Она должна быть запущена по имени или по имени интерфейса.

Открыть доступ к файлу и передать его fd запущенному процессу:

Код:

file <path> <type>

Тип должен быть «r», «w» или «rw».

Изменение имени группы перед выполнением этой службы:

Код:

group <groupname> [ <groupname>\* ]

Дополнительные имена групп помимо (обязательного) первого используются для установки дополнительных групп процесса (через setgroups ()).

Ввод нового PID или монтирование именного пространства при разветвлении службы:

Код:

namespace <pid|mnt>

Не перезапускать службу, когда она падает:

Код:

oneshot

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

Код:

onrestart

Изменение «seclabel» перед выполнением этой службы:

Код:

seclabel <seclabel>

В основном это нужно для использования службами, запускаемыми из rootfs, например adbd.
«seclabel» - это контекст безопасности SELinux для сокета. По умолчанию используется контекст безопасности службы, заданный seclabel или вычисленный на основе контекста безопасности исполняемого файла службы.

Создание сокета домена unix с именем /dev/socket/name и передача его fd запущенному процессу:

Код:

socket <name> <type> <perm> [ <user> [ <group> [ <seclabel> ] ] ]

<type>должен быть «dgram», «stream» или «seqpacket». По умолчанию для пользователя и группы установлено значение 0.

Триггеры - это строки, которые могут использоваться для соответствия определенным видам событий и вызывать действие.

Триггеры подразделяются на:

Триггеры событий
Триггеры свойств

Триггеры событий - это строки, запускаемые командой «trigger» или функцией QueueEventTrigger() в бинарнике init. Они принимают форму простой строки, такой как «boot» или «late-init».
Триггеры свойств - это строки, запускаемые, когда именованное свойство меняет значение на указанное новое значение или когда именованное свойство меняет значение на любое новое значение. Они принимают форму ‘property: =’ и ‘property: = *’ соответственно. Триггеры свойств дополнительно оцениваются и запускаются соответствующим образом на начальной стадии загрузки init.

Действие может иметь несколько триггеров свойств, но может иметь только один триггер события.
Например:

Код:

on boot && property:a=b

определяет действие, которое выполняется только тогда, когда срабатывает триггер события «boot» и свойство a равно b.

Код:

on property:a=b && property:c=d

определяет действие, которое выполняется три раза:

Во время начальной загрузки, если свойство a = b и свойство c = d.
Каждый раз, когда свойство a переходит к значению b, а свойство c уже равно d.
Каждый раз, когда свойство c переходит к значению d, а свойство a уже равно b.

Изменение прав доступа к файлу:

Код:

chmod <octal-mode> <path>

Смена владельца файла и группы:

Код:

chown <владелец> <группа> <путь>

Запуск всех служб указанного класса, если они еще не запущены:

Код:

class_start <serviceclass>

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

Код:

class_stop <serviceclass>

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

Код:

class_reset <serviceclass>

Перезапускает все службы указанного класса:

Код:

class_restart <serviceclass>

Копирует файл:

Код:

copy <src> <dst>

Установка доменного имени:

Код:

domainname <name>

Превращение отключенной службы во включенную:

Код:

enable <servicename>

Например:
[/CODE]on property:ro.boot.мойhardware=1
Запустить моя_служба_для_моего_hardware

Код:

Разветвление и выполнение команды с заданными аргументами. Команда начинается после «-», так что можно указать необязательный контекст безопасности, пользователя и дополнительные группы. Никакие другие команды не будут выполняться, пока эта не завершится.
[CODE]exec [ <seclabel> [ <user> [ <group>\* ] ] ] -- <command> [ <argument>\* ]

Разветвление и выполнение команды с заданными аргументами. Это обрабатывается аналогично команде выше. Разница в том, что init не останавливает выполнение команд до тех пор, пока процесс не завершится для exec_background.

Код:

exec_background [ <seclabel> [ <user> [ <group>\* ] ] ] -- <command> [ <argument>\* ]

Запуск службы и остановка обработки дополнительных команд инициализации, пока она не вернется:

Код:

exec_start <сервис>

Установка имени переменной среды равным значению в глобальной среде (которое будет унаследовано всеми процессами, запущенными после выполнения этой команды):

Код:

export <name> <value>

Установка имени хоста:

Код:

hostname <name>

Подключение сетевого интерфейса к сети:

Код:

ifup <interface>

Установка модуля по пути с указанными опциями:

Код:

insmod [-f] <путь> [<параметры>]

-f: принудительно установить модуль, даже если версия работающего ядра и версия ядра, для которого был скомпилирован модуль, не совпадают.

Загрузка свойств из /system, /vendor и т. д:

Код:

load_all_props

Это включено в init.rc. по умолчанию.

Загружает постоянные свойства, когда /data были расшифрованы.

Код:

load_persist_props

Это включено в init.rc. по умолчанию.

Установка уровня логирования:

Код:

loglevel <level>

Максимум 8 уровень.

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

Код:

mkdir <path> [mode] [owner] [group]

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

Вызов fs_mgr_mount_all для указанного fsta_mgr-формата fstab и импорт файлов .rc по указанным путям (например, на только что смонтированных разделах) с необязательными параметрами «ранний» и «поздний»:

Код:

mount_all <fstab> [ <path> ]\* [--<option>]

Монтирование указанного устройства в каталоге dir _flag_s включает в себя «ro», «rw», «remount», «noatime», ... опции включают «barrier=1», «noauto_da_alloc», «noatime », ... в виде строки, разделенной запятыми, например: barrier=1 , noauto_da_alloc:

Код:

mount <type> <device> <dir> [ <flag>\* ] [<options>]

Остановка и перезапуск работающей службы:

Код:

restart <service>

Восстановление файла с именем пути в контексте безопасности, указанному в конфигурации file_contexts:

Код:

restorecon <path> [ <path>\* ]

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

Рекурсивное восстановление дерева каталогов с именем путей в контексте безопасности, указанные в конфигурации file_contexts:

Код:

restorecon_recursive <path> [ <path>\* ]

Удаление файлов по пути:

Код:

rm <path>

Удаление папки по пути:

Код:

rmdir <path>

Установка системного имени как значение чего-либо:

Код:

setprop <name> <value>

Установка ограничения для ресурса:

Код:

setrlimit <resource> <cur> <max>

Старт службы:

Код:

start <service>

Остановка службы:

Код:

остановить <сервис>

Вызов fs_mgr_swapon_all для данного файла fstab:

Код:

swapon_all <fstab>

Создание симлинка на путь со значением target:

Код:

symlink <target> <path>

Триггер запуска события:

Код:

trigger <event>

Размонтирование файловой системы, смонтированной по этому пути:

Код:

umount <path>

Открыть файл по пути и записать в него строку с помощью write:

Код:

write <path> <content>

Если файл не существует, он будет создан. Если он существует, он будет изменён.

Разбор файла конфигурации init, расширение текущей конфигурации:

Код:

import <path>

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

Ключевое слово import - это не команда, а отдельный раздел. Это означает, что он не происходит как часть действия, а, скорее, обрабатывается во время анализа файла и следует приведенной ниже логике.
Есть только три случая, когда бинарник init импортирует .rc файлы:

Когда он импортирует /init.rc или скрипт, указанный в свойстве ro.boot.init_rc во время начальной загрузки.
Когда он импортирует /{system, vendor, odm}/etc/init/ для устройств первого этапа монтирования сразу после импорта /init.rc.
Когда он импортирует файлы /{system, vendor, odm}/etc/init/ или .rc по указанным путям во время mount_all.

Порядок импорта файлов немного сложный по устаревшим причинам и для обеспечения обратной совместимости.

Единственный правильный способ гарантировать, что команда была выполнена перед другой командой, это:

Поместить ее в действие с ранее выполненным триггером
Поместить ее в действие с тем же триггером в том же файле в более ранней линии.

Тем не менее, по умолчанию:

/init.rc анализируется, а затем рекурсивно анализируется каждый импорт.
Содержимое /system/etc/init/ разбирается в алфавитном порядке и анализируется последовательно, а импорт выполняется рекурсивно после анализа каждого файла.
Шаг 2 повторяется для /vendor/etc/init, а затем /odm/etc/init

andrwgldmn · 03.01.2019

Как изменить дерево для сборки других прошивок

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

Переименовываем lineage.mk в aokp.mk
Ищем все упоминания lineage.mk в дереве и меняем их на aokp.mk: grep -r "lineage.mk"
В переименованом lineage.mk меняем:
- с $(call inherit-product, vendor/lineage/config/common_full_phone.mk)
- на $(call inherit-product, vendor/aokp/configs/common_full_phone.mk)
- с PRODUCT_NAME := lineage_имя_устройства
- на PRODUCT_NAME := aokp_имя_устройства
  Путь к vendor/ROM/config/common_.mk у каждой прошивки свой, так что не ленитесь лезть в vendor/ROM/ и всё изучить.
В vendorsetup.sh меняем:
- с add_lunch_combo lineage_имя_устройства-тип_сборки
- на add_lunch_combo aokp_имя_устройства-тип_сборки

В принципе, это минимальный набор которого достаточно для начала сборки..

Lord_X · 05.01.2019

Код:

Which would you like? [aosp_arm-eng] 9
vendor/aoscp/config/common_full_phone.mk:7: error: _nic.PRODUCTS.[[device/samsung/j5xnlte/aoscp.mk]]: "vendor/aoscp/configs/common.mk" does not exist.
17:19:36 dumpvars failed with: exit status 1
Device j5xnlte not found. Attempting to retrieve device repository from CypherOS Github (http://github.com/CypherOS).
Repository for j5xnlte not found in the CypherOS Github repository list. If this is in error, you may need to manually add it to your local_manifests/roomservice.xml.
vendor/aoscp/config/common_full_phone.mk:7: error: _nic.PRODUCTS.[[device/samsung/j5xnlte/aoscp.mk]]: "vendor/aoscp/configs/common.mk" does not exist.
17:19:37 dumpvars failed with: exit status 1
vendor/aoscp/config/common_full_phone.mk:7: error: _nic.PRODUCTS.[[device/samsung/j5xnlte/aoscp.mk]]: "vendor/aoscp/configs/common.mk" does not exist.
17:19:38 dumpvars failed with: exit status 1

** Don't have a product spec for: 'aoscp_j5xnlte'
** Do you have the right repo manifest?

andrwgldmn · 05.01.2019

L Lord, какие там файлы есть?

Lord_X · 05.01.2019

Код:

vendor/aoscp/config

нет такой папки. configs там

а еще в aoscp.devices нет моего устройства. Добавить вручную?

Код:

angler
berkeley
bullhead
charlotte
cheeseburger
dumpling
h811
h815
kenzo
m8
mido
oneplus2
oneplus3
osprey
potter
shamu
sirius
tissot
titan
whyred

andrwgldmn · 05.01.2019

Lord написал(а):
вручную

Можно вообще удалить, в aoscp.mk в инклюде изменить на configs тогда. А что в этой папке лежит? Какие файлы? Лень на гитхаб лезть

Lord_X · 05.01.2019

Снимок экрана от 2019-01-05 17-37-50.png

во. Что-то изменилось.
Изменил на configs

Снимок экрана от 2019-01-05 17-41-36.png

andrwgldmn · 05.01.2019

L Lord, теперь make otapackage -j4 и ждать первой ошибки))

Lord_X · 05.01.2019

Ну добрался хоть до этого момента )
Ошибки, конечно, неизбежны. ) Я это понимаю.

Код:

system/sepolicy/Android.mk:89: warning: Be careful when using the SELINUX_IGNORE_NEVERALLOWS flag. It does not work in user builds and using it will not stop you from failing CTS.
[1054/1054] including vendor/samsung/serranovexx-common/Android.mk ...
bootable/recovery/Android.mk: error: recovery (EXECUTABLES android-arm) missing libhealthd.lineage (STATIC_LIBRARIES android-arm)
You can set ALLOW_MISSING_DEPENDENCIES=true in your environment if this is intentional, but that may defer real problems until later in the build.
hardware/interfaces/health/1.0/default/Android.mk: error: android.hardware.health@1.0-impl (SHARED_LIBRARIES android-arm) missing libhealthd.lineage (STATIC_LIBRARIES android-arm)
You can set ALLOW_MISSING_DEPENDENCIES=true in your environment if this is intentional, but that may defer real problems until later in the build.
hardware/qcom/wlan/qcwcn/wcnss-service/Android.mk: error: wcnss_service (EXECUTABLES android-arm) missing libqmiservices (SHARED_LIBRARIES android-arm)
You can set ALLOW_MISSING_DEPENDENCIES=true in your environment if this is intentional, but that may defer real problems until later in the build.
hardware/qcom/wlan/qcwcn/wcnss-service/Android.mk: error: wcnss_service (EXECUTABLES android-arm) missing libqmi (SHARED_LIBRARIES android-arm)
You can set ALLOW_MISSING_DEPENDENCIES=true in your environment if this is intentional, but that may defer real problems until later in the build.
hardware/qcom/wlan/qcwcn/wcnss-service/Android.mk: error: wcnss_service (EXECUTABLES android-arm) missing libqcci_legacy (SHARED_LIBRARIES android-arm)
You can set ALLOW_MISSING_DEPENDENCIES=true in your environment if this is intentional, but that may defer real problems until later in the build.
hardware/qcom/wlan/qcwcn/wcnss-service/Android.mk: error: wcnss_service (EXECUTABLES android-arm) missing libqmi_client_qmux (SHARED_LIBRARIES android-arm)
You can set ALLOW_MISSING_DEPENDENCIES=true in your environment if this is intentional, but that may defer real problems until later in the build.
hardware/qcom/wlan/qcwcn/wcnss-service/Android.mk: error: wcnss_service (EXECUTABLES android-arm) missing libmdmdetect (SHARED_LIBRARIES android-arm)
You can set ALLOW_MISSING_DEPENDENCIES=true in your environment if this is intentional, but that may defer real problems until later in the build.
hardware/ril/reference-ril/Android.mk: error: libreference-ril (SHARED_LIBRARIES android-arm) missing libril (SHARED_LIBRARIES android-arm)
You can set ALLOW_MISSING_DEPENDENCIES=true in your environment if this is intentional, but that may defer real problems until later in the build.
hardware/ril/rild/Android.mk: error: rild (EXECUTABLES android-arm) missing libril (SHARED_LIBRARIES android-arm)
You can set ALLOW_MISSING_DEPENDENCIES=true in your environment if this is intentional, but that may defer real problems until later in the build.
packages/apps/FMRadio/Android.mk: error: FMRadio (APPS android-arm) missing libfmjni (SHARED_LIBRARIES android-arm)
You can set ALLOW_MISSING_DEPENDENCIES=true in your environment if this is intentional, but that may defer real problems until later in the build.
system/core/healthd/Android.mk: error: charger (EXECUTABLES android-arm) missing libhealthd.lineage (STATIC_LIBRARIES android-arm)
You can set ALLOW_MISSING_DEPENDENCIES=true in your environment if this is intentional, but that may defer real problems until later in the build.
build/make/core/main.mk:846: error: exiting from previous errors.
18:14:29 ckati failed with: exit status 1

#### failed to build some targets (02:36 (mm:ss)) ####

Если не трудно - накидай мануал как эти ошибки определять и исправлять. Литературку какую может прочесть, а то так я боюсь что долго буду тебя эксплуатировать.

Lord_X · 06.01.2019

Смущает эта строка

Код:

bootable/recovery/Android.mk: error: recovery (EXECUTABLES android-arm) missing libhealthd.lineage (STATIC_LIBRARIES android-arm)

Где-то остался хвост линейки

hyperion70 · 06.01.2019

Lord написал(а):
Где-то остался хвост линейки

Да, вот:

чтобы видеть ссылку, вы должны быть зарегистрированы

hyperion70 · 14.02.2019

Собираю LOS 14.1. Сборка падает с ошибкой:

Код:

out/target/product/N1/obj/KERNEL_OBJ/usr/include/asm/sigcontext.h:53:2: error: unknown type name '__uint128_t'

Почему? Сборка 64-битная, указание на это в дереве есть

чтобы видеть ссылку, вы должны быть зарегистрированы

Больше лога

чтобы видеть ссылку, вы должны быть зарегистрированы

Upd: помог этот

чтобы видеть ссылку, вы должны быть зарегистрированы

.

andrwgldmn · 17.02.2019

Всем доброго. Подскажите по

чтобы видеть ссылку, вы должны быть зарегистрированы

, почему не бутится? 6755 los14.1 + почему-то отвалилось адб..

чтобы видеть ссылку, вы должны быть зарегистрированы

andrwgldmn · 07.03.2019

Парсинг контекстов file_/service_/property_ с дальнейшим получением .te файлов с типами.

Сделал простенький скрипт на питоне.

чтобы видеть ссылку, вы должны быть зарегистрированы

Работает как часы.
Всё в README

WinKarbik · 16.03.2019

Любителем портировать или что делать с ядром, чтобы запустить андроид выше.

Требования: Компьютер с установленной UNIX-based системой, исходный код ядра от производителя телефона

Больше всего эта инструкция подойдёт именно для портировщиков, ибо тут будут патчи только для запуска андроид версии выше, чем имеется. Она подойдёт и для сборщиков, но те кто уже довольно продолжительное время собирает прошивки, знает, что помимо этих патчей есть ещё и всякие доп. патчи(livedisplay; добавление core_ctl; коммиты, которые исправляют сборку прошивки из-за ядра и т.д.). Патчи проверялись на процессоре msm8939(Телефон Xiaomi Redmi 3), в принципе без проблем должны применяться на всех процессорах от Qualcomm, с другими процессорами может быть небольшая проблема с применением коммитов. Начнём:

Так как моё устр-во поставлялось с прошивкой 5.1 на борту, поэтому я начал патч именно с неё.
1. Открываем терминал, устанавливаем git

Код:

sudo apt install git

2. Скачиваем исходный код ядра и распаковываем его в папку /home/%username%/kernel_sources . В моём случае исходный код ядра на github'е, поэтому я скачаю их оттуда командой:

Код:

git clone https://github.com/MiCode/Xiaomi_Kernel_OpenSource.git -b ido-l-oss /home/%username%/kernel_sources

где %username% - имя пользователя системы
3. Переходим в папку с распакованным исходным кодом:

Код:

cd /home/%username%/kernel_sources

4. Сейчас нам будет необходимо инициализировать эту папку как git репозиторий. После этого мы сможем использовать команду cherry-pick(взять патч с уже другого пропатченного ядра) и также сможем выложить наш исходный код с историей патчей на github.

Код:

git init
git add .
git commit -m "Initial import of source code"

(Опционально, для тех кто желает позже выложить исходный код на github) Создаём бранч для github:

Код:

git checkout -b android-6.0

где android-6.0 - название вашего бранча
5. А теперь приступаем к подключению репозитория с патчами(за основу будет взят мой репозиторий с уже необходимыми применёнными патчами в исходном коде ядра):

Код:

git remote add patches https://github.com/WinKarbik/kernel_sources.git
git fetch patches

После этого пойдёт загрузка моего исходного кода(как базы) для того, чтобы можно было взять необходимые коммиты оттуда.
6. Приступаем к патчингу исходников. Выполняем поочерёдно каждую из команд:

Код:

git cherry-pick d873bae
git cherry-pick 7c2f128
git cherry-pick d601cb7
git cherry-pick a9db470
git cherry-pick 6882fc0
git cherry-pick 3785321
git cherry-pick 4341b40
git cherry-pick 8e23e6a
git cherry-pick bb88158
git cherry-pick 1916965
git cherry-pick 78acf33
git cherry-pick 37eac5b
git cherry-pick 8c2d35d
git cherry-pick fc2b130
git cherry-pick 787d8a7
git cherry-pick b75933a
git cherry-pick 1f1f0a0
git cherry-pick f64207b
git cherry-pick df7a68d
git cherry-pick 0d0be75
git cherry-pick 7e33539
git cherry-pick a8f1c21
git cherry-pick 7991c2e
git cherry-pick 633177a
git cherry-pick 717fb05
git cherry-pick f84df63
git cherry-pick e2d0606

Смотрим первый спойлер и делаем аналогично, команды в 5 пункте будут другие:

Код:

git remote add patches https://github.com/WinKarbik/kernel_xiaomi_msm8916.git
git fetch patches

И в 6 пункте также:

Код:

git cherry-pick fcad7a5
git cherry-pick 713c7b6
git cherry-pick b13bbd5
git cherry-pick 4b8c51d
git cherry-pick a9d4e9f
git cherry-pick d741469
git cherry-pick 253a003
git cherry-pick 3e4575a
git cherry-pick f0deffa
git cherry-pick 9a3a436
git cherry-pick dcb3a16
git cherry-pick 908afaf
git cherry-pick 3e37cd4
git cherry-pick c4c687c
git cherry-pick f6444dc
git cherry-pick 1801642
git cherry-pick 9cf1f77
git cherry-pick 71149ca

В процессе написания...

andrwgldmn · 16.03.2019

Shim_parser

Наваял скрипт для ленивых :Lol:

Парсит логкат и выдаёт пустышку с недостающим символом

чтобы видеть ссылку, вы должны быть зарегистрированы

andrwgldmn · 23.08.2019

Немного про SElinux в Android

Как часть безопасности Android, Android использует Security-Enhanced Linux (SELinux) для обеспечения обязательного контроля доступа (MAC) ко всем процессам, даже процессам, работающим с привилегиями root/superuser. С помощью SELinux Android может лучше защищать и ограничивать системные службы, контролировать доступ к данным приложений и системным журналам, уменьшать влияние вредоносного программного обеспечения и защищать пользователей от потенциальных ошибок в коде на мобильных устройствах.

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

Enforcing: SELinux разрешает или запрещает доступ на основании правил политики SELinux. Это как раз тот режим, который можно назвать ON/Enabled. В этот режим мы переводим систему командой setenforce 1
Permissive: Политики SELinux не применяются. Однако система регистрирует все отказы к предоставлению доступа, как это было бы в режиме Enforcing. Режим используется для отладки. Команда — setenforce 0.

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

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

Происхождение:
Модель безопасности Android частично основана на концепции «песочниц» для приложений. Каждое приложение запускается в своей собственной песочнице. До Android 4.3 эти песочницы определялись путем создания уникального UID Linux для каждого приложения во время установки. Android 4.3 и более поздние версии используют SELinux для дальнейшего определения границ изолированной программной среды приложения Android.

В Android 5.0 и более поздних версиях SELinux полностью применяется, основываясь на разрешительной версии Android 4.3 и частичном применении Android 4.4. С этим изменением Android перешел от принудительного применения на ограниченном наборе важных доменов (installd, netd, vold и zygote) ко всему (более 60 доменов). В частности:

Все в принудительном режиме в Android 5.x и выше.
Никакие процессы кроме init не должны запускаться в домене init.
Любое общее отклонение (для block_device, socket_device, default_service и т. д.) указывает на то, что устройству требуется специальный домен.

Android 6.0 укрепил систему, уменьшив допустимость нашей политики и включив в нее лучшую изоляцию между пользователями, фильтрацию IOCTL, снижение угрозы для открытых служб, дальнейшее ужесточение доменов SELinux и крайне ограниченный доступ к /proc.

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

Android 8.0 обновил SELinux для работы с Treble, который отделяет код поставщика более низкого уровня от системной платформы Android. В этом выпуске обновлена политика SELinux, чтобы производители устройств и производители SOC могли обновлять свои части политики, создавать свои образы (vendor.img, boot.img и т. д.), а затем обновлять эти образы независимо от платформы или наоборот.

В то время как на устройстве может быть запущена более высокая/более новая версия платформы (фреймворка), обратная совместимость не поддерживается; образы поставщиков (vendor.img/odm.img) не могут иметь более новую версию, чем платформа (system.img). Таким образом, в более новой версии платформы могут возникнуть проблемы совместимости с SELinux, поскольку политика SELinux для платформы имеет более новую версию, чем части политики SELinux, разработанные поставщиком. Модель Android 8.0 предоставляет метод сохранения совместимости для предотвращения ненужных одновременных OTA.

Обязательный контроль доступа (MAC):

Security Enhanced Linux (SELinux) - это система обязательного контроля доступа (MAC) для операционной системы Linux. Как система MAC, она отличается от привычной системы контроля доступа (DAC) в Linux. В системе DAC существует концепция владения, при которой владелец определенного ресурса контролирует разрешения доступа, связанные с ним. Как правило, это является грубым и может привести к непреднамеренному повышению привилегий. Система MAC, однако, консультируется с центральным органом власти для принятия решения по всем попыткам доступа.

SELinux был реализован как часть платформы Linux Security Module (LSM), которая распознает различные объекты ядра и действия, выполняемые над ними. В момент, когда каждое из этих действий будет выполнено, вызывается функция ловушки LSM, чтобы определить, следует ли разрешить действие на основе информации для него, хранящейся в непрозрачном объекте безопасности. SELinux предоставляет реализацию этих хуков и управление этими объектами безопасности, которые в сочетании с собственной политикой определяют решения о доступе.

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

Например, программное обеспечение обычно должно запускаться от имени учетной записи root для записи в необработанные блочные устройства. В традиционной среде Linux на основе DAC, если пользователь root скомпрометирован, он может писать на каждое необработанное блочное устройство. Однако SELinux можно использовать для маркировки этих устройств, чтобы процесс, которому назначены привилегии root, мог выполнять запись только в те, которые указаны в соответствующей политике. Таким образом, процесс не может перезаписать данные и системные параметры за пределами определенного необработанного блочного устройства.

Режимы исполнения:

Enforcing: SELinux разрешает или запрещает доступ на основании правил политики SELinux. Это как раз тот режим, который можно назвать ON/Enabled. В этот режим мы переводим систему командой setenforce 1
Permissive: Политики SELinux не применяются. Однако система регистрирует все отказы к предоставлению доступа, как это было бы в режиме Enforcing. Режим используется для отладки. Команда — setenforce 0.

Метки, правила и домены:

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

В SELinux метка имеет вид:

Код:

user: role: type: mls_level

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

Правила имеют вид:

Код:

allow domains types:classes permissions;

где:

Домен - метка для процесса или набора процессов. Также называется типом домена, поскольку это просто тип для процесса.
Тип - метка для объекта (например, файла, сокета) или набора объектов.
Класс - тип объекта (например, файл, сокет), к которому осуществляется доступ.
Разрешение - выполняемая операция (например, чтение, запись).

Например:

Код:

allow appdomain app_data_file:file rw_file_perms;

Это говорит о том, что всем доменам приложений разрешено читать и записывать файлы с меткой app_data_file. Стоит заметить, что это правило опирается на макросы, определенные в файле global_macros, а другие полезные макросы также можно найти в файле te_macros. Макросы предоставляются для общих групп классов, разрешений и правил, и их следует использовать по возможности, чтобы уменьшить вероятность сбоев из-за отказа в соответствующих разрешениях. Эти файлы макросов находятся в каталоге system/sepolicy. В Android 8.0 и выше они находятся в публичном подкаталоге с другими поддерживаемыми публичными разделителями.

Помимо индивидуального перечисления доменов или типов в правиле, можно также обратиться к набору доменов или типов через атрибут.
Атрибут - это просто имя для набора доменов или типов. Каждый домен или тип может быть связан с любым количеством атрибутов. Когда пишется правило, в котором указывается имя атрибута, это имя автоматически расширяется до списка доменов или типов, связанных с атрибутом. Например, атрибут домена связан со всеми доменами процессов, а атрибут file_type связан со всеми типами файлов.

Домен обычно соответствует процессу и имеет метку, связанную с ним.

Например, типичное приложение Android работает в своем собственном процессе и имеет метку untrusted_app, которая предоставляет ему определенные ограниченные разрешения.

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

Доступ к следующим общим меткам никогда не должен быть напрямую разрешен для доменов; вместо этого для объекта или объектов должен быть создан более конкретный тип:

socket_device
device
block_device
default_service
system_data_file
tmpfs

Основные файлы:

Как правило, не нужно изменять system/sepolicy напрямую. Вместо этого добавьте или редактируйте свои собственные файлы политик для конкретного устройства в каталоге device/изготовитель/имя-устройства/sepolicy. В Android 8.0 и выше изменения, которые вы вносите в эти файлы, должны влиять только на политику в каталоге вашего вендора.

Файлы политик:

Файлы с расширением *.te являются исходными файлами политики SELinux, которые определяют домены и их метки. Вам может потребоваться создать новые файлы политик в device/изготовитель/имя-устройства/sepolicy, но вы должны попытаться обновить существующие файлы, если возможно.

Контекстные файлы:

В контекстных файлах указываются метки для ваших объектов.

file_contexts назначает метки файлам и используется различными компонентами пользовательского пространства. По мере создания новых политик, создавайте или обновляйте этот файл, чтобы назначать файлам новые метки. Чтобы применить новые file_contexts, пересоберите образ файловой системы или запустите restorecon для файла, который будет перемаркирован. При обновлениях изменения file_contexts автоматически применяются к системным разделам и разделам пользовательских данных как часть обновления. Изменения также могут автоматически применяться при обновлении до других разделов путем добавления вызовов restorecon_recursive в ваш файл init.board.rc после того, как раздел был смонтирован для чтения-записи.
genfs_contexts назначает метки файловым системам, таким как proc или vfat, которые не поддерживают расширенные атрибуты. Эта конфигурация загружается как часть политики ядра, но изменения могут не вступать в силу для inode в ядре, требуя перезагрузки или размонтирования и перемонтирования файловой системы, чтобы полностью применить изменения. Определенные метки также могут быть назначены определенным монтировкам, таким как vfat, используя опцию context=mount.
property_contexts назначает метки системным свойствам Android, чтобы контролировать, какие процессы могут их устанавливать. Эта конфигурация читается процессом init во время запуска.
service_contexts назначает метки для сервисов связывания Android, чтобы контролировать, какие процессы могут добавлять (регистрировать) и находить (искать) ссылку на связыватель для сервиса. Эта конфигурация читается процессом servicemanager во время запуска.
seapp_contexts назначает метки процессам приложения и data/data каталогам. Эта конфигурация считывается процессом zygote при каждом запуске приложения и программой установки во время запуска.
mac_permissions.xml назначает тегу seinfo приложениям на основе их подписи и, необязательно, имени пакета. Затем тег seinfo можно использовать в качестве ключа в файле seapp_contexts для назначения определенной метки всем приложениям с этим тегом seinfo. Эта конфигурация читается system_server во время запуска.

BoardConfig.mk:
После редактирования или добавления файлов политик и контекстов обновите BoardConfig.mk, чтобы он ссылался на подкаталог sepolicy и каждый новый файл политики:

Код:

BOARD_SEPOLICY_DIRS += \
        <root>/device/manufacturer/device-name/sepolicy

BOARD_SEPOLICY_UNION += \
        genfs_contexts \
        file_contexts \
        sepolicy.te

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

Симлинки - поскольку символические ссылки отображаются в виде файлов, они часто читаются как файлы, что может привести к эксплойтам. Например, некоторые привилегированные компоненты, такие как init, изменяют права доступа к определенным файлам, иногда будучи чрезмерно открытыми.
Системные файлы. Рассмотрим класс системных файлов, которые должны быть изменены только системным сервером. Тем не менее, поскольку netd, init и vold работают от имени root, они могут обращаться к этим системным файлам. Таким образом, если netd скомпрометирован, он может скомпрометировать эти файлы и, возможно, саму систему.
Данные приложения. Другим примером является класс функций, которые должны запускаться от имени пользователя root, но не должны получать доступ к данным приложения. Это невероятно полезно, поскольку могут быть сделаны широкомасштабные утверждения, например, что некоторые домены, не связанные с данными приложения, не имеют доступа к Интернету.
setattr - для таких команд, как chmod и chown, вы можете определить набор файлов, в которых связанный домен может выполнять setattr. Все что угодно, кроме этого, может быть запрещено этими изменениями, даже root. Таким образом, приложение может запускать chmod и chown для тех, которые помечены как app_data_files, но не для shell_data_files или system_data_files.

SELinux основан на компьютерном языке M4 и поэтому поддерживает различные макросы для экономии времени.

В следующем примере всем доменам предоставляется доступ для чтения или записи в /dev/null и чтения из /dev/zero:

Код:

# Allow read / write access to /dev/null
allow domain null_device:chr_file { getattr open read ioctl lock append write};

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file { getattr open read ioctl lock };

Этот же пример, но только с макросами:

Код:

# Allow read / write access to /dev/null
allow domain null_device:chr_file rw_file_perms;

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file r_file_perms;

Пример политики для DHCP:

Код:

type dhcp, domain;
permissive dhcp;
type dhcp_exec, exec_type, file_type;
type dhcp_data_file, file_type, data_file_type;

init_daemon_domain(dhcp)
net_domain(dhcp)

allow dhcp self:capability { setgid setuid net_admin net_raw net_bind_service
};
allow dhcp self:packet_socket create_socket_perms;
allow dhcp self:netlink_route_socket { create_socket_perms nlmsg_write };
allow dhcp shell_exec:file rx_file_perms;
allow dhcp system_file:file rx_file_perms;
# For /proc/sys/net/ipv4/conf/*/promote_secondaries
allow dhcp proc_net:file write;
allow dhcp system_prop:property_service set ;
unix_socket_connect(dhcp, property, init)

type_transition dhcp system_data_file:{ dir file } dhcp_data_file;
allow dhcp dhcp_data_file:dir create_dir_perms;
allow dhcp dhcp_data_file:file create_file_perms;

allow dhcp netd:fd use;
allow dhcp netd:fifo_file rw_file_perms;
allow dhcp netd:{ dgram_socket_class_set unix_stream_socket } { read write };
allow dhcp netd:{ netlink_kobject_uevent_socket netlink_route_socket
netlink_nflog_socket } { read write };

Давайте рассмотрим пример:

В первой строке объявления типа демон DHCP наследуется от базовой политики безопасности (домена). Из предыдущих примеров мы можем понять что DHCP может читать и записывать в /dev/null.
Во второй строке DHCP идентифицируется как разрешающий домен.
В строке init_daemon_domain (dhcp) политика заявляет, что DHCP порожден от init и ему разрешено связываться с ним.
В строке net_domain (dhcp) политика позволяет DHCP использовать общие сетевые функции из сетевого домена, такие как чтение и запись пакетов TCP, обмен данными через сокеты и выполнение DNS-запросов.
В строке allow dhcp proc_net: file write; политика говорит, что DHCP может записывать в определенные файлы в /proc. Эта строка демонстрирует тонкую маркировку файлов в SELinux. Он использует метку proc_net для ограничения доступа на запись только к файлам в /proc/sys/net.
Последний блок примера, начинающийся с allow dhcp netd: fd use; показывает, как приложения могут взаимодействовать друг с другом. Политика гласит, что DHCP и netd могут связываться друг с другом через файловые дескрипторы, файлы FIFO, сокеты датаграмм и потоковые сокеты UNIX. DHCP может только читать и записывать данные из сокетов датаграмм и потоковых сокетов UNIX, но не создавать и не открывать их.

Доступные элементы управления

file ioctl read write create getattr setattr lock relabelfrom relabelto append unlink link rename execute swapon quotaon mounton
directory add_name remove_name reparent search rmdir open audit_access execmod
socket ioctl read write create getattr setattr lock relabelfrom relabelto append bind connect listen accept getopt setopt shutdown recvfrom sendto recv_msg send_msg name_bind
filesystem mount remount unmount getattr relabelfrom relabelto transition associate quotamod quotaget
process fork transition sigchld sigkill sigstop signull signal ptrace getsched setsched getsession getpgid setpgid getcap setcap share getattr setexec setfscreate noatsecure siginh setrlimit rlimitinh dyntransition setcurrent execmem execstack execheap setkeycreate setsockcreate
security compute_av compute_create compute_member check_context load_policy compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot read_policy
capability chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin
sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write audit_control setfcap

Разбираем отказы Selinux

Сообщения SELinux содержат avc:, поэтому их легко найти с помощью grep. Можно получить текущие отказы, запустив cat /proc/kmsg, или получить отказы от предыдущей загрузки, запустив cat /sys/fs/pstore/console-ramoops.

В частности, в этих сообщениях указывается, какие процессы не работают на данный момент и почему. Вот пример:

Код:

avc: denied  { connectto } for  pid=2671 comm="ping" path="/dev/socket/dnsproxyd"
scontext=u:r:shell:s0 tcontext=u:r:netd:s0 tclass=unix_stream_socket

Интерпретировать этот вывод можно так:

{ connectto } представляет предпринимаемое действие. Вместе с tclass в конце (unix_stream_socket) он примерно говорит вам, что с чем было сделано. В этом случае что-то пыталось подключиться к сокету потока Unix.
scontext (u: r: shell: s0) сообщает вам, какой контекст инициировал действие. В этом случае это нечто, работающее как оболочка.
tcontext (u: r: netd: s0) сообщает вам контекст цели действия. В данном случае это unix_stream_socket, принадлежащий netd.
comm = "ping" дает вам дополнительную подсказку о том, что выполнялось в момент генерирования отказа. В этом случае это довольно хороший намек.

Другой пример:

Код:

<5> type=1400 audit: avc:  denied  { read write } for  pid=177
comm="rmt_storage" name="mem" dev="tmpfs" ino=6004 scontext=u:r:rmt:s0
tcontext=u:object_r:kmem_device:s0 tclass=chr_file

Вот ключевые элементы этого отказа:

Действие - попытка действия выделена в фигурных скобках, чтение-запись или setenforce.
Исполнитель - scontext (исходный контекст) представляет исполнителя действия, в данном случае это демон rmt_storage.
Объект - tcontext (целевой контекст) представляет объект, с которым работал исполнитель, в этом случае это kmem.
Результат - tclass (целевой класс) указывает тип объекта, над которым выполняется действие, в данном случае это chr_file (символьное устройство).

zhyk_magadan · 30.08.2019

Ребята, помогите. Весь инет перерыл, ничего не нашёл. Под самый конец вышло.

Код:

[ 15% 206/1365] Target userdata fs image: /home/zhyk_magadan/Philips/Android/out/target/product/S327/userdata.img
FAILED: /bin/bash -c "(mkdir -p /home/zhyk_magadan/Philips/Android/out/target/product/S327/data ) && (mkdir -p /home/zhyk_magadan/Philips/Android/out/target/product/S327/obj/PACKAGING/userdata_intermediates && rm -rf /home/zhyk_magadan/Philips/Android/out/target/product/S327/obj/PACKAGING/userdata_intermediates/userdata_image_info.txt ) && (echo \"system_size=1610612736\" >>  /home/zhyk_magadan/Philips/Android/out/target/product/S327/obj/PACKAGING/userdata_intermediates/userdata_image_info.txt ) && (echo \"userdata_size=13106688\" >>  /home/zhyk_magadan/Philips/Android/out/target/product/S327/obj/PACKAGING/userdata_intermediates/userdata_image_info.txt ) && (echo \"cache_size=419430400\" >>  /home/zhyk_magadan/Philips/Android/out/target/product/S327/obj/PACKAGING/userdata_intermediates/userdata_image_info.txt ) && (echo \"extfs_sparse_flag=-s\" >>  /home/zhyk_magadan/Philips/Android/out/target/product/S327/obj/PACKAGING/userdata_intermediates/userdata_image_info.txt ) && (echo \"squashfs_sparse_flag=-s\" >>  /home/zhyk_magadan/Philips/Android/out/target/product/S327/obj/PACKAGING/userdata_intermediates/userdata_image_info.txt ) && (echo \"selinux_fc=/home/zhyk_magadan/Philips/Android/out/target/product/S327/root/file_contexts.bin\" >>  /home/zhyk_magadan/Philips/Android/out/target/product/S327/obj/PACKAGING/userdata_intermediates/userdata_image_info.txt ) && (echo \"skip_fsck=true\" >>  /home/zhyk_magadan/Philips/Android/out/target/product/S327/obj/PACKAGING/userdata_intermediates/userdata_image_info.txt ) && (PATH=/home/zhyk_magadan/Philips/Android/out/host/linux-x86/bin/:\$PATH ./build/tools/releasetools/build_image.py /home/zhyk_magadan/Philips/Android/out/target/product/S327/data /home/zhyk_magadan/Philips/Android/out/target/product/S327/obj/PACKAGING/userdata_intermediates/userdata_image_info.txt /home/zhyk_magadan/Philips/Android/out/target/product/S327/userdata.img /home/zhyk_magadan/Philips/Android/out/target/product/S327/system ) && (size=\$(for i in /home/zhyk_magadan/Philips/Android/out/target/product/S327/userdata.img; do stat --format \"%s\" \"\$i\" | tr -d '\\n'; echo +; done; echo 0); total=\$(( \$( echo \"\$size\" ) )); printname=\$(echo -n \"/home/zhyk_magadan/Philips/Android/out/target/product/S327/userdata.img\" | tr \" \" +); img_blocksize=135168; twoblocks=\$((img_blocksize * 2)); onepct=\$(((((13514688 / 100) - 1) / img_blocksize + 1) * img_blocksize)); reserve=\$((twoblocks > onepct ? twoblocks : onepct)); maxsize=\$((13514688 - reserve)); echo \"\$printname maxsize=\$maxsize blocksize=\$img_blocksize total=\$total reserve=\$reserve\"; if [ \"\$total\" -gt \"\$maxsize\" ]; then echo \"error: \$printname too large (\$total > [13514688 - \$reserve])\"; false; elif [ \"\$total\" -gt \$((maxsize - 32768)) ]; then echo \"WARNING: \$printname approaching size limit (\$total now; limit \$maxsize)\"; fi )"
BuildImage: in_dir = /home/zhyk_magadan/Philips/Android/out/target/product/S327/data, out_file = /home/zhyk_magadan/Philips/Android/out/target/product/S327/userdata.img
fs type is not ext4
Running:  mkyaffs2image -f /home/zhyk_magadan/Philips/Android/out/target/product/S327/data /home/zhyk_magadan/Philips/Android/out/target/product/S327/userdata.img /home/zhyk_magadan/Philips/Android/out/target/product/S327/root/file_contexts.bin data
Traceback (most recent call last):
  File "./build/tools/releasetools/build_image.py", line 714, in <module>
    main(sys.argv[1:])
  File "./build/tools/releasetools/build_image.py", line 707, in main
    if not BuildImage(in_dir, image_properties, out_file, target_out):
  File "./build/tools/releasetools/build_image.py", line 487, in BuildImage
    (_, exit_code) = RunCommand(build_command)
  File "./build/tools/releasetools/build_image.py", line 48, in RunCommand
    p = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
  File "/usr/lib/python2.7/subprocess.py", line 394, in __init__
    errread, errwrite)
  File "/usr/lib/python2.7/subprocess.py", line 1047, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory
[ 15% 206/1365] Construct recovery from boot
failed to reconstruct target deflate chunk 1 [(null)]; treating as normal
chunk 0: type 0 start 0 len 7036938
chunk 1: type 2 start 7036938 len 2651136
chunk 2: type 0 start 8416384 len 896
Construct patches for 3 chunks...
patch   0 is 207 bytes (of 7036938)
patch   1 is 3286912 bytes (of 1379446)
patch   2 is 188 bytes (of 896)
chunk   0: normal   (         0,    7036938)         207
chunk   1: deflate  (   7036938,    5501600)     3286912  (null)
chunk   2: normal   (  12538538,       1366)         188
[ 15% 206/1365] target Export Resources: framework-res (/home/zhyk_magadan/Philips/Android/out/target/common/obj/APPS/framework-res_intermediates/package-export.apk)
warning: string 'candidates_style' has no default translation.
warning: string 'gsm_alphabet_default_charset' has no default translation.
warning: string 'wfcSpnFormat' has no default translation.
nothing matches overlay file default_wallpaper.png, for flavor hdpi-v4
nothing matches overlay file default_wallpaper.png, for flavor xhdpi-v4
nothing matches overlay file default_wallpaper.png, for flavor xxhdpi-v4
nothing matches overlay file default_wallpaper.png, for flavor xxxhdpi-v4

P.S. 31.08.2019 ошибка исправлена. В BoardConfig добавил строчку.

Инструкции по сборке Android из исходников

rm -rf /*

Стараюсь быть человеком

rm -rf /*

rm -rf /*

rm -rf /*

Стараюсь быть человеком

rm -rf /*

Стараюсь быть человеком

rm -rf /*

Стараюсь быть человеком

rm -rf /*

Стараюсь быть человеком

Стараюсь быть человеком

#include <calmness.h>

#include <calmness.h>

rm -rf /*

rm -rf /*

Банан

rm -rf /*

rm -rf /*

Друг форума

Похожие темы