4pda как поменять андроид
Замена Android на десктопный дистрибутив
. Просто у него были свои идеи о том, как должен выглядеть мир, и он был достаточно могущественным, чтобы попытаться осуществить их.
Интересно, пытался ли кто-нибудь, кроме меня, полностью избавиться от андроида на своём устройстве и развернуть нормальный дистрибутив.
Если такие люди существуют, то, возможно, они захотят обсудить результаты, обменяться наработками или похвалиться достижениями.
Наверняка, кто-то спросит «Нафиг надо?». Да, почти любая десктопная линуксовская программа уже имеет аналоги под андроид. Но, возможно, кому-то андроид просто не по душе. Или, может, кто-то хочет писать узкоспециализированные программы для своего устройства и писать их не на Java.
Тут можно задать вопросы (или оставить инструкции) на следующие темы:
— Пересборка ядра с новым конфигом или драйверами;
— Работа с рамдиском;
— HAL библиотеки и libhybris;
— Настройка Wi-Fi, 3g;
— Настройка и запуск X сервера;
— Выбор оконного менеджера, окружения, виртуальной клавиатуры;
— Вывод звука;
— Разработка программ, заменяющих функционал андроида: управление подсветкой, частотой процессора, громкостью, лампочками, звонки, сообщения, гибернация;
— Использование камеры, датчиков.
Если кому-то интересно, но не знаете, с чего начать, можете заглянуть вот сюда:
Замена Android на десктопный дистрибутив (Пост Pigg #48927960)
Сообщение отредактировал ottiwell — 15.06.18, 23:22
#Активируем вибрацию на N миллисекунд
echo N> /sys/devices/virtual/timed_output/vibrator/enable
#Включить фонарик
echo 1 > /sys/devices/platform/flashlight/leds/flashlight/brightness
#Изменить яркость. Пути в разных прошивках отличаются.
echo 50 > /sys/class/backlight/pwm-backlight/brightness
Сообщение отредактировал ottiwell — 30.07.16, 20:13
Azathtot,
1. Пересборка ядра особо не нужна, Pigg просто не очень любит Android как систему и в своем устройстве постарался максимально привести ядро к нормальному (ванильному) виду с созранением работоспособности.
2. Можно обойтись и без chroot, использовать обычный systemv или busybox init.
3. Здесь вроде как тоже уже freeadreno (для Adreno) и libhybris. Если заведутся конечно на отдельных устройствах.
А утилиты, заменяющие функции андроида нужны для более-менее комфортного пользования устройством.
/Downloads/pppd-mod /system/xbin/pppd-mod
chmod 777 /system/xbin/pppd-mod
Сообщение отредактировал ottiwell — 07.04.16, 18:09
Похоже теперь я могу подключаться напрямую из recovery к своему WiFi-ю, пока не допилил xorg.
Сообщение отредактировал ottiwell — 08.04.16, 17:30
Ребят, только не ругайтесь. Я одно не понимаю — зачем?! 🙂
гугль запустил андроид. Внешне с разворотом якобы поболее к пользователю. Мол, как бы в открытость. А, по-сути, верно свои силы и возможности оценил, как недостаточные для разработки собственного ядра с нуля. А элементы все стандартные. Всё, что принципиально — закрыто. Эдакая хитровыделанность от гугл. Вы пытаетесь взломать андроид, точнее изготовителей железа? Со всеми их патентами, лицензиями и армиями юристов. Зачем? Это же их главный интерес — техническое решение конкретного аппаратного элемента и программа его управления. Миллионы людей противодействуют вам — ровно в обратном направлении тому, что вы хотите сделать.
То, что вы здесь пытаетесь решить, очевидно — мне ) , надо совсем иначе делать:
Подбираете оборудование такое, на котором правильно работает дистрибутив GNU/Linux. Это вариант условно обычного настольного компьютера. Есть варианты и открытого оборудования. Пока, конечно, слабенькие.
Если принципиально железо — то ориентироваться лучше, например, на подобные проекты Yocto Project и DragonBoard™ 410c. Похожих с большей или меньшей степенью открытости уже довольно много.
В крайнем случае — прикинул сейчас — поправьте, если ошибаюсь — вам надо брать исходные тексты twrp — по-сути, открывашки андроида. Благо twrp открыта. Ядра twrp, естественно, можно настраивать, как угодно. Всё для базы построения собственного GNU/Linux дистрибутива для андроид устройства в ней есть, включая нормальный буфер кадров «из коробки». По крайней мере — так должно быть в ней. Далее уже, если очень сильно нужно — на чистой и ясной системе можно всякую разную графику пытаться привязывать.
С этим главная проблема. Денег нет, поэтому приходится работать с тем, что есть.
А сорцов twrp под мой девайс нет 🙁 И к тому же кадровый буффер работает, не работает аппаратное ускорение.
Сообщение отредактировал ottiwell — 20.07.16, 01:42
Это я слегка неточно высказался. Вряд ли кто-то будет спорить, что главное препятствие сейчас — быстродействие в графической части. Понятно, что там, где отдельно нарочно не сломали фрэймбуфер в каноническом понимании, он будет работать. Но, если мои знания по теме не устарели — нет сейчас ни одного открытого набора родных полноценных программ управления графической частью для современных, условно андроид устройств, как вариант — графики их систем на чипе. То есть все подобные доступные программы, которыми можно воспользоваться сейчас — приближения в том или ином виде и не обеспечивают полную оптимизацию по железу. Грубо говоря — «костыли». А на них, как ни разгоняйся — далеко не убежишь.
Понятно. Но вобще-то платы разработчика часто стоят вполне адекватно. Цены не высокие, разумные. Работа с такой платой — это принципиально более высокоблагородный 🙂 подход. Академически верный. Может быть, практически, конечно, менее подходящий. Идейно ) я с вами, но лично для меня в принципе противно «лить воду на мельницу» гугла и прочих, примкнувших к нему. Ну хотят они там узакрываться со своей графикой — пусть живут в своём мирке. Чего на них время тратить.
Вот для случая андроида и twrp действительно тогда надо выбирать конкретное устройство, для которого есть открытый код twrp. Когда я написал — >всякую разную графику пытаться привязывать — подразумевал, в чистую работающую систему, в которой, естественно, работает вывод графики через фб — далее пытаться интегрировать программы управления графикой специализированные по аппаратуре, чтобы получать то же аппаратное ускорение. Хотя, я этот термин недолюбливаю. Нет никакого аппаратного ускорения. Есть штатная работа с максимально возможным быстродействием кода точно и максимально соответствующего запроектированным характеристикам условно микросхемы.
Сообщение отредактировал Den4PDA — 15.04.16, 21:49
Серъёзно? Я без какой-либо подковыки. Мне не нравится андроид. И не особо в нём разбираюсь. Недавно простаки ) заставил себя купить андроид устройство после длительного перерыва. Приходится вспоминать неспеша, что здесь теперь.
Вот, допустим, в моём 1+Х в SoC Qualcomm : GPU — Adreno 330. Вы можете привести ссылку на исходные тексты для самостоятельной сборки программы управления выводом графики на данном устройстве?
Сообщение отредактировал Den4PDA — 15.04.16, 23:16
Да. Я об этом же.
Проблема начинается не здесь. На мой взгляд. Зачем нам в принципе упоминать некие специфичные андроиду элементы, типа bionic, если рассматриваем замену андроида на GNU/Linux.
Если бы в ядро можно было устанавливать не некий блоб, а модуль на основании открытого кода и документации, то вся лавино-нарастающая каша из мешанины слоёв поддержки не требовалась. Здесь даже не учитываем, что в этом блобе элементы могут выполнять и посторонние задачи. Без разницы — если железо закрытое, понятно, что их выполнение можно перенести на уровень микрокода и условно ниже ) . Логика же такая: есть своя программа управления — нет зависимости от bionic, нет зависимости от bionic — не требуется прослойка обеспечения совместимости в виде libhybris. Или: документация открыта — есть своя программа управления устройством. Есть программа управления — не требуется осуществлять обратную разработку для получения какого-нибудь freedreno. Такие программы вобщем-то не являются полноценными, надёжными, эффективными в общем смысле. То есть при правильном подходе — не возникает ситуации, когда вынуждены решать проблемы определяемые изначально неверной основой.
Это интересно. И, наверное, здорово. Но. из другой области по отношению к моему подходу к теме.
Вот эту часть можно отдельно долго рассматривать, но в принципе здесь всё ясно. Лично я против 🙂 . Всё по прежней схеме — да, молодцы, конечно — ибо, как-то надо же решать. Но сначала, по-сути, придумываем себе проблему, потом героически её решаем. К счастью, здесь не всё так печально — если поискать, скорее всего, найду пару-тройку примеров, когда тесты показывали лучшее быстродействие, чем в оригинале.
Спасибо — напомнили про nvidia. Лучше, чем ничего.
Вобщем, извините, что слегка влез в тему. Микрокомпьютер точно, однозначно программируемый на основании полной документации — это одно, а преобразование андродид телефона какого-нибудь путём ухищрений и комбинаций определёнными инструментами просто потому, что сейчас есть именно такие — ситуация, конечно, другая.
Подробной инструкции нету и вряд ли будет. Только приблизительный общий план:
1. Поработать, к примеру, с LinuxDeploy. Это программа для установки дистрибутивов в папку или в образ и запуска программ в chroot. Обязательно добиться работы через framebuffer. По проблемам можно спросить в теме LD.
2. Научиться пользоваться adb. Научиться монтировать образ LD и запускать xorg без помощи LD, через adb shell. Это не сложно. Там 5-6 команд, которые легко объединить в скрипт. Если не получится, спрашивайте тут. пример монтирования
3. Научиться извлекать, редактировать и закачивать обратно рамдиск. На тех устройствах, что я видел, рамдиск с ядром обычно сшиты в один файл и вместе прошиваются в устройство. Чаще, всего это boot.img или recovery.img, но бывают и другие варианты. Извлекать их из мобилы не обязательно — можно просто взять тот, что вы прошивали. На XDA-Developers есть всякие программы для разделения таких файлов и распаковки/упаковки рамдиска. Вот тут утилиты, которые использовал я, и краткая инструкция. Скорее всего, подойдут они далеко не всем.
4. Когда рамдиск распакуется в папку, в нем должны быть, как минимум, файлы init и init.rc. Когда ядро загружается, оно тоже распаковывает рамдиск в / и /init становится первой юзерспейс программой, которая выполняется.
Чаще всего /init — это андроидовский бинарник. Он читает и выполняет /init.rc. В init.rc указано, какие команды выполнить на ранних стадиях загрузки, какие команды выполнить на поздних стадиях, какие запустить сервисы итп. Так же /init может быть и sh скриптом, что весьма полезно.
В десктопных дистрибутивах обычно используется другая система инициализации: systemd, например. Но новичкам я пока предлагаю остаться на андроидовской init. Она и по ресурсам легче, и не придется каждую строчку длинющих init.rc скриптов портировать под systemd. Ну там реально нужна только каждая 10-я строчка, конечно, но все-равно для начала лучше оставить андроидовский init.
5. Теперь вы можете редактировать init.rc и закачивать обратно в устройство? Хорошо.
Самое интересное в init.rc — это блоки service типа:
Эти блоки описывают программы, которые init запускает при тех или иных условиях. Класс — это что-то типа группы. Все сервисы одной группы можно потом запустить одной командой типа class_start main.
disabled — означает, что данный конкретный сервис не будет запускаться, когда вызывается class_start для его группы. Но его все-равно можно запустить в любой момент инициализации как-то типа start bootanim.
oneshot означает, что программа выполняется один раз и не будет перезапускаться, если завершится или помрет. Если oneshot нету, то да, будет перезапускаться.
Больше информации по init.rc тут:
https://android.google…master/init/readme.txt
Скорее всего, у вас в init.rc есть блоки типа «on early-init», «on init», «on fs». Это что-то типа событий. Когда событие наступает, выполняются команды из блока. У меня в «on init» после кучи команд сомнительной полезности была команда class_start main. Понимать это надо как-то так: когда наступает init (наступает оно весьма рано в процессе инициализации, но точный порядок не знаю), выполняются все те команды и запускаются сервисы класса main.
Есть еще события типа «on property:ro.debuggable=1». Они вызываются, когда меняется какая-то проперти. Менять их может андроид и пользователь андроидовской программой setprop. Удобно, если надо запускать/останавливать/перезапускать сервисы без редактирования рамдиска и без перезапуска устройства.
6. Первое, что лично я сделал, — это так, чтоб adb запускалось прямо сразу и с рут-правами. По-умолчанию, оно вполне может запускаться не от рута. А потом уже андроид переключает режимы adb с помощью property. Я это всё удалил и оставил по adb только то, что было в init.rc рекавери. Кстати да, в рекавери свой совсем другой и более короткий init.rc — обязательно загляните. Можно даже с него начать — там намного меньше понимать надо.
7. Если adb работает сразу и с правами рута, теперь можно отключить самые ненавистные части андроида. Отключить сервис легко — можно его просто закомментировать в init.rc, добавив символ # в начало каждой строчки. Отключаем surfaceflinger, zygote, bootanim итд. итп. Точный список нужных и не нужных сервисов дать не могу при всём желании — зависит от устойства. Но zygote и surfaceflinger точно надо отключать.
После успешного завершения этого пункта андроид уже не должен грузиться, но adb shell должно работать. Ну и всё остальное должно работать (вай фак, звук итп), если ничего лишнего не отключили.
8. Ну а вот теперь можно попробовать через adb shell смонтировать образ LD* и запустить xorg. Вы же не пропустили пункт 2? 🙂
Если получится, можно создать скрипт и добавить его в init.rc.
Да, ну вот с чего-то такого типа нужно начинать. Не очень удобно заново сшивать boot.img и прошивать его в телефон после каждого изменения рамдиска, да? Но тут вспоминаем, что /init не обязан быть сразу тем андроидовским инитом. И тут уже ваша фантазия не ограничена. Можно вставить скрипт, который будет монтировать карту памяти и обновлять с неё init.rc.
А можно разом избавиться от всех проблем и заодно от chroot, но это не очень просто:
1. Распаковываем рамдиск и копируем его в корень образа LD.
2. Можно сразу скопировать туда и андроидовские /system, /data. Папки нормального дистрибутива можно временно переименовать, чтоб не было конфликтов имен папок и файлов.
3. В том init.rc, что уже в образе, нужно закомментировать строки, монтирующие /system, /data, /cache. Незачем их монтировать уже.
4. А потом в рамдиск (тот, что в boot.img) пишем свой собственный скрипт /init и добавляем статический busybox. Этот скрипт должен создать ноды нужных ему устройств. Смонтировать образ LD, где бы тот ни лежал. А потом «передать ему управление» (busybox switch_root). После этой команды образ навсегда монтируется в /, а рамдиск демонтируется. И выполняется уже /init и init.rc, лажащие в образе.
Смысл этого всего в том, что после этого не нужно больше будет перепрошивать boot.img. Если нужно отредактировать init.rc, то это запросто можно сделать через adb shell или из уже работающего дистрибутива (sudo nano /init.rc). Ну и заодно можно, например, красивый дуалбут сделать.
Дальше пока писать не буду. Но если вдруг хоть один человек дойдет до запуска xorg из init.rc, то можно будет продолжить обсуждение. Работающий xorg — это круто. И даже большинство устройств будут работать. Но надо же сделать, чтоб устройство было реально использовать, а не только хвалиться друзьям. Нужно управление питанием, звонилка, подключение интернета итп.
Гарантирую, что ни один из пунктов не обойдется без дополнительных проблем, не описанных тут. Если у Вас нету свободных МЕСЯЦЕВ, забейте.
*Под «образ LD» подразумевался образ или папка с файловой системой десктопного дистрибутива. Разумеется, не обязательно создавать его именно в LinuxDeploy.
Сообщение отредактировал Pigg — 07.12.16, 18:31
Источник
