In fastboot we trust. Part 3

Сборка прошивки для LG G3s(jag3gds):

• Скачиваем исходники основной прошивки:
  $ repo init -u https://github.com/LineageOS/android.git -b cm-14.1
• Обновляем исходники:
  $ repo sync -j 4
• Обновляем переменные окружения:
  $ . build/envsetup.sh
• Подготавливаем специфичные для устройства каталоги:
  $ breakfast jag3gds
• Дописываем project name="TheMuppets/proprietary_vendor_lge" path="vendor/lge" remote="github" в .repo/local_manifests/roomservice.xml для добавления блобов
• Запускаем сборку:
  $ brunch jag3gds

In fastboot we trust. Part 2

Некоторые устройства содержат нестандартные протоколы загрузки или неполные реализации стандартных протоколов. В случае LG G3s(jag3gds) мы имеем 4 способа загрузки:

• стандартный загрузочный сектор(boot), загружается при обычном нажатии кнопки Power;
• загрузчик для стандартной системы обновления прошивки(laf), поддерживает только стандартный протокол LG для установки прошивок, для входа нужно выключить телефон подождать с десяток секунд, нажать Volume UP и подключить usb или adb reboot bootloader;
• если стереть laf то aboot не найдя laf входит в режим fastboot, реализовано только часть протокола - можно только отформатировать разделы или перегрузить телефон(поддержки команды boot нет);
• раздел с recovery - загрузиться можно только с основного раздела через adb reboot recovery.

Решением могло бы быть реализация fastboot или использование uboot. Но можно использовать наработки efidroid минимальный lk образ содержит поддержку fastboot. Для сборки можно использовать такую последовательность команд:

• $ source build/envsetup.sh
• $ lunch
• # select Device name == lge/jag3gds and build type == debug
• $ make -j6 lk
• $ adb push out/device/lge/jag3gds/lk.img /sdcard/Download/lk.img
• $ adb root
• $ adb shell
• # dd if=/sdcard/Download/lk.img of=/dev/block/platform/msm_sdcc.1/by-name/laf
• # exit
• $ adb reboot bootloader # boot to laf

Если хочется использовать полный образ нужно заменить lk на uefi.

В текущей реализации в uefi образе содержится ошибка и нужно применить такое исправление в uefiapi/target/msm8226.c заменить:

pdata = cb(pdata, MSM_IOMAP_BASE, (MSM_IOMAP_END - MSM_IOMAP_BASE), LKAPI_MMAP_RANGEFLAG_RESERVED, 

на:

pdata = cb(pdata, MSM_IOMAP_BASE, 1*MB, LKAPI_MMAP_RANGEFLAG_RESERVED,.

In fastboot we trust. Part 1

Или обновление ядра android на официальное ядро с kernel.org

Все современные ядра для android, хоть и до сих пор базируются на 3.4, но все же перешли на device tree, поэтому напрямую использовать их на старых устройствах(до 2011 года) скорее всего не получиться, так как они рассчитаны на загрузку используя atags, поддержку которого благополучно сломали в процессе обновления, есть ещё и вторая потенциальная проблема, на мобильных телефонах размер подобных atags может быть очень большой, для примера там может быть прошивка для Wi-Fi и калибровка для камеры и получается размер под 64 килобайта. Если немного пройтись по тому как оно работает получается такое поведение: в идеале на новых загрузчиках ядру передается как один из параметров ссылка на devicetree, который представляет собой упакованное дерево с описанием устройств и их настроек доступных на аппаратном уровне, каждый узел подобного дерева содержит список совместимости, где перечислен список типов устройство потенциально совместимых с доступными на аппаратном уровне, для примера может быть указано что мы имеем какой-то телефон или платформу и указано что также у нас система базирующаяся на каком-то чипе, если ядро не в курсе нашей платформы оно может попытаться задействовать код поддержки от чипа, этого должно быть достаточно для поддержки 99 процентов устройств, так как все устройства внутри soc обычно совпадают для того же процессора, а отличие только в описании и настройке линий ввода/вывода. Данная технология изначально была придумана для power и используется широко на данный момент в официальном ядре для реализации поддержку различных платформ одним ядром одновременно, как следствие можно загрузиться на одном ядре Qualcomm msm и Samsung Exynos устройство сообщив ему путь к device tree.

В случае atags все немного попроще и не так универсально, а теги представляют собой список структур в каждой такой структуре есть длина этой записи и ее тип, последняя структура содержит все поля с нулями. Значения численные значения типов частично стандартизированы и каждый производитель волен их дополнять как ему удобно. В качестве стандартных обычно выступают размер памяти и размер initrd образа.

Новый загрузчик под android понимает образы которые содержат 3 секции: само ядро, device tree, initrd. Старые загрузчики игнорируют DT секцию и для того чтобы можно было загрузиться ядру с поддержкой DT, придуманы такие обходные маневры: в конец образа ядра записывается DT и в ядре выбирается опция, что нужно искать DT после образа ядра и опция конвертации atags в DT во время загрузки, в результате ядро загрузить DT и прочитав atags перепишет используя эти значения DT.

Датчик освещения

Опубликовал свое первое приложение в гугл маркете, написал я его полгода назад и сразу выложил исходный код с альфа версией на маpкете, но тогда оно было доступно только ограниченному кругу тестеров, включающему только те аппараты которые мне доступны. Теперь же это 'произведение' доступно всем желающим в собранном виде. Функциональность приложения очень проста, оно берет изображение с фронтальной камеры с минимальным разрешением и заблокированной экспозицией и рассчитывает среднее значение которое ставит как значение яркости экрана. Для удобства тестирования приложение отображает значение с датчика освещения и примерное значение освещения на основе кадра фронтальной камеры.

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

Выбор без вариантов

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

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

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

И получается, что иногда производители позиционируют телефон как не флагманский через установку не последней версии android, установки не самого мощного в линейке процессора или экрана меньшей диагонали или забыть установить какой-то датчик. Что не так страшно по пользовательским ожиданиям, иногда даже в значительно степени повышает пользовательскую ценность и если есть возможность установки обновленной прошивки последней версии, то пользователь получает почти идеальное устройство, так как нивелирует ограничения установленные производителем.

Добавление логотопчика при загрузке

Для пояснения, где эта картинка будет показываться рассмотрим последовательность загрузки телефона:

1. uboot или другой загрузчик, показывает логотип кампании производителя статическая картинка поменять в теории можно, но нужно понимать как загрузка происходит на низком уровне и иметь возможность изменить radio и hboot разделы.
2. загрузка ядра и инициализация устройств, можно добавить лого именно сюда и оно  продержится пару секунд до момента старта инита и замены на анимацию загрузки
3. загрузка инита и монтирования разделов и запуск сервисов  показывается обычная анимация из файла подобного /system/customize/resource/hTC_bootup.zip.

Для того чтобы заменить или добавить логотипчик на 2 шаг нужно сделать такие шаги:

1. Преобразовать картинку с размером экрана(480x800) в raw формат: convert -depth 8 -size 480x800  ~/Downloads/Tux.png rgb:tux.raw
2. Собрать програмку конвертор в формат который понимимает ядро: gcc to565.c -o to565
3. И с конвертировать в нужный формат ./to565  -rle < tux.raw > msmlogo.rle
4. Положить этот файл в корень ramdisk и проверить включен ли CONFIG_FB_MSM_LOGO. По умолчанию картинка должна имень название initlogo.rle, но в моем случае инит скрипт пытался чтото сделать с этой картинкой, что приводило к ребуту телефона и для избежания конфликта я ее переименовал. 

Пересборка boot раздела для android

Собираем утилиты для распаковки образов:

git clone git://github.com/CyanogenMod/android_system_core

cd  android_system_core

gcc -o ../mkbootimg libmincrypt/*.c mkbootimg/mkbootimg.c -Iinclude

gcc -o ../unpackbootimg libmincrypt/*.c mkbootimg/unpackbootimg.c -Iinclude

Распаковываем старый образ полученный с обновления или иным путем:

./unpackbootimg -i boot.img

mkdir ramdisk

cd ramdisk/

gunzip -c ../boot.img-ramdisk.gz | cpio -id

В папке с ramdisk меняем части которые нам нужно, разрешаем отладку и отключаем проверки безопасности (при входе под adb сразу root) меняем:

--- default.prop 2014-08-07 22:35:02.481322985 +0300

+++ default.prop 2014-08-07 22:35:18.293601299 +0300

@@ -1,8 +1,8 @@

 #

 # ADDITIONAL_DEFAULT_PROPERTIES

 #

-ro.secure=1

+ro.secure=0

 ro.allow.mock.location=0

-ro.debuggable=0

+ro.debuggable=1

 persist.service.adb.enable=0

 ro.metropcs.ui=0

Соберем ramdisk обратно:

cd ramdisk/

find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz

cd ..

Упаковываем в новый boot:

cp ../z4u-kernel/arch/arm/boot/zImage .

./mkbootimg --kernel zImage --ramdisk newramdisk.cpio.gz --base 0x3b00000 --cmdline 'no_console_suspend=1 console=null' -o new_boot.img, где 0x3b00000 значение из boot.img-base, no_console_suspend=1 console=null значение из boot.img-cmdline 

Обновление hboot/radio разделов

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

Для этого нужно заблокировать загрузчик:
$ adb reboot bootloader
$ fastboot oem lock

Иначе обновить не получиться, можно получить ошибку вида:
FAILED ( remote: 99 unknown error)

Перепроверяем версию обновления:
Смотрим на modelid в выводе:
$ adb reboot bootloader
$ fastboot getvar all

Распаковываем обновление(OTA_*.zip) и смотрим файл firmware.zip/android-info.txt Если номера совпали значит можно продолжать.

Устанавливаем обновление:
$ adb reboot bootloader
$ fastboot oem rebootRUU
$ fastboot flash zip firmware.zip 

В консоли может появиться:
FAILED (remote: 90 hboot pre-update! please flush image again immediately)
При эом нужно повторить последнюю команду.

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

Разблокируем загрузчик:
fastboot flash unlocktoken unlock_code.bin

Код разблокировки можно получить с официального сайта.

Мобильные ядра

Состояние исходных кодов ядра linux мобильных устройств на примере z4u: 

• Отсутствие документации и комментариев в файлах. Частично решаемо запуском скрипта, который проводит маленькую интеллектуальную работу над исходным кодом удаляя все комментарии и документацию из кода, и сравнивает с исходным кодом, прошедшим точно такой же фильтр, но уже из официальных исходных кодов ядра близкой версии(msm-3.4(aurora), 3.4(kernel.org)). Если все прошло нормально код заменяется на официальный. Но это помогает лишь частично так как при изменении кода скрипт не признает его как подобный. Посмотреть на результаты можно в данном репозитории. 
• Изменения в в системном разделе заблокированы, что легко решается изменением конфигурации. 
• Код ядра базируются на старом коде, если смотреть по некоторым файлам, то исходные коды уже на год полтора отстают от текущего состояния, и может содержать гигантское количество уже исправленных ошибок и не содержать новых улучшений. Что возможно и является причиной отсутствия документации, ее просто тогда не существовало, когда код писался. Как пример arch/arm/common/dmabounce.c находиться в состоянии между 0703ed2a6b260cd743adf49a8281eb064d728832 (04 Jul 2011) и 1dc8f0065cb2a274785fac9da61417908e22e0b9 (15 Aug 2012), если судить по msm-3.4.

Сборка recovery под новое устройство

Последовательность действий такова:

Подготовка окружения для сборки:

• curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo
• chmod a+x ~/bin/repo
• mkdir cm10.1 && cd cm10.1
• ../repo init -u git://github.com/CyanogenMod/android.git -b cm-10.1
• ../repo sync

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

Генирируем заготовку для сборки:

• cd vendor/cm
• ./get-prebuilts
• make otatools
• PATH=$PATH:`pwd`/out/host/linux-x86/bin/
• build/tools/device/mkvendor.sh htc z4u recovery.img

Вместо htc z4u используем имена производителя и модели, но можно использовать любые значения, так как эти значения используются только как название каталогов. Образ recovery.img изначальный образ recovery с официальной прошивки не обязательный параметр, но позволяет заполнить часть значений в конфигурации. После этого в сгенерированной папках нужно поменять значения в BoardConfig.mk и в fstab. Как подсказку для заполнения последнего файла можно использовать список разделов из файла /proc/emmc или в выводе mount.

После обновления конфигурации, можно пересобрать ядро для чистоты эксперимента, конфигурацию ядра можно получить из /proc/config.gz и попытаться пересобрать ядро из исходников подобного устройства c aurora для qualcomm или другого репозитория. Наиболее удобным вариантом может быть скачать исходника с сайта разработчика устройства, пересобрать и заменить файл в сгенерированом каталоге.

• make CROSS_COMPILE=../arm-eabi-4.6/bin/arm-eabi- SUBARCH=arm ARCH=arm z4u_defconfig 
• make CROSS_COMPILE=../arm-eabi-4.6/bin/arm-eabi- SUBARCH=arm ARCH=arm -j 4
• cp {каталог с ядром}/arch/arm/boot/zImage device/htc/z4u/kernel

Затем можно пересобрать recovery в каталоге 10.1:

• source build/envsetup.sh
• lunch cm_z4u-eng
• . build/tools/device/makerecoveries.sh cm_z4u-eng или make recoveryzip -j 4
• fastboot flash recovery out/target/product/z4u/recovery.img

Результаты запуска нового recovery при ошибках можно попробовать посмотреть в /proc/kmsg и /proc/last_kmsg. Необязательно там что-то будет, но попробовать стоит.

Дополнительно можно посмотреть:

1. Сборка recovery
2. Презентация о портировании на новые устройство
3. Replicant Porting Guide
4. How To Port CyanogenMod Android To Your Own Device
5. Porting Android to Devices

Ядро и телефон

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

Или если по порядку: 

Скачать компилятор можно с AOSP, где лежит стандартный компилятор уже "оптимизированный" под сборку Android, что дает нам большой процент вероятности, что у нас все же что-то соберется. Хотя тут тоже могут быть скрытые проблемы модифицированный компилятор использованный при сборке, но такой случай маловероятен иначе на устройстве не будут работать приложения собранный стандартным компилятором из NDK.

Получение конфигурации ядра тоже достаточно простая операция можно получить установив эмулятор терминала на устройство или запустив adb и сделав копию /proc/config.gz.  С конфигурацией тоже могут быть проблемы: отсутствие этой конфигурации по указанному пути, так как производитель решил сэкономить таким образом место, заблокированный доступ к системным каталогам, заблокированный запуск стандартный утилит, заблокированный доступ к системным областям, не стандартные устройства или их не канонические названия, производитель модифицировал стандартное устройство по своему усмотрению - в общем проблемы могут быть даже здесь. Но в основном все же доступ к конфигурации есть, заблокирован только доступ к dmesg, записи или чтению системных устройств - чтобы нельзя было получить прошивку или заменить ее. 

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

Для разработчиков конечного устройства вопрос универсальности или использования одобренных или обсуждённых с сообществом решений вообще теряет смысл, у них несколько иная цель - выпуск продукта в ограниченные сроки, c ограниченной поддержкой вида "работает - не трогай", что приводит к неочень хорошим результатам на всех уровнях. Как пример, это может быть такая ситуация: в прошивке используется как MARCH значение платформы описание, которой отстутстует в исходниках ядер для других устройств стандартного ядра которое дается производителем SOC, врезультате у нас есть описание чипа из спецификации устройства, но описания как иммено оно сконфигурировано нет. И нужно дожидатся открытия исходникой ядра иммено под это конечное устройство, что может произходить достаточно не быстро или вообще не произойти никогда. Следущая проблема качество этих исходных кодов, так как эти исходники собирались только для одного устойства с четко определенным списком функций, никто не обновляет эти ядра из общего хранилища кодов и не возвращает наработки обратно. Как следствие в коде отстутвуют проверки присутствия каких-то опций или наоброт отсутствия их, зависимости между элементами не проверяются и код можно собирать только в том виде как он есть, без изменений и только одим жестко определенным способом. 

И разработки выглядят со стороны, как берется исходный код андроид, модифицируется разработчиком базовых чипов, распространяется с поддержкой этого чипа установленного в стандартной платформы разработки используемой для отладки решения. И как следствие, код с большой вероятностью имеет куски кода от других платформ, но без поддержки сборки на этих платформах или проверки сборки на этих платформах. Затем этот код модифицируется производителем устройства под свои потребности - с изменением аппаратуры и программной части под свои нужды, опять-таки без обращения внимания на совместимость с чем-либо кроме самого устройства. В результате появляются проблемы описанные Линусом, когда отсутствует стандартные интерфейсы определения конфигурации системы во время исполнения системы, так как реализация стандартного механизма усложнит аппаратную часть, а значит, приведет к удорожанию разработки устройства в данный момент. 

Такая же ситуация происходит и с другими частями системы, берется какая-то версия программного обеспечения и модифицируется под какой-то конечный продукт и не обновляется из основного для продукта репозитория, и как результат, все части проверены как рабочие только в ограниченной экосистеме без взаимного обмена новшествами между различными копиями изначально одного продукта. Что имеет некоторую положительную сторону как проверенный годами стабильный продукт, с коллекцией ошибок уже давным давно исправленных в родственных продуктах или отсутствием каких-то приятных свойств, вида большая производительность, новые виды поддерживаемых форматов или отображений. Сложность изменения или переноса каких то частей на другие платформы, в любом из возможных смыслов, как другую аппаратную платформу, другой список оборудования, другое предназначение устройства или использование программной части в другом окружение или с другим списком оборудования. И сборка ядра сводится к поиску похожих устройств или упоминания нужного устройства в исходниках для других моделей на сайтах AOSP, Cyanogwwnmod, Aurora и попытках собрать ядро которое загрузится после сборки на устройстве если повезет. 

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

1. make CROSS_COMPILE=../arm-eabi-4.6/bin/arm-eabi- SUBARCH=arm ARCH=arm menuconfig 
2. make CROSS_COMPILE=../arm-eabi-4.6/bin/arm-eabi- SUBARCH=arm ARCH=arm -j 4 
3. fastboot boot bzImage

Android + autoconfig?

Android по размерам исходного кода более похож на дистрибутивы общего назначения, где есть несколько тысяч пакетов со сложными взаимосвязями. Последний Android содержит примерно 370 пакетов в терминах обычных дистрибутивов. Основное отличием от остальных дистрибутивов является использование жестко прописанные зависимостей, что обычно характерно для встраиваемых систем или внутренних продуктов заточенных на выполнение только жестко ограниченной функциональности без повторного использования другими продуктами.

Для Android - причина таких особенностей связана с тем что:

• нужно всегда иметь вне зависимости от окружения сборки получать одинаковый результат;
• собирается он с жесткой привязкой к одной аппаратуре, собирается только раз и после первоначальной продажи продукта обновления выпускаются только исправления безопасности, поэтому особой универсальности не требуется
• каждый производитель использует свои наработки по работе с аппаратурой, поэтому перенос с одной платформы на другую или обновление прошивки не требуется так как часто люди скорее купят новый телефон с новый пользовательским окружением чем будут обновлять прошивку так как после нее поменяется принцип пользовательского окружение, а люди не любят менять привычки - и новое устройство с новым пользовательским окружением предпочтительно
• большинство компонент непосредственно конечными пользователям не видно - так как пакетного менеджера нет и поставить что то по зависимостям нельзя и нужно предусмотреть максимально широкое API чтобы не тянуть все те же компоненты с пользовательских программами,
• встроенных программ тоже не много в отличии от других дистрибутивов - вкусы всех не предугадаешь и так можно оставить больше возможностей для внесения разнообразия сборщиками под продукт

Как следствие отсутствие классической инкрементальной сборки, отсутствие средств автоконфигурирования, жесткая привязка к кросскомриляции с изначально заданными параметрами, в общем не LFS или Gentoo.

Возможно это все можно решить, если изначально собирать все по принципам LFS и в эмуляторе конечной платформы. Но результат такой системы будет полностью переписанная сборка частей общих и характерных для остальных дистрибутивов Linux и опять таки сложная система с жесткими связями для пользовательского интерфейса где используется Dalvik, плюс проблема с драйверами к аппаратуре - так как Android позволяет больший разброс в идеях как работать с аппаратурой чем обычный linux и содержит части из других операционных систем, например binder (часть как следствие вечно живой Beos).

Обновление радио

При обновлении прошивки для радиочипа на android телефоне может поменяется идентификатор usb, для обычных пользователей это не так важно, но для использования fastboot и adb нужно в udev поменять этот идентификатор и права на него.

Установка достаточно проста: 

1. скинуть в корень флешки, 
2. перегрузится через adb reboot bootloader, 
3. выбрать обновление.

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

Android прошивки

​Существуют общность возможно даже недостаток прошивок Android и стабильных версий дистрибутивов и в общем-то любых прошивок - используются старые версии библиотек. Но все же ближе к обычным прошивкам - так как после релиза не вносятся изменения в базовые компоненты. Возможно, что версия библиотек определяется как последняя стабильная версия на момент начала разработок, и основные изменения вносятся только во внутренние части продуктов, разрабатываемых внутри компании и как следствие представляющие наибольший интерес для компании разработчика.

Было бы удобно, если бы бекпортировали изменения в ядре и библиотеках связанных с безопасностью openssl, openvpn и тому подобное. И обновляли все библиотеки у которых не меняется внешний интерфейс, например libxml и bash и sudo. И прошивка для телефонов поддерживающих по каким-то причинам только версию 2.3.* с обновленными ssl библиотеками и браузером, была достаточно полезна. Так же было бы не неплохо иметь возможность устанавливать и обновлять все пользовательские приложения не относящиеся к базовой функциональности в виде пакетов, например обновлять браузер(не html движок)и телефонное приложение, а в базовой обновляющееся только с прошивкой: сервисы, виртуальная машина и все остальные части в отдельном обновляемом разделе, который можно перекрывать как сейчас, когда обновленные версии хранятся в отдельном разделе.

Результатом моей попытки по обновления компонентов которые собираются без проблем со старым abi без изменений в критических компонентах к которым привязаны бинарные библиотеки для поддержки аппаратуры можно посмотреть сдесь.

iOS и Android

IPhone все же лучше чем Android, из-за дикого разнообразия устройств, даже если не учитывать разнообразие версий Apple очень строго контролирует свою экосистему, и новые устройства хоть и отстают технически по объему памяти и мощности процессора - всегда имеют четко продуманный дизайн и отличный экран и камеру. Благодаря строгому ограничению мощности и компиляции под аппаратуру в бинарном виде и попыткам исключить любые интерпретаторы и бессмысленное выполнение в фоне, они получили продукт который в основном не вызывает недовольства у пользователя своей заторможенностью, имея при этом далеко не передовые аппаратные средства. 

В Android выбран режим виртуальной машины широко распространенного языка Java что конечно дало возможность получить большое количество разработчиков, но добавило проблем с лицензией на использование и патентами на реализацию, которая внутренно не совместимо с изначальной реализацией виртуальной машины. Выбрав как язык виртуальной машины python или другой подобный язык удалось бы возможно избежать некоторых проблем с лицензией, но все-же не решило всех проблем - так лицензионное разбирательство происходило не столько из-за использования языка сколько из-за вопроса реализации виртуальной машины. И никто не может сказать чтобы было выбери они другое решение. А тихое ожидание и скрытые проблемы с лицензиями и патентами только вредят продукту- зная что именно нарушено в 235 патентах, можно реализовать по другому функциональность или добиться решения о аннулировании патентов. И если продолжаются скрытые соглашения о крослицензировании для OpenSourse проекта, разработчиком может не захочется открывать/ сообщать о своих улучшениях, если в какой-то момент окажется, что ты не можешь использовать свои наработки и вынужден за них кому-то платить. 

Благодаря этому продукту Linux смог получить большой рынок и выйти за приделы серверов и встраиваемой техники, что конечно большой плюс. И если добавить возможность принудительного ухода в спящий режим и возможность сохранения состояния программы по запросу от системы - в режиме слушаем фоновую музыку и открыт только текстовый редактор- мы получим громадное сокращение потребления энергии, так как проигрыватель может сохранить состояние своего интерфейсного окна и оставить рабочим только звуковой модуль, также как тестовый редактор может сохранить состояние других документов и только оставить рабочим модуль с текущим документом, или вообще выгрузится полностью. Но как я знаю ни Gtk ни qt - не поддерживают сигнал на сохранение состояния ни на восстановление оного. Подразумевается именно событие на сохранение, а не обычный сигнал закрытия окна. 

P.S.: Я не владелец iPhone. Поэтому мое мнение сугубо субъективное.

Желания и мечты

​Не все желания выполнимы, после того как google официально объявило, что больше не будет поддерживать nexus one он же htc desire, htc объявило что запланированное обновление для desire hd тоже не выйдет - оно планировалось на июль-август - о чём как раз и было объявлено под конец этого срока. Пользователи уже создали петицию с просьбой выпустить еcли не полное обновление - то хотя бы код ядра и драйвера. В общем именно то чего не хватает альтернативным прошивкам для работы. С остальными устройствами в общем-то та же история - в основном прошивки сейчас есть только для последних устройств идущих с новым андроидом. Что будет с остальными устройствами не понятно, часть будет уже сейчас официально не поддерживаться в cyanogenmod 9+ версии, как не удовлетворяющая минимальным требованиям для андроида, так как на этих устройствах скорее всего будет проблемы с новыми приложениями рассчитанными на большие аппаратные возможности, и чтобы не создавать продукт которые вызовет только рост недовольных отзывов - решили официально не поддерживать. Относительно устройств которые удовлетворяют этим требованиям, но компании производители не хотят по своим внутренним причинам выпускать обновление прошивок, ответ похоже скорее всего - возможно, если смогут портировать драйвера с других устройств или через какие-то дополнительные абстракции, чтобы работали старые драйвера. Что в общем-то близко, но всё же отличается от обычных дистрибутивов линукса, где с большой вероятностью пользовательские устройства с более менее широкой распространённостью все же с большой вероятностью поддерживаются. Ноутбуки все же в большой степени остаются функциональными из-за широкой общности устройств и использования для удобства пользователя различных ухищрений с возможностью автоматической настройки устройств(USB, Plug and Play) - и скорее всего устройство как-то себе идентифицирует при загрузке, но всё же остаются различные проблемы вида сложностей обновления прошивок, так как производители не сообщают спецификацию и эта процедура может сильно отличаться между моделями, а может и нет - так как для прошивки используются приложения поставляемые производителем BIOS, а не устройства. Но всё же полной спецификации нет и CoreBoot может использоваться не на всех устройствах. Также есть проблемы когда производитель не поставляет драйвера или не обновляет их под новые ядра - но в основном это решается если устройство популярно.

Ice Cream Sandwich on Desire HD

Решил проверить как продвигается CM9 - пока не очень.

Используя версию чистого CM9 на основе инструкции- не загрузилось :-( Анимация при загрузке зациклилась, а как смотреть лог загрузки для андроида не понятно. Если есть желание повторить нужно загрузить: repo init -u git://github.com/CyanogenMod/android.git -b ics и добавить в system/.repo/manifests/default.xml репозитории:

1. project path="device/htc/ace" name="CyanogenMod/android_device_htc_ace"
2. project path="device/htc/common" name="CyanogenMod/android_device_htc_common" revision="refs/heads/gingerbread"
3. project path="device/htc/msm7x30-common" name="CyanogenMod/android_device_htc_msm7x30-common"
4. project name="koush/proprietary_vendor_htc" path="vendor/htc"

Версия собранная специально для этой модели запустилась - единственное отсутсвует приложение для радио и при записи видео приложение вылетает.

MESH телефончик

Идея для маленькой программки - полурация - полуmesh сеть :-) В принципе уже есть аналог http://www.servalproject.org/ - вобщем-то, если верить описанию всем хорош - можно звонить без сети, можно передавать файлы, слать SMS. Программа может сама управлять сетью, но она мне кажется не удобной - слишком много функционала или мне просто хочется создать свой велосипед - единственное, что не удобно для отправки SMS используется, как я понял, внешняя сеть и SMS будет отослан через http://code.google.com/p/websmsdroid/ веб-сайты. Основной проблемой как по мне является не возможность аутентифицировать звонящего - так как можно спокойно менять свой номер. Другим аналогом может быть http://sipdroid.org/ - все хорошо - но нужно постоянное соединение с интернетом и регистрация SIP аккаунта.

В общем моя идея - приложение которое будет заменять стандартные с минимальный функционалом - возможно с интеграцией в стандартные приложения отправки сообщений, может нет, скорее это дополнительное приложение объединяющее обе возможности: дешевая связь через локальную сеть и дорогую, но более классическую отправку через оператора. Так как если оставить стандартные приложение в них можно посмотреть, что и как реально отправлялось. 

Принцип работы приложения:

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

Это тоже не идеально - но по идее позволяет примерно убедиться, что это тот же абонент что и раньше был. Хотя кто то может подсмотреть циферки и узнать по какому коду мы раньше проверили - но все же нет возможности легко выдать себя за кого-то другого - поменяв настройки.

Fastboot

Есть маленькая особенность при прошивке через fastboot - идентификатор устройства в режиме fastboot не совпадает с идентификатором после загрузки поэтому adb видит устройство после загрузки, но если не прописать правильные идентификаторы udev - fastboot не увидит устройство. Потому желательно поискать телефон через lsusb(телефон должен быть в режиме fastboot) - там должна быть строка вида: 

Bus 001 Device 016: ID 0bb4:0fff High Tech Computer Corp. Android Fastboot Bootloader 




И 0fff - нужно записать в '/etc/udev/rules.d/11-android.rules' в виде строки: 

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bb4", ATTRS{idProduct}=="0fff", MODE="0666", OWNER="mylogname" 

После этого телефон должен появиться в списке fastboot devices, в том случае если телефон поддерживает этот режим прошивки,  я пробовал только на Nexus One и HTC Desire HD. Другие производители я думаю не используют High Tech Computer в идентификаторах. Причем Nexus One точно можно разблокировать прошивку через fastboot( fastboot oem unlock ), на Desire не пробовал.

Android и вирусы

​

Андроид стал очень популярной системой под него есть вирусы и их даже не нужно компилить:-) Правда они пока ориентированы на невнимательность пользователя - так как нужно подтвердить установки и если не включено разрешение установки пакетов не из Android Market(Application Settings -> Unknow sources) - то вообще установку выполнить нельзя. Но вообще это очень положительный момент - значит эта операционная система очень популярна среди пользователей.

Это произведение хорошо определяется DrWeb (можно установить из маркета бесплатно). А вот clamav не захотел определять как вирус :-(

 По заголовкам пакета это произведение хотело сказать что оно опера:-)