Huawei выпустила полноценную замену Android для своих смартфонов. Видео
Huawei начала распространение своей собственной ОС для смартфонов Harmony OS 2.0, которую она показала еще в сентябре 2020 г. Уже сегодня ее можно установить на целый ряд смартфонов компании и на один планшет, и в ней есть привычный многим интерфейс EMUI, обновления «по воздуху» и поддержка Android-приложений.
Китайская альтернатива Android
Компания Huawei выпустила операционную систему Harmony OS 2.0 для своих смартфонов, работающих под управлением ОС Android. Она, пишет ресурс GizChina, пока доступна лишь в бета-версии, но ее могут установить на свои гаджеты не только бета-тестеры, но и обычные пользователи.
Прямо сейчас установить Harmony OS 2.0 на свой смартфон могут владельцы моделей Huawei P40, P40 Pro, Mate 30 и Mate 30 Pro, сроки реализации поддержки других телефонов компании пока неизвестны. Также есть версия для планшета MatePad Pro, но существуют некоторые ограничения – оценить новую ОС могут пока лишь только жители Китая.
Для получения прошивки нужно обратиться к Huawei с соответствующим запросом и дождаться его одобрения. После этого она будет доступна для установки.
Дебют Harmony OS 2.0 состоялся в сентябре 2020 г. Тогда же Huawei заявила, что первые устройства на ее основе появятся в декабре 2020 г., то есть свое слово она сдержала.
Как выглядит и что умеет новая ОС
Huawei предоставила пользователям возможность максимально быстро адаптироваться к Harmony OS, разработав ее интерфейс на базе собственной оболочки EMUI 11 для Android. За счет этого владельцы ее смартфонов могут даже не заметить разницы между внешним видом этих ОС – настолько они похожи.
Поскольку до релиза первой стабильной версии Harmony OS еще остается некоторое время, разработчики приложений пока не торопятся переносить на нее свое ПО. Для решения этой проблемы Huawei прибегла к интеграции в нее поддержки приложений, написанных для Android, что позволяет пользоваться привычным софтом. Поддержки сервисов Google в Harmony OS нет, но у Huawei давно есть собственный их аналог – Huawei Mobile Services (HMS).
Система поддерживает обновления «по воздуху» (OTA, on the air), как и современные смартфоны крупных производителей. Это означает, что для установки новой версии ПО для смартфона не нужно будет вручную скачивать дистрибутив и устанавливать его через спецсофт для ПК – прошивка скачает и распакует архив самостоятельно.
Редакция CNews поинтересовалась у российской компании «Открытая мобильная платформа» (ОМП), разработчика мобильной ОС «Аврора», можно ли считать Harmony OS равноценной заменой Android. Директор департамента ОМП Роман Аляутдин отметил: «Пока рано говорить нет ли в ней заимствований от проекта AOSP, например в части функционала выполнения Android приложений, который заявлен; осенью Huawei публиковал в открытый доступ компоненты Harmony, но только для устройств вроде фитнес-трекеров. Возможно, после сегодняшнего события, будет обновление». «Опубликованное демо с точки зрения внешнего интерфейса похоже на Android сборки Huawei», – добавил он.
На вопрос о возможности использования Harmony OS, в которой, в отличие от Android, нет американского кода будет использоваться российскими госкомпаниями вместо отечественных мобильных ОС, Роман Аляутдин ответил: «В Android есть код представителей всего мира, в том числе России, хотя бы потому, что он основан на ядре Linux. Полагаться на цифровые продукты можно только при наличии своих базисных технологий, разработок и экспертизы в ОС, микроэлектронике и ПО для инфраструктуры».
Когда ждать
Сроки появления стабильной версии Harmony OS Huawei не уточняет. По предварительной информации, первым смартфоном на базе новой операционки станет P50, а Huawei, как известно, выпускает новые смартфоны Р-серии в начале весны каждого года. Остальные смартфоны Huawei, вероятно, начнут обновляться в течение 2021 г.
Что касается мобильников Honor, то вероятность появления на них Harmony OS пока что околонулевая. В ноябре 2020 г. Huawei под давлением президента США Дональда Трампа (Donald Trump) вынужденно продала свой дочерний бренд и больше не будет иметь к нему никакого отношения.
Не исключено, что со временем на гаджеты Honor вернутся и сервисы Google, которые Huawei не имеет права устанавливать на свои устройства. Но подтверждений этому в настоящее время нет.
Откуда у Huawei своя операционка
Впервые о планах Huawei по выпуску собственной мобильной ОС стало известно еще в 2011 г., но ее разработка затянулась на восемь лет. Толчком к ее завершению и выпуску Harmony OS первого поколения стало сильное давление на Huawei со стороны американского правительства – компания стала мишенью для Дональда Трампа и рычагом давления на власти КНР в рамках торговой войны между Китаем и США.
В мае 2019 г., Трамп выпустил ряд указов, в которых он запрещал американским ИТ-компаниям сотрудничать с Huawei. Google была в числе первых, кто подчинился приказу президента, и Huawei лишилась возможности устанавливать на Android сервисы Google – YouTube, Gmail и др., даже магазин приложений Google Play. Это и подтолкнуло ее к наращиванию темпов разработки собственной программной платформы, у которой с декабря 2019 г. есть собственные сервисы Huawei Mobile Services – в их состав входит фирменный магазин ПО AppGallery, доступный, в том числе, и в России.
Harmony OS первого поколения была представлена в августе 2019 г. – изначально она создавалась для смарт-ТВ, автомобильных головных устройств и ряда других гаджетов. В планы Huawei входила установка ее и на смартфоны, но точных сроков она не называла, и основной целью для нее она не была. Harmony OS 2.0 пришла ей на замену и сразу получила отдельную модификацию для смартфонов.
Источник
Другая операционная система вместо андроид
Замена 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
Источник
