Как собрать/запустить dalvik
Исходники я каким-то чудом таки нашёл тут https://android.googlesource.com/platform (кстати они ли это?). А вот что делать с тем что я оттуда выкачал сильно неясно, мейкфайла нет, ридми нет, растительности нет, населена роботамиандроидами.
Гугл не помог. Есть где-то какое-нибудь руководство?
Собираешь прошивку, прошиваешь прошивку, запускаешь прошивку. Инфа 100%, гайдов — завались.
А тебе нужна виртуализация, еще на прошлой неделе выяснили же.
В том то и дело что мне нафиг не нужна прошивка/виртуализация. Мне нужен далвик, что б запустить его через quemu на арме на нём запустить apkшку и смотреть что отпадывает.
Во всяком случае это мне так сейчас это видится.
В том то и дело что мне нафиг не нужна прошивка/виртуализация. Мне нужен далвик, что б запустить его через quemu на арме на нём запустить apkшку
В том-то и дело, что нужна.
Отпадет все, починка — пара десятков тысяч человеко-часов.
Во всяком случае это мне так сейчас это видится.
Неправильно видится. Давай начнем с супербазового аргумента — если бы это было нужно и легко — ты бы уже сделал бы это с HOWTO на первой странице гугла по любому мало-мальски связному запросу.
Можешь обяснить для чего мне прошивка?
Отпадет все, починка — пара десятков тысяч человеко-часов
Неправильно видится. Давай начнем с супербазового аргумента — если бы это было нужно и легко — ты бы уже сделал бы это с HOWTO на первой странице гугла по любому мало-мальски связному запросу.
Ты так говоришь как будто при сборки прошивки далвик готовый из /dev/astral выкачается. Всё равно ведь происходит сборка.
Можешь обяснить для чего мне прошивка?
Чтобы запустить это на Android-девайсе и перестать тратить время.
Отпадет все, починка — пара десятков тысяч человеко-часов
Нет, только здравый смысл — откровенно глупо полагать, что Android-приложени зависят только от dalvik’а, а все остальное, что есть в системе, там тупо для красоты.
Ты так говоришь как будто при сборки прошивки далвик готовый из /dev/astral выкачается.
Нет, соберется. И даже сможет функционировать. Но только под Android-userland’ом. Его тоже надо собрать. А как соберешь — запускай виртуалочку или прошивай девайс.
Чтобы запустить это на Android-девайсе и перестать тратить время.
Моё время — хочу трачу. К тому же какой смысл мне запускать что-то на андроид-девайсе если цель запустить это вне андроид-девайса?
Нет, только здравый смысл — откровенно глупо полагать, что Android-приложени зависят только от dalvik’а, а все остальное, что есть в системе, там тупо для красоты.
Боюсь что всё остальное для вендрлока. Я же не собираюсь переписывать весь андроидовский рантайм, мне нужно понять что нужно и подсунуть библиотеки/воткнуть заглушки.
1) нафига эмулятором мучиться? Далвик и под х86 можно собрать.
2) Шукай файлик Android.mk это типа местный Makefile.
нафига эмулятором мучиться? Далвик и под х86 можно собрать.
Ну мне сейчас не принципиально, главное понять как.
Шукай файлик Android.mk это типа местный Makefile.
Угу, это я догадался. Проблема в том, что на http://android.mk/ он так подробно описан, что не осталось места что б описать чем его билдить.
Вот у меня есть у меня android.mk и андроидовкий СДК, а что дальше сижу голову ломаю.
SDK мало, нужен NDK!
Ну и билдят в NDK с помощью ndk-build.
Спасибо, теперь ясно чего не хватает.
Repo is a tool that makes it easier to work with Git in the context of Android.
Они что нарочно всё через задницу делают?
Тебе уже говорили, что ты полез в дебри. Я могу только присоединится к этому утверждению.
Теперь ты на личном опыте поймешь, что Android != Linux.
С радостью бы не лез, к сожалению за меня это сделать некому.
Мне нужен далвик, что б запустить его через quemu на арме на нём запустить apkшку
Поставь андроид в любую виртуалку (например обычный VB) и запускай что хочешь.
Чувак, это тяжело
В принципе, все это собирабельно. Тот же aapt я осиливал J4F собрать нативный 64х битный. Но 1) мейкфайл будешь писать сам; 2) если какого-нибудь говна будет не хватать – будешь искать его в андроидовских репах и собирать ещё и его.
Короче это сложно. Если нет опыта собирать софт из говна, палок и libastral – лучше забей.
Это для NDK. И можно без него, если обычный мейкфайл руками запилить.
Ну вот и появится опыт.
Я так понял что на основе android.mk можно мейк файл состряпать. Если ты такое уже делал, можешь примерчиком поделиться? В смысле оригинальный mk и мейкфайл под него.
У цианогена свои репы или они тоже аосповские пользуют?
Именно так и надо сделать. Есть. Genymotion специально для быстрой (x86) разработки. Для тех кто не торопиться эмулятор псевдо ARM входит в состав SDK.
Dalvik вынули из Android давно — Alien Dalvik. Потратив на это те самые тысячи человекочасов.
Гугли еще Android ART. Если уж решил убить год на сборку чего-то, будь в тренде.
Можно написать Activity почти на голом C++. Поведение Java прослойки тоже важно, но поток событий, холст/контекст EGL можно обработать и без Java.
«Запускать и смотреть что отваливвется» я бы начал с определения цели.
Dalvik вынули из Android давно — Alien Dalvik
Да мало ли, скайп из стартового поста или например опера или какой нить ватсап.
Я слышал про него, но казалось там нужно специально пересобирать приложения. Оказывается нет, фигасе, скайп и опера могут быть запущены через эту штуку не на арме? Вот это интересно.
Java код переносим. Нативные либы можно скомпилировать для всех архитектур и включить в apk, в ущерб его размеру. На Маркет обычно срабатывает автоматическое определение архитектуры и тот же Skype скачается только с либами под неё.
На x86 полно устройств. Intel их даже субсидировал. У меня одно даже на MIPS.
Да кстати, вспомнил: akp в Chrome . Способ не для всех apk.
libhybris тебе, наверное, нужен и прочие куски от mer project. Ты хочешь что-то типа alien davlik замутить? Но его, вроде бы, целая команда разработчиков долго долго пилила. Гугл как-то сделал оригинальный рантайм андроида непортабельным, хоть там и java.
Но его, вроде бы, целая команда разработчиков долго долго пилила.
Подозреваю что большая часть времени ушла на написание осиливание сборки.
Мне то не нужна возможность запускать всё подряд. Мне пары приложений хватит, а значит надо просто заткнуть те вызовы которые этим приложениям нужны.
фигасе, скайп и опера могут быть запущены через эту штуку не на арме? Вот это интересно.
ART это замена Dalvik’а, и на вход принимает байт-код Dalvik’а, а не платформо-зависимые бинарники.
Но вообще-то, портировать приложения с native-компонентами тоже возможно: plasma^W opera не падает
Подозреваю что большая часть времени ушла на написание осиливание сборки
Ты понимаешь, что android != desktop Linux? Там даже ведро передлопачено довольно заметно, а юзерспейс вообще на других принципах построен. Начиная хотя-бы с того, что в ведроиде нету даже libc — зкаместо неё там bionic крутится. То, что ты хлчкшь сделать, сравнимо с запуском elf-бинариков с линукса род маком. Без знаний ты ничего не сделаешь. А знаний у тебя нету, это сразу видно.
Источник
Android изнутри: сравнение Dalvik и ART
Привет, Хабр! Около полугода назад я публиковал подробный «гайд» по JVM. Пост, в целом, зашел, а в комментариях спросили, не планируется ли “чего-то по андроиду”. Наконец, у меня дошли руки.
В этом посте поговорим о среде выполнения в Android. В частности, я постараюсь кратко, но емко изложить, чем отличается ART и Dalvik, и как со временем улучшились средства разработки в Android. Тема явно не новая, но, надеюсь, придется кстати тем, кто только начинает вникать. Кому интересно — добро пожаловать под кат.
Виртуальная машина
Сначала, давайте разберемся чем отличается JVM от DVM.
Java Virtual Machine — виртуальная машина, способная выполнять байт-код Java независимо от базовой платформы. Она опирается на принцип “Write once, run anywhere”. Байт-код Java может быть запущен на любой машине, способной поддерживать JVM.
Компилятор Java преобразует .java файлы в class-файлы (байт-код). Байт-код передается JVM, который компилирует его в машинный код для исполнения непосредственно на CPU.
- Имеет стековую архитектуру: в качестве структуры данных, куда помещаются и хранятся методы, используется стек. Он работает по схеме LIFO или “Last in — First Out” или “Последним вошел, первым вышел”.
- Может запускать только class-файлы.
- Использует JIT-компилятор.
Dalvik Virtual Machine (DVM) — виртуальная Java машина, разработанная и написанная Дэном Борнштейном (англ. Dan Bornstein) и другими, как часть мобильной платформы Android.
Можно сказать, что Dalvik — это среда для выполнения компонентов операционной системы Android и пользовательских приложений. Каждый процесс выполняется в своём, изолированном адресном пространстве. Когда пользователь запускает приложение (либо операционная система запускает один из своих компонентов), ядро виртуальной машины Dalvik (Zygote Dalvik VM) создает отдельный, защищенный процесс в общей памяти, в котором непосредственно разворачивается VM, как среда для запуска приложения. Другими словами, изнутри Android выглядит как набор виртуальных машин Dalvik, в каждой из которых исполняется приложение.
- Использует архитектуру на основе регистров: структура данных, куда помещаются методы, основана на регистрах процессора. За счет отсутствия операций POP и PUSH, команды в регистровой виртуальной машине выполняются быстрее аналогичных команд стековой виртуальной машины.
- Исполняет байт-код собственного формата: Android dexer (о нем поговорим ниже) преобразует class-файлы в формат .dex, оптимизированные для выполнения на Dalvik VM. В отличие от class-файла, dex-файл содержит сразу несколько классов.
Подробно об архитектуре DVM можно почитать тут.
Android Dexer
Разработчики Android знают, что процесс преобразования Java байткода в .dex байткод для Android Runtime является ключевым шагом в создании APK. Компилятор dex в основном работает “под капотом” в повседневной разработке приложений, но он напрямую влияет на время сборки приложения, на размер файла .dex и производительность во время выполнения.
Как уже упоминалось, сам dex-файл содержит сразу несколько классов. Повторяющиеся строки и другие константы, используемые в нескольких файлах классов, включаются только для экономии места. Байт-код Java также преобразуется в альтернативный набор команд, используемый DVM. Несжатый dex-файл обычно на несколько процентов меньше по размеру, чем сжатый архив Java (JAR), полученный из тех же файлов .class.
Изначально, class-файлы преобразовывались в dex-файлы с помощью встроенного DX-компилятора. Но начиная с Android Studio 3.1 и далее, компилятором по умолчанию стал D8. По сравнению с DX-компилятором, D8 компилирует быстрее и выводит dex-файлы меньшие по размеру, при этом обеспечивая более высокую производительность приложения во время исполнения. Полученный таким образом байт-код dex подвергается минификации с помощью open-source утилиты ProGuard. В итоге, мы получаем тот же dex-файл, но только меньше. Далее этот dex-файл используется для сборки apk и, наконец, для развертывания на устройстве Android.
Но следом за D8 в 2018 году пришел R8, который, по сути, является тем же D8, только с дополнениями.
При работе с Android Studio 3.4 и Android Gradle 3.4.0 plugin или выше, Proguard больше не используется для оптимизации кода во время компиляции. Вместо этого плагин работает по умолчанию с R8, который сам выполняет Code shrinking, Optimisation и Obfuscation. Хотя R8 предлагает только подмножество функций, предоставляемых Proguard, он позволяет совершить процесс преобразования Java байт-кода в dex-байт-код единоразово, что еще больше сокращает время сборки.
R8 и сокращение кода
Как правило, приложения используют сторонние библиотеки, такие как Jetpack, Gson, Google Play Services. Когда мы используем одну из этих библиотек, часто в приложении используется только малая часть каждой отдельной библиотеки. Без Code shrinking, весь код библиотеки сохраняется в вашем приложении.
Бывает так, что для улучшения читаемости и удобства поддержки приложения разработчики используют подробный код. Например, могут быть использованы значимые имена переменных и шаблон проектирования для того, чтобы другим было удобнее разобраться в коде. Но шаблоны, как правило, приводят к бОльшему объему кода, чем это необходимо.
В этом случае R8 приходит на помощь. Он позволяет существенно уменьшить размер приложения, оптимизируя размер даже того кода, который действительно используется приложением.
В качестве примера, ниже преведены цифры из доклада Shrinking Your App with R8, который был представлен на Android Dev Summit ’19:
А вот так выглядело сравнение эффективности R8 на этапе выпуска бета-версии (взято из источника Android Developers Blog):
Детальнее можно ознакомиться в оф документации и докладе.
ART vs DVM в Android
DVM была спроектирована именно для мобильных устройств и использовалась как виртуальная
машина для запуска андроид приложений вплоть до Android 4.4 Kitkat.
Начиная с этой версии, ART был представлен как среда выполнения, а в Android 5.0 (Lollipop) ART полностью заменил Dalvik.
Основное явное отличие ART от DVM состоит в том, что ART использует AOT компиляцию, а DVM — JIT компиляцию. Не так давно ART начал использовать гибрид AOT и JIT. Далее разберем это чуть подробнее.
- Использует JIT компиляцию: всякий раз при запуске приложения,
- компилируется та часть кода, которая необходима для выполнения приложения. Остальная часть кода компилируется динамически. Это замедляет запуск и работу приложений, но уменьшает время установки.
- Ускоряет загрузку устройства, поскольку кеш приложения создается во время выполнения.
- Приложения, работающие на DVM, требуют меньше памяти, чем те, которые работают на ART.
- Уменьшает резерв батареи, увеличивая нагрузку на CPU.
- Dalvik является “устаревшим” и не используется на андроид версиях выше 4.4.
- Использует AOT компиляцию, то есть компилирует весь код во время установки приложения. Это ускоряет запуск и работу приложений, но требует большего времени установки.
- Замедляет загрузку устройства, так как кеш создается во время первой загрузки.
- Ввиду использования подхода AOT компиляции, требует больше памяти в сравнении с приложениями на DVM.
- Увеличивает резерв батареи, сокращая работу процессора из-за отсутствия компиляции при выполнении приложений.
- Улучшенная Garbage Collection или сборка мусора. Во времена использования Dalvik, сборщики мусора должны были осуществить 2 прохода по куче (heap), что и приводило к плохому UX. В случае с ART, такой ситуации нет: он чистит кучу один раз для консолидации памяти.
И небольшая схема Dalvik vs ART:
JIT + AOT в ART
Среда выполнения Android (ART), начиная с Android 7, включает компилятор JIT с профилированием кода. JIT-компилятор дополняет AOT компилятор и повышает производительность во время выполнения, экономит место на диске и ускоряет обновления приложений и системы.
Происходит это по следующей схеме:
Вместо того, чтобы запускать AOT-компиляцию каждого приложения на этапе установки, он запускает приложение под управлением виртуальной машины, используя JIT-компилятор (почти так же, как в Android
Источник
