суббота, 22 марта 2014 г.

Обновление 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 

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

понедельник, 10 марта 2014 г.

cm11 recovery for z4u

Удалось преодолеть первый шаг на пути создания собственной прошивки для z4u. Теперь можно использовать recovery раздел по назначению:-) Можно ставить новый прошивки и делать бекап для текущей прошивки. 
Ранее recovery имел следующие недостатки: 
  • прыжки изображения на экране при смене пункта меню что было не критично, но все же было недостатком (благодаря комиту); 
  • после подсказки в обсуждении разработки recovery и сравнения файлов используемых как fstab на разных версия cyanogenmod - удалось исправить этот файл, который поменял синтаксис для новых версий и теперь все грузится без проблем. Ранее экран просто мигал несколько раз каждую минуту и не показывал никакого меню. 


На данный момент в автоматически сгенерированной конфигурации нужно исправлять: 
  • fstab - по данным из /proc/emmc - данный файл отличается для 10.1 и 11 версии cyanogenmod 
  • BoardConfig: BOARD_*_SIZE - для указания реальных размеров разделов, TARGET_ARCH_VARIANT_CPU, TARGET_BOARD_PLATFORM, TARGET_BOARD_PLATFORM_GPU - для указания реальных значений процессора и видеокарты.

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

четверг, 27 февраля 2014 г.

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

Состояние исходных кодов ядра 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.

воскресенье, 9 февраля 2014 г.

Сборка 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. Необязательно там что-то будет, но попробовать стоит.

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

суббота, 4 января 2014 г.

Proxy и маршрутизация

Нет предела совершенству.

Оптимизация трафика на уровне прокси имеет несколько ограничений, если верить данным с chrome beta на мобильном телефоне, он смог уменьшить затраты трафика на 65% для сайтов благодаря тому что пропускал трафик через свои сервера и минимизировал его. Недостатков я не заметил, но если верить статистике с httparchive - крупные сайты достигли 77 пунктов в pagespeed - что достаточно не плохо на уровне среднего уровня оптимизации и с сравнение трафика пропущенного с оптимизацией с чистым трафиком покажет достаточно не плохие результаты, подобные двойному уменьшению объёма трафика.

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

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

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

Но идея вида максимально совместного использования инфраструктуры всеми возможными видами использования канала, как например: телевиденье, мобильная связь, интернет, позволяет получить покрытие до 100%. Так как исчезает потребность установки в некоторой малопопулярной местности оборудования (сетевое оборудование, передатчиков) для всех видов связи, устанавливает один, остальные арендуют. Так же изменить принцип работы мобильной сети, когда любой трафик должен пройти до корневого оборудования, вне зависимости где находятся источники этого трафика, чтобы соединение между конечным оборудованием разных видов связи, как частный случай одного, не шло через корневые узлы, а происходило по минимально возможному маршрут, например трафик для голоса и передачи данных обменивался в рамках пары десятков километров, а управляющий трафик шел, как и раньше на корневые узлы. Что позволит получить в достаточно большую теоретическую выгоду, так как данные миновав низкоскоростной канал связи, которым является последняя миля, могут быть централизовано быть проанализированы и пущены кратчайшим путем до получателя.

воскресенье, 29 декабря 2013 г.

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

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

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

Скачать компилятор можно с 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

суббота, 28 декабря 2013 г.

Оптимизация через уменьшение

Лучший код тот, который не написан. 

Очистка html от пробельных символов:

Достоинства: 
  • ускоряет разбор документа на клиентской стороне; 
  • уменьшает размер сжатого deflate результата уменьшая энтропию тегов с символами возле них;
  • экономия места при кешировании; 
  • возможность получения статистики распределения размера встроенных элементов в результате; 
  • возможность смены последовательности тегов для оптимизации отображения. 

Недостатки: 
  • затраты ресурсов на очистку; 
  • дополнительное место для отказа. 

Очистка и объединение файлов css: 

Достоинства: 
  • минимизация кода и удаление пробельных символов как следствие сокращения объёма трафика; 
  • возможность поменять последовательность тегов; 
  • удаление лишних стилей в случае перекрытия частей стиля в последующем коде. 

Недостатки: 
  • возможно усложнение отладки из-за изменений в исходном коде; 
  • дополнительные затраты ресурсов. 

Очистка и объединение файлов js: 

Достоинства: 
  • минимизация кода и удаление пробельных символов как следствие сокращения объёма трафика; 
  • возможность удалить или оптимизировать код; 
  • ускорение работы кода как результат удаления "мертвого кода" и ускорения разбора. 

Недостатки: 
  • возможно усложнение отладки из-за изменений в структуре исходного кода; 
  • дополнительные затраты ресурсов.