Arm linux androideabi download
В: Могу ли я собрать ядро если производитель не выложил исходники для моего девайса?
O: Ответ на ваш вопрос неоднократно обсуждался, например «Сборка ядра не имея исходников», вы сможете собрать ядро, но придется приложить больше усилий.
В: Слышал, что в данной ветке присутствуют телепаты, гадалки, медиумы и ясновидцы, которые могут дать полный и адекватный ответ на не полностью сформулированный вопрос?
O: Эх, к нашему большому сожалению, все вышеперечисленные товарищи ушли на ТНТ и ТВ3. И мы, как и вы, тоже будем надеяться на их скорейшее возвращение в ряды пользователей нашего форума.
А пока, будьте добры: если вы хотите получить адекватный ответ на ваш вопрос, то формулируйте его соответственно.
Например: устройство + платформа + версия ядра / андроид + описание проблемы + действия которые к ней привели (изменение конфигурации, изменение в исходниках, лог терминала и/или logcat) + ой, нечаянно удалил + ой, а не помню что.
Работоспособность магнитометра
Клонирование проекта
Про сборку 9-10 для проца mt6735p (ну и видимо mt6735m)
Добавляем поддержку aptX кодека в ALPS
Сборка модулей вместе с ядром без альпсов. Инструкция для 8.1 mt6580 (версия ядра 3.18.79)
Гайд, для тех кто хочет достать прошивку тача GSLXXXX
Инструкция по сборке ядра Android (лучшая на 4pda) | или скачать 
Kernel_building.docx.zip ( 90,32 КБ )
Мануал по сборке ядра.
Сборка отдельного модуля / либа / бина.
Пояснения к сборке Андроид 5.х
Инструкция по сборке ядра без использования ПК
Игнорирование ошибок сборки
Мануал по портированию исходного кода ядра 4.2.х -> 4.4.x |
Работа кнопки гарнитуры platform/../../drivers/accdet
Отключение Encryption в Андроид 5.х
Инструкция по добавлению governors & schedulers
Немного по ошибкам сборки
Сборка AOSP с busybox
Компиляция Android 6.0 под Windows в оболчке bash
Перенос стокового dtb на примере mtk67xx
Добавляем поддержку OTA в свою прошивку
Как прикрутить cameracustom от сток 6 на ноугат
Инструкция по восстановлению прошивки тачскрина Synaptics
Инструкция по поднятию тачскринов
В теме нет куратора. Если в теме есть пользователь, желающий стать Куратором и соответствующий Требованиям для кандидатов, он может подать заявку в теме Хочу стать Куратором (предварительно изучив шапку темы и все материалы для кураторов).
До назначения куратора, по вопросам наполнения шапки, обращайтесь к модераторам раздела через кнопку 
под сообщениями, на которые необходимо добавить ссылки.
Сообщение отредактировал derak1129 — 05.08.21, 06:03
Я пока кроме патча биндера не могу ничего сказать 😉 Но патч биндера все знающие видели. Это под СМ11 я так понимаю только. Если посмотреть просто на прошивки от 4.4 видно что там модули не собираются. Соответственно вопросы возникают. Исходники нет нет да появляются под 4.4. Вопрос: Кто то еще пытался совместить исхи 4.2 под 4.4 ?
Сообщение отредактировал Cheshkin — 25.06.14, 14:15
Собственно, для чего создавалась эта тема:
В сети уже есть в открытом доступе исходники Android 4.4 от mediatek c ядром версии 3.4.67 Я встречал их по крайней мере на три платформы — 6582, 6592 и новая, еще не вышедшая в свет платформа 6571. Вот (кликабельно) одно из хранилищ на котором их можно найти.
Большинство аппаратов на платформе Mediatek имеют версию ядра 3.4.5 адаптированную под JB 4.2.2 и на многие аппараты уже есть предоставленные производителем либо собранные умельцами исходники соответственно версии 3.4.5. Так вот, в первую очередь интересует перенос своих драйверов в дерево исходников версии 3.4.67 и сборка рабочего ядра с последующим запуском Android KitKat. Во вторую очередь — портирование между платформами, то есть при имеющихся исходниках версии 3.4.67 от mt6582 и исходниках mt6589 версии 3.4.5 собрать ядро версии 3.4.67 для mt6589
Как это сделать (Мое мнение, на правильность не претендую) Перенести папки /mediatek/custom/mtxxxx, /mediatek/custom/проект, mediatek/config/mtxxxx, /mediatek/config/проект и /mediatek/platform/mtxxxx из исходников своего аппарата в исходники из которых будем собирать новое ядро, исправить все ошибки возникающие при компиляции и запустить ядро на телефоне.
Собранное мной по такому алгоритму ядро запускаться категорически отказалось, теперь надеюсь решить вопрос коллегиально.
Я так понимаю это есть как раз сборка ядра вместе с рам диском ?. Но это можно пока упустить. Рам диск это отдельная история
именно так и планировал начинать перенос исхов. Сегодня будет первая попытка.
вопрос:
Очень важным являются настройки видеоускорителя. У меня он
. Без его правильного переноса прошивка не стартанет. Ессно как его из проекта правильно перенести ?
Сообщение отредактировал Cheshkin — 26.06.14, 07:39
- В этой теме обсуждается портирование конфигов и драйверов своего аппарата MTxxxx в ядро последней версии.
- В этой теме не обсуждаются вопросы не относящиеся непосредственно к данной теме(настройка рабочего окружения, поиск драйверов для своего аппарата, вопросы вроде «Что значит Undeclared function?» и так далее, то есть тема создана для людей уже умеющих хотя бы собрать ядро из готовых исходников и разобраться c простыми ошибками при компиляции)
- В этой теме не стол заказов — здесь Вам помогут советом, но основную работу Вам придется делать самим.
- Сообщения, не относящиеся к теме обсуждения (оффтоп), удаляются без предупреждения.
В: Слышал, что в данной ветке присутствуют телепаты, гадалки, медиумы и ясновидцы, которые могут дать полный и адекватный ответ на не полностью сформулированный вопрос?
O: Эх, к нашему большому сожалению, все вышеперечисленные товарищи ушли на ТНТ и ТВ3. И мы, как и вы, тоже будем надеяться на их скорейшее возвращение в ряды пользователей нашего форума.
А пока, будьте добры: если вы хотите получить адекватный ответ на ваш вопрос, то формулируйте его соответственно.
Например: устройство + платформа + версия ядра / андроид + описание проблемы + действия которые к ней привели (изменение конфигурации, изменение в исходниках, лог терминала и/или logcat) + ой, нечаянно удалил + ой, а не помню что.
Источник
Как собрать нативную библиотеку для Android
Собрать и заставить работать приложение с небольшим количеством нативного кода несложно. Если же вы хотите использовать нативную библиотеку, в которой много файлов, становится труднее. Сложность в том, что нативные библиотеки распространяются в виде исходного кода, который нужно компилировать под нужную архитектуру процессора. На примере аудиокодека Opus я покажу, как это сделать.
В своей предыдущей статье я на примере аудиокодека Opus показал, как решить задачу сборки нативной библиотеки для Android, но в проект был добавлен весь исходный код Opus, а так делать не хочется. По-хорошему нужно иметь в проекте уже собранные .so или .a, и используя их, писать свои врапперы на C/C++ и собирать приложение. Об этом и пойдёт речь в статье. На примере того же аудиокодека Opus я покажу, как с помощью NDK получить скомпилированные .so и .a, чтобы далее использовать их в Android-проекте.
Чтобы использовать любую нативную библиотеку, нам нужно написать враппер на C/C++, в котором мы будем вызывать методы самой библиотеки. Мы скомпилируем и соберём библиотеку Opus как статическую (.a).
Мы вызываем функцию в нашем C файле, которая описана в другой библиотеке. Для этого в начале файла пишем #include . Далее на этапе компиляции C файла, если библиотека статическая(.a), то вместо #include компилятор подставит весь код этой функции. Если динамическая(.so), то подставит только ссылку на функцию. Таким образом, при использовании статической библиотеки у нас есть весь код, который нам необходим из другой библиотеки, а при использовании динамической код будет подгружаться динамически.
Использование .so в зависимостях может уменьшить размер нашей итоговой библиотеки. Это было бы так, если бы Opus был стандартной библиотекой, но так как её нет в Android, мы должны её предоставить. Поэтому итоговый размер нашего libjniopus.so будет одинаковым, что при использовании libopus.a, что при использовании libopus.so.
Для компиляции нативных библиотек из исходников в NDK c версии 19 есть готовые удобные инструменты «из коробки». В документации описано, как их использовать. Описание довольно короткое, поэтому человек, не имеющий опыта в сборке нативных библиотек, неизбежно столкнётся со сложностями. Как их решить, я разберу ниже.
Собираем Opus из исходников
Сначала скачиваем исходники: либо из репозитория (git clone), либо архивом. У Opus есть Autoconf — утилита, которая автоматически создаёт конфигурационные скрипты. В проекте с Autoconf можно задать toolchain для компиляции, используя ENV-переменные. Autoconf, как правило, работает только на Unix подобных системах. Поэтому если у вас Windows, то вам, скорее всего, придётся использовать средства эмуляции.
В итоге мы хотим получить 4 файла библиотеки с расширением .a по одной на каждую архитектуру процессора: armeabi-v7a, arm64-v8a, x86, x86-64.
Для каждой архитектуры нужно задать свои ENV-переменные. Общими будут только NDK, HOST_TAG и TOOLCHAIN. В Linux, ENV-переменную для текущей сессии терминала можно задать, используя команду export:
Однако заданные ENV-переменные будут существовать, пока активна текущая сессия терминала, и только в ней. Если вы откроете другую сессию, то там этих переменных не будет. Чтобы каждый раз не прописывать ENV-переменные заново, можно добавить их в конец файла .bashrc, который находится в домашнем каталоге (
). Перед запуском каждой сессии терминала запускается .bashrc. Поэтому переменные, объявленные в нём, будут существовать во всех сессиях терминала. Вот ENV-переменные, которые отличаются в зависимости от архитектуры:
Сначала скомпилируем под arm64-v8a, поэтому закомментируем в .bashrc объявление ENV-переменных для остальных архитектур. Стоит отметить, что в переменных CC и CXX есть цифра 21, которая очень похожа на Android API level. Так и есть, а если быть точнее, то это ваша minSdkVersion. В нашем примере это 21, но если у вас другие потребности, можете смело поменять. В NDK доступны версии с 16 по 29 для 32-разрядных ABI (armeabi-v7a и x86) и с 21 по 29 для 64-разрядных ABI (arm64-v8a и x86-64).
Итак, мы объявили ENV-переменные, которые определяют toolchain для компиляции под выбранную архитектуру, и выкачали репозиторий с исходниками Opus. Теперь открываем Readme в папке с исходниками Opus и видим, что для компиляции библиотеки надо всего-навсего запустить:
Но не всё так просто. Таким образом мы скомпилируем библиотеку под архитектуру нашей рабочей машины, а нам надо под 4 архитектуры мобильных девайсов.
В NDK с версии r19 «из коробки» идут toolchains. Как и показано в примере на странице, нужно выставить ENV-переменные (выставили их выше в .bashrc), соответствующие архитектуре, под которую компилируется библиотека. Затем нужно запустить команду configure с соответствующим аргументом host. Для arm64-v8a получается такое:
/.bashrc необходимо запускать, чтобы изменения переменных среды для сборки «подхватывались» текущей сессией терминала без перезапуска.
После выполнения всех вышеописанных команд, в папке с исходниками Opus появится папка .libs. В ней будут находиться все артефакты компиляции, в том числе и нужный нам libopus.a.
Далее в .bashrc комментим/раскомменчиваем, чтобы активными были ENV-переменные для armeabi-v7a, и прописываем команды уже с другим аргументом host:
./autogen.sh не выполняем, так как он нужен был только для первоначальной генерации конфигурационных файлов и того самого configure, который мы запускаем.
В этот раз команда make завершится ошибкой. Я долго не понимал, из-за чего так происходит. Поискав в интернете похожие проблемы, понял, что файлы и тесты, которые создаются для определённой архитектуры, во время компиляции не удаляются автоматически после переконфигурации на другую архитектуру (запуск configure с другим host). А так как в папке с исходниками, в которой появляются все артефакты сборки, и так много файлов, понять, какие из них надо удалять потом, очень сложно.
Решение оказалось довольно простым. Можно запускать все команды для конфигурации и компиляции, не находясь в папке с исходниками Opus. Тогда можно создать свою отдельную папку для каждой архитектуры, где будут все артефакты сборки и временные файлы для этой архитектуры.
Теперь всего-то нужно создать 4 папки и последовательно сделать одни и те же действия по выставлению ENV-переменных и прописыванию команд с нужным аргументом. Это слишком долго и скучно, поэтому есть отличная возможность написать bash-скрипт, который всё это сделает за нас. Вот такой небольшой скрипт получился:
Если использовать скрипт, то объявлять ENV-переменные в .bashrc нет необходимости, так как они объявлены в скрипте.
Чтобы использовать скрипт, нужно сделать его исполняемым:
Далее необходимо прописать путь к NDK на вашей машине и поменять HOST_TAG, если вы не на Linux (в скрипте значение linux-x86_64):
- 32-bit Windows: windows
- 64-bit Windows: windows-x86_64
- macOS: darwin-x86_64
Затем запускаем скрипт таким образом:
Ему нужно передать minSdkVersion и путь к папке с исходниками Opus. Опционально можно передать путь к папке, куда поместим артефакты сборки. По умолчанию создаётся папка opus_android_build в папке, где расположен скрипт buildOpus.sh.
Выполнение скрипта займёт некоторое время. Потом в папке opus_android_build или в той, которую вы передали, будут располагаться папки с названиями ABI, под которые была скомпилирована библиотека. Соответственно, внутри каждой папки будет уже знакомая нам папка .libs, в которой лежат все артефакты сборки.
Добавляем собранные библиотеки в проект
Отлично, у нас есть 4 файла libopus.a под разные архитектуры, самое сложное позади. Осталось добавить их в наш Android-проект и поправить CmakeLists.txt, чтобы к итоговой .so линковалась скомпилированная нами статическая библиотека Opus.
У нас есть папка app/src/main/cpp, в которой лежит наш C-враппер (jniopus.c), к которому идут external вызовы из Kotlin. В ней создаём папку includes. Затем в неё копируем содержимое папки include из исходников Opus. Там находятся файлы хедеров (.h). Они нам нужны для использования функции и структуры Opus в нашем C-враппере. Файлы хедеров содержат прототипы функций и являются своего рода контрактом, который определяет, какие аргументы может принимать и возвращать та или иная функция.
После этого в той же в папке app/src/main/cpp создадим папку libopus, а внутри неё 4 папки с названиями, идентичными названиям ABI, под которые мы скомпилировали библиотеку Opus: armeabi-v7a, arm64-v8a, x86, x86-64. В каждую из них помещаем файл libopus.a, скомпилированный под соответствующую архитектуру.
Далее модифицируем CmakeLists.txt, который был в предыдущей статье, где мы собирали Opus из исходников прямо в проекте. Сначала удаляем «простыню» со всеми путями к исходникам. Затем задаём переменные для путей:
Теперь добавляем Opus в сборку:
add_library используется для добавления библиотеки в сборку. Сначала идёт имя, которое у неё будет, далее тип библиотеки STATIC(.a) или SHARED(.so) и путь к исходникам, либо слово IMPORTED, если у нас уже собранная библиотека и мы хотим её использовать. В этом случае путь к готовым (импортируемым) библиотекам указывается ниже с помощью конструкции:
ANDROID_ABI это NDK toolchain аргумент, который сам туда подставит ABI.
Для компиляции нашего С-враппера, куда идут external вызовы из Kotlin, мы оставляем:
Также оставляем библиотеку, которая идёт «из коробки» в NDK для логирования таким образом:
И в конце мы объединяем всё это вместе:
Первым параметром идёт имя итоговой библиотеки, далее идут имена библиотек, которые нужно прилинковать к нашей. Вот и всё, теперь синхронизируем проект с помощью Gradle, нажимаем Run, и готово. Приложение открывается, жмём на кнопку Start call и говорим. Если тут же слышим то, что сказали, значит всё работает как надо.
Источник
