среда, 22 марта 2017 г.

Всё обо всём. Выпуск #05. Немного о ядрах ...

В последнюю неделю в блоге практически не было новых постов ... отчасти это связано с небольшими проблемами со здоровьем, отчасти с тем, что плюсом к этому была очень большая нагрузка по работе. Однако, даже в этой ситуации с катастрофической нехваткой времени, все же удалось немного заняться тем что действительно интересно мне сейчас. После последнего поста про активацию тачпада в recovery и patch'е ядра Mediatek я заинтересовался вопросами сборки ядра из исходников. Про это и будет сегодняшний выпуск ... т.к. это "Всё обо всём", то здесь не будет конкретных мануалов или инструкций, я просто расскажу о том каких результатов удалось достичь мне в рамках моих "домашних исследований" ;) В качестве подопытного я взял небезызвестный "музыкальный смартфон" от компании Highscreen - Boost 3 SE PRO и решил попробовать собрать для него альтернативное ядро 3.18.35+ ...

Надо сказать что изначально этот аппарат поставляется с Android 6.0 и стоковым ядром 3.18.19, традиционным для Marshmallow. Поэтому цели которые я ставил перед собой изначально выглядели следующим образом - попробовать собрать рабочее ядро 3.18.35+ и изучить возможность сборки ALPS 7.0 (Android Nougat) под этот аппарат. Те из вас, кто ранее пользовался различными кастомными прошивками (не обязательно для этого аппарата) наверняка заметили, что подавляющее большинство из них, например, Lineage 14.1 (Android 7.1.1) и т.п. обычно собирают на базе "стокового ядра". В основном это обусловлено тем, что производитель не предоставляет исходники ядра для своих аппаратов ... т.е. исходников ядра у авторов прошивки просто нет ... Как известно, ядро 3.18.19 для работы Android Nougat "не подходит", поэтому в данной ситуации есть два пути - либо собрать обновленное ядро из исходников, либо "адаптировать" прошивку для работы на старом ядре, что в большинстве случаев мы и видим.

Мне же в данном случае был интересен другой путь, а именно, сборка Android Nougat из Mediatek'овских исходников и как, следствие, процесс сборки обновленного ядра. Что из этого получилось вы можете видеть на следующих фото:


Тех кто увидев данные фото спешит воскликнуть "вау, наконец-то кто-то собрал полноценный Nougat для нашего аппарата" - поспешу огорчить. Он далеко неполноценный. Т.е. это просто "учебный проект" на котором я учился собирать ядро, разбираться с работой драйверов lcm, imgsensor'а, touchpad'а, узнавал что такое dts (dtb), codegen.dws и т.п. вещи.

За основу были взяты исходники ALPS'а 7.0, найденные на просторах "китайского интернета". Иногда поиск по pan.baidu.com бывает достаточно занимательным ... так или иначе мне удалось найти один более или менее рабочий проект, который можно было использовать для моих задач.


В результате примерно двух дней работы мне удалось собрать более-менее живое ядро 3.18.35+ с которым собранный Nougat запускался ... в ядро были перенесены драйвера дисплея, тача, акселерометра, сенсоров камеры, исправлены все ошибки сборки ... однако, по факту оказалось что до создания полноценной прошивки на базе этого ядра еще "ой как далеко" и по-сути это труд не для одного человека. В получившемся варианте не работает камера (то что необходимые драйверы сенсоров камеры есть в ядре - далеко недостаточно для того чтобы камера работала в Android) ... кстати, те кому интересно могут почитать найденный мной на просторах интернет Camera Porting Guide от Archermind. Так вот, помимо наличия необходимых драйверов в Kernel space, Android в User space'е тоже должен знать о том какие сенсоры камеры используются в аппарате (у меня он пока этого не знает). Также, т.к. аппарат использует ЦАП ESS9018K2M + усилитель ADA4897-2 - звук в Android также отсутствует. Т.к. чтобы он заработал необходимо наличие драйверов ESS9018 в ядре и соответствующих модификаций "звуковой части" самого Android - audioflinger'а, audiopolicymanager'а и т.п.

Естественно все это требует более тщательного изучения, исходников от производителя и, самое главное, времени, т.е. тех самых "человекочасов", которых в рамках "хобби" просто нет. Поэтому говорить в данном случае о сборке полноценного Android 7.0 на Mediatek'овских исходниках не приходится. Однако, благодаря этому маленькому эксперименту мне удалось получить, как минимум, начальные знания о kernel. Разобраться в том из чего состоит ядро, каким образом осуществляется интеграция новых устройств в него и ряде других абсолютно понятных и прозрачных для тех кто имеет с этим дело каждый день моментов. Примечание "для тех кто имеет с этим дело каждый день" в данном случае было сделано не зря, т.к. на тот момент когда я только начинал этот эксперимент никаких знаний о ядре у меня не было совсем. Т.е. ядро для меня представлялось неким черным ящиком в виде Image.gz-dtb в boot.img ... по-сравнению с тем уровнем за два дня работы я узнал достаточно много, но все равно крайне недостаточно ;) Как там было у Сократа: "Я знаю, что ничего не знаю" или в другой интерпретации "Чем больше я узнаю, тем больше понимаю, что ничего не знаю" ... 

Примерно такие же ощущения испытал и я ... ну а на сегодня, пока все ... если в этом проекте что-то сдвинется с мертвой точки - я обязательно буду держать вас в курсе. Тех же кого просто интересуют альтернативные прошивки на данный аппарат, могу сказать что я уже выложил LineageOS 13.0 (Android 6.0) для него на одном из популярных мобильных форумов. При желании можно найти и попробовать ... Всем добра и stay tuned ... ;)

суббота, 11 марта 2017 г.

Как активировать тачпад в Recovery на MTK или патчим ядро Android.

Как вы заметили я редко пишу узкоспециализированные технические посты, в основном контент расчитан на более широкую аудиторию, но сегодня я не удержался. Предыстория очень простая. Во время сборки кастомного Recovery для одного из аппаратов на чипе от Mediatek я столкнулся с проблемой - тачпад в Recovery не работал, а любые упоминания о mtk-tpd напрочь отсутствовали в /sys/class/input. Надо сказать что mtk-tpd это как раз и есть тот самый MTK Android Linux Touch Panel Device Driver, который отвечает за работу тачпада. Напомню, что в нормальной ситуации, когда тачпад в recovery работает, сделав что-то вроде grep . /sys/class/input/input*/name в консоли мы должны увидеть примерно следующее:


/sys/class/input/input0/name:ACCDET
/sys/class/input/input1/name:mtk-kpd
/sys/class/input/input2/name:hwmdata
/sys/class/input/input3/name:m_alsps_input
/sys/class/input/input4/name:m_acc_input
/sys/class/input/input5/name:m_gyro_input
/sys/class/input/input6/name:mtk-tpd
/sys/class/input/input7/name:mtk-tpd-kpd

Однако в моей ситуации mtk-tpd отсутствовал. Зная что на одном из форумов есть человек, который уже занимался патчами ядра ARM64 для Mediatek, я обратился к нему с вопросом, а каким образом (честно говоря я рассчитывал на ответ в двух словах, такая-то функция, такая-то проверка) он заставил работать тачпад в recovery и что конкретно он патчил в ядре. Правда здесь я почему-то наткнулся на стену глухого непонимания и какой-то секретности. Ну "секрет" так секрет, настаивать, чтобы кто-то что-то рассказал, если человек сам не хочет бессмысленно. Поэтому я решил провести некий анализ, который занял от минут 30-40 ... теперь голые факты. В MTK существует несколько режимов загрузки, который описаны в заголовочных файлах ядра (mt_boot_common.h), вот они:

/* boot type definitions */
enum boot_mode_t {
 NORMAL_BOOT = 0,
 META_BOOT = 1,
 RECOVERY_BOOT = 2,
 SW_REBOOT = 3,
 FACTORY_BOOT = 4,
 ADVMETA_BOOT = 5,
 ATE_FACTORY_BOOT = 6,
 ALARM_BOOT = 7,
#if defined(CONFIG_MTK_KERNEL_POWER_OFF_CHARGING)
 KERNEL_POWER_OFF_CHARGING_BOOT = 8,
 LOW_POWER_OFF_CHARGING_BOOT = 9,
#endif
 DONGLE_BOOT = 10,
 UNKNOWN_BOOT
};

В драйвере дисплея в процедуре инициализации тача есть проверка:

static s32 tpd_i2c_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
 int err = 0;
 int count = 0;

 GTP_INFO("tpd_i2c_probe start.");
 if (RECOVERY_BOOT == get_boot_mode())
  return 0;
 probe_thread = kthread_run(tpd_registration, client, "tpd_probe");
 if (IS_ERR(probe_thread)) {
  err = PTR_ERR(probe_thread);
  GTP_INFO(TPD_DEVICE " failed to create probe thread: %d\n", err);
  return err;
 }

 do {
  msleep(20);
  count++;
  if (check_flag)
   break;
 } while (count < 50);
 GTP_INFO("tpd_i2c_probe done.count = %d, flag = %d", count, check_flag);
 return 0;
}

Как видно при вызове tpd_i2c_probe проверяется, если boot mode у нас равен RECOVERY_BOOT, то драйвер у нас не инициализируется ;) Т.е. со стороны MTK так и задумано что в recovery тач пользователю не нужен. Но ведь TWRP фактически использует только тач, скажете вы и будете правы. Но девайсы на платформе MTK никогда ведь не идут с TWRP в комплекте, а стоковому recovery тач естественно не нужен. Поэтому сейчас я вам расскажу как найти соответствующую проверку в бинарнике ядра, ну а непосредственно патч будет "домашним заданием" ) Должна же остаться какая-то "изюминка" ... Так вот. Для начала узнаем адрес tpd_i2c_probe, для этого от имени root выполняем:

sh -c "echo 0 > /proc/sys/kernel/kptr_restrict"
cat /proc/kallsyms | grep tpd_i2c_probe

В результате получаем нужный нам адрес 0xffffffc000760494. Далее загружаем в любом дизассемблер распакованное ядро (архитектура моего CPU - ARM64, поэтому offset нужной нам функции как видите 64-битный) с адреса 0xFFFFFFC000080000 (для 32-bit ядер - 0xC0008000) и переходим по найденному адресу:


На скриншоте выше наглядно видно и исходники и дизассемблированный код. На поиск нужной функции, как вы можете убедиться, и места проверки в ядре у нас ушло не более 5 минут. Теперь нам достаточно убрать условный переход по адресу 0xFFFFFFC0007604D0, заменив его NOP'ами или любой другой "пустой операцией" и собрать boot с модифицированным ядром назад. После чего при загрузке в recovery тачпад будет успешно инициализироваться.

Успехов вам!

p.s. Да, забыл сказать ... в данном примере мы разбирали инициализацию MediaTek gt91xx touch panel driver. Естественно, что в вашем устройстве может быть другой драйвер тача.

четверг, 9 марта 2017 г.

Highscreen Power Five Max. "Китаец" из будущего ...

Так получилось, что я опять на больничном ... решил все-таки заняться зубами на старости лет ;) А т.к. процесс этот долгий и мучительный, то помимо всего прочего я решил взять в разработку еще один проект. Предыстория очень простая, есть один такой интересный аппарат с названием Highscreen Power Five Max. Не знаю почему, но до этого времени я как-то незаслуженно обходил стороной продукцию этого производителя, не то чтобы намеренно, но как-то ни один из их аппаратов не попадался мне в руки. Поэтому когда ко мне в ЛС постучался некто и спросил "А не поможешь собрать нам Android 7.1.1 для Power Five Max?" - я вначале хотел оказать (времени совсем не было, а как известно это самый ценный ресурс, который иногда дороже всего остального, согласитесь, ведь в сутках всего 24 часа и при всем желании "докупить" время нельзя), но ради интереса спросил "А что это?" ... Когда мне показали характеристики устройства я слегка удивился ... если вкратце, то это девайс на Mediatek MT6755 с 4 Gb RAM, 64 Gb внутренней памяти (!), основной камерой в 13 MPix (Sony IMX258), Full HD Super AMOLED дисплеем и различными "плюшками" вроде датчика отпечатка пальцев и инфракрасным портом (Remote IR) для управления бытовой техникой. Впечатляет, не правда ли?

Более подробно с характеристиками аппарата вы можете познакомиться на официальном сайте производителя - Highscreen Power Five Max. Возможно чуть позже я сведу их в отдельную таблицу здесь, со своими комментариями. Но вернемся к нашей истории ... После того как я немного познакомился с этим аппаратом, я подумал что все же будет интересно собрать под него Nougat, плюс покрутить его в руках, т.к. не каждый день в руки попадают действительно интересные девайсы. Человек который изначально обратился ко мне с этим вопросом сказал, что он и еще группа заинтересованных товарищей купят мне этот аппарат, чтобы я мог начать работать над прошивкой (кстати, стоит это чудо техники на данный момент ~20990 руб., что выглядит вполне оправданной ценой за такой набор характеристик) ... но единственное условие, которое они ставят - это чтобы в получившейся прошивке работал IR порт и датчик отпечатка. Вспоминая историю с Doogee и все сложности с которыми мне пришлось столкнуться, я нехотя согласился, мысленно уже представляя все возможные проблемы с Goodix'овским датчиком fingerprint'а. Однако интерес пересилил ... и через некоторое время аппарат был у меня.

Тут надо сказать что к тому моменту уже успела выйти одна кастомная прошивка для него - Lineage 13.0, но она была на Android 6.0, плюс многие устройства в ней не работали. К тому же, как я понял из различных мобильных форумов, пользователи сумели собрать кастомный recovery для этого аппарата (TWRP), он он не поддерживал шифрование. Т.е. не расшифровывал раздел userdata ... Т.к. заставить работать встроенное шифрование пользователям было не под силу, они решили эту проблему проще, заменив флаг forceencrypt в boot'е на encryptable и отформатировав полностью раздел data, таким образом отключив шифрование вообще. Т.е. до этого момента перед использованием TWRP или установкой кастомной прошивки userdata обязательно было форматировать.

До этого момента - потому что меня такой вариант категорически не устраивал, ибо во-первых нельзя лишать телефон функции шифрования данных, а во-вторых TWRP, который не умеет работать с зашифрованным разделом, лично я бы использовать не стал. Поэтому первое что я сделал (на то чтобы разобраться как работает mobicore'овское шифрование ушли где-то сутки) это собрал TWPR с поддержкой шифрования:


На следующих фото отчетливо видно, как раздел userdata у нас расшифровывается и создается новое блочное устройство /dev/block/dm-0. Начало положено ... Забегая вперед скажу, что разработка дерева для Lineage 14.1 (Android 7.1.1) заняла у меня примерно неделю. С результатом можно ознакомиться здесь - android_device_HighScreen_PowerFiveMax. В коммитах видно, насколько сложной и поэтапной была работа над ним, а в NOTES.md перечислены основные проблемы и варианты их решения. Что-то вроде заметок для себя, но, как показывает практика, их ведение полезно всем. Т.к. аналогичные проблемы могут встретиться и у других пользователей, которые имеют аналогичное "железо".

Первая сложность с которой пришлось столкнуться - это начисто неработающий звук. audio.primary.mt6755.so загружался, но тут же падал, при попытке вызова функции _ZN7android22AudioMTKGainController17SetHeadPhoneLGainEi (android::AudioMTKGainController::SetHeadPhoneLGain(int)) и некоторых других. Изначально я пошел по неверному пути и попытался просто сделать "заглушки" для них, в либе которая загружалась через LD_PRELOAD. Звук-то конечно появился, но начисто пропал микрофон, т.к. Android не мог управлять "уровнями громкости" в нем. Тогда я попробовал использовать audio.primary от MT6735 платформы. В этом случае все заработало, но начисто пропала связь, т.е. SIM не определялась. Решение оказалось простым, а проблема была в моем незнании специфики MT6755, оказывается помимо прочего на этой платформе существует еще и папка etc/audio_param, а также некоторые другие конфигурационные файлы, отвечающие за звук, уровни громкости и т.п. Я по незнанию просто не включил их в свое дерево, в результате чего потратил несколько дней на то, чтобы разобраться в сути проблемы. Впрочем, добавив в дерево все необходимое - звук успешно поднялся.

Следующей проблемой была проблема с crash'ем Zygote ... изначально я добавил в permission'ы android.hardware.consumerir.xml ... так вот этого делать было нельзя, пока все остальное что касается работы IR не было добавлено в результирующую прошивку. На это также ушло достаточно много времени. Единственный урок который я извлек для себя - не добавлять в /etc/permissions вообще ничего лишнего до тех пор пока не будут задействованы все необходимые BLOB'ы, иначе прошивка может просто не запуститься (а в данном случае правда удалось связать крах Zygote с отсутствием IR HW модуля, но в остальных случаях все может быть не так тривиально). IR кстати после этого завелся относительно легко, по крайней мере в Peel Remote он отлично работал.

Самая душещипательная история коснулась датчика сканера отпечатков пальцев от Goodix, с подробностями можно ознакомиться в NOTES.md в дереве в разделе Fingerprint. После нескольких бессонных ночей, патчей sepolicy и PackageManager'а он заработал. Но трудов в это было вложено порядочно. В итоге получилась вполне рабочая прошивка:




Однако, на текущий момент, увы, в ней обнаружилась проблема с камерой, которая после нескольких (десятков) снимков в режиме фото просто "зависает". Возможно проблема связана с ошибкой внутренней памяти самого аппарата, т.е. возможно что проблема в данном случае не софтовая, а железная. Поэтому пока данный баг не будет устранен или не будет установлена его причина - выкладывать релиз я не буду. Работы продолжаются, ну а желающие могут пока поддержать проект ...

Обновлено 09.02.2017 22:34 MSK

  • TWRP-3.0.2.0-decker - TWRP recovery собранный из исходников с полной поддержкой принудительного шифрования раздела userdata. Т.е. если вы сразу после стоковой прошивки установите данный TWRP, вам не придется делать Format Data. Полная поддержка шифрования означает то, что раздел userdata у вас будет расшифровываться в любом случае, даже если вы установили PIN код и поставили его запрос при загрузке. В этом случае TWRP запросит у вас пароль для расшифровки раздела, введя который раздел userdata успешно примонтируется. В архиве сам TWRP и Scatter для прошивки через SP Flash Tool.

    Важно: если после прошивки TWRP телефон не загружается в ОС, "зависая" на заставке Android - установите через TWRP с помощью опции Install ZIP последний архив с SuperSU с официального сайта ChainFire. Последнюю версию zip'а с SuperSU всегда можно взять здесь - Stable, Beta, Latest.
  • lineage-13.0-20170309-UNOFFICIAL-PowerFiveMax.zip - Lineage OS 13.0. Перед установкой этой прошивки сделать wipe'ы всех разделов. При инициализации мастера первоначальной настройки симка определяется спустя некоторое время, поэтому рекомендуется дойти до шага подключения к WiFi сети и подождать 1-2 минуты. Далее, на экране "Настройка сканера отпечатка" нажимаем "Настроить экран блокировки" и добавляем хотя бы 1 отпечаток (!) ... Это наиболее стабильная версия из всех представленных прошивок. Камера, запись видео, GPS, сканер отпечатка, ИК порт и прочее на ней работают, по-крайней мере на имеющемся у меня девайсе.

    Видеоинструкция как добавить отпечатки пальцев на Lineage 13.0. Если не идет просмотр непосредственно на Яндекс.Диске, скачайте файл к себе на ПК.

Версия LineageOS 14.1 на базе Android 7.1.1 пока находится в стадии доработки, желающие могут получить её по запросу в комментариях. Также перед установкой прошивки настоятельно рекомендуется ознакомиться с порядком установки, приведенным по ссылке.

Обновлено 10.03.2017 10:49 MSK

FAQ

Q. Я сделал сброс настроек из меню Настройки -> Восстановление и сброс после чего аппарат грузится только в recovery? Что делать?
A. Все дело в том, что Lineage (любая версия) несовместимы с этим TWRP, поэтому сброс через меню Настройки -> Восстановление и сброс делать не рекомендуется, достаточно просто сделать Wipe Data / Factory Reset в Recovery. Если же вы по каким-то причинам сделали этот сброс и телефон у вас грузится только в Recovery, то поправить это достаточно просто:

1. Залить стоковую прошивку через SP Flash Tool (менее предпочтительный вариант)
2. Вручную очистить раздел para / misc с помощью SP Flash Tool. Как это сделать показано на следующей картинке:


Внимание! Значения Begin Address и Format Lenght нужно брать из вашего scatter'а, от стоковой прошивки. Т.е. открываем его и смотрим раздел para:

- partition_index: SYS3
  partition_name: para
  file_name: NONE
  is_download: false
  type: NORMAL_ROM
  linear_start_addr: 0x1008000
  physical_start_addr: 0x1008000
  partition_size: 0x80000
  region: EMMC_USER
  storage: HW_STORAGE_EMMC
  boundary_check: true
  is_reserved: false
  operation_type: INVISIBLE
  is_upgradable: false
  empty_boot_needed: false
  reserve: 0x00

В данном случае:

  • Begin Address = 0x1008000
  • Format Length = 0x80000

После этой несложной процедуры телефон вновь будет загружаться в систему. Ну и еще раз, если вам необходимо вернуться к заводским настройкам, делаем Wipe Data / Factory Reset в TWRP.

Обновлено 12.03.2017 02:41 MSK

Выяснилось что существует несколько различных аппаратных ревизий устройства отличающихся типом сканера (наиболее распространена ревизия со сканером второго типа), поэтому если в прошивке от 09.03.2017, выложенной выше, сканер отпечатка по каким-либо причинам у вас не заработал, то для вашей ревизии подойдет следующая прошивка, в которой сканер будет работоспособен - lineage-13.0-20170311-UNOFFICIAL-PowerFiveMax.zip .

Внимание! Материалы приведенные в данной статье размещены в ознакомительных целях. Все действия описанные в данной статье вы осуществляете на свой страх и риск! Автор(ы) статьи не несут ответственности за вышедшее из строя оборудование, в результате ошибочных действий или неверного понимания вами смысла изложенного в ней материала, а также в силу любых прямых и косвенных причин, которые потенциально могут привести к неработоспособности вашего устройства или любым другим проблемам с ним. Если вы не уверены в своих силах, сомневаетесь и т.п. - не выполняйте ничего из вышеописанного. Используя материалы из этой статьи вы соглашаетесь с тем, что ответственность за ваши действия несете вы и только вы.

суббота, 4 марта 2017 г.

Билайн Про 6 и Билайн Fast HD. Опережая время ...

Билайн Про 6. Первый операторский смартфон с Android Nougat.
Не так давно, в обзоре другого аппарата я рассуждал об инновациях и говорил о том, что было бы интересно, если бы кто-то из операторов выпустил брендированное устройство с Android 7.0 Nougat (надо же в конечном итоге следовать духу времени). И вот судя по всему, первый претендент на такую заявку появился. По информации полученной от наших "штатных телепатов", спустя некоторое время в Билайн должны появиться два абсолютно новых аппарата. Это Билайн Про 6 (Beeline Pro 6) и Билайн Fast HD (Beeline Fast HD). Сроки появления новинок и их технические характеристики достоверно пока неизвестны, однако, уже сейчас можно сказать, что новые модели будут построены на уже хорошо знакомом нам по бюджетному сегменту чипе от Mediatek - MT6737M. При этом отличительной особенностью первого девайса, т.е. Билайн Про 6 будет Android Nougat (Android 7.0) на борту. Что же касается технических характеристик новинок, то пока известно лишь очень немногое (к тому же, к моменту появления аппаратов в продаже вполне возможно что что-то изменится, поэтому эту информацию можно рассматривать как ориентировочную):

Билайн Про 6

  • Чипсет: Mediatek MT6737M (Quad Core, 1.3 GHz)
  • Операционная система: Android 7.0 Nougat, 32-bit
  • Производитель устройства: Fortuneship
  • Разрешение экрана: 720x1280 точек (диагональ пока неизвестна)
  • Количество SIM-карт: 2 (форм-фактор слотов пока под вопросом)
  • Объем оперативной памяти: 2 Gb RAM (?)
  • Объем встроенной памяти: неизвестно

Билайн Fast HD

  • Чипсет: Mediatek MT6737M (Quad Core, 1.3 GHz)
  • Операционная система: Android 6.0 Marshmallow, 32-bit
  • Производитель устройства: Fortuneship
  • Разрешение экрана: 720x1280 точек (диагональ пока неизвестна)
  • Количество SIM-карт: 2 (форм-фактор слотов пока под вопросом)
  • Объем оперативной памяти: 2 Gb RAM (?)
  • Объем встроенной памяти: неизвестно

В ближайшем будущем я постараюсь рассказать вам об ожидаемых новинках чуть более подробно, но уже сейчас можно сказать что устройства ожидаются достаточно интересными и составят неплохую конкуренцию имеющимся на рынке брендированным моделям других операторов, ведь, как я и говорил, оператор который первым выпустит "бюджетку" на Nougat'е, как минимум, запомнится пользователям, плюс, использование Android 7.0 в операторском устройстве можно использовать как неплохой рекламный ход, особенно если такой девайс будет единственным на момент выхода в своем сегменте. 

среда, 1 марта 2017 г.

Doogee X5 Max Pro. Lineage 14.1 (Android 7.1.1)

Не так давно, судьба забросила меня на один из околомобильных форумов, где kaito373 и bolt1502 портировали на свое устройство (Doogee X5 Max Pro) мою прошивку от Tele2 Maxi LTE. Все бы ничего, но пообщавшись с владельцами аппарата, выяснилось что помимо всего прочего их аппарат оснащен сканером отпечатка пальца, который ни на одной кастомной прошивке с Android Nougat у них не работал. Чисто по-человечески мне стало интересно, а смогу ли я заставить работать этот сканер в Nougat'е и собрать полноценную LineageOS 14.1 для него. Проблема осложнялась также и тем, что я сам не являюсь владельцем Doogee X5 Max Pro - поэтому задача разработки и тестирования прошивки на порядок усложнялась, т.к. при любых изменениях я должен был дождаться результатов проверки от людей, которые ее устанавливали. Т.е. если что-то не работало пользователи выкладывали логи, затем я анализировал их, что-то правил в исходниках, выкладывал новый релиз, пользователи его проверяли и так до тех пор, пока не удавалось победить ошибку ... Надо сказать что где-то на середине пути (а занимались подобной отладкой мы в общей сложности два дня) я уже думал отказаться от этой идеи, извиниться, что взял на себя такие обязательства и сказать что собрать прошивку "вслепую", не владея самим устройством - это нереально ... Отчасти это утверждение близко к истине, но так или иначе любопытство и игра с самим собой в "А вам слабо?" взяла надо мной вверх и я решил идти до конца.

В результате я все-таки заставил работать MicroArray'евский сканер отпечатка в 7-ом Android, починил запись видео с помощью аппаратных OMX кодеков, исправил ошибку с неработоспособным FM-Radio и сделал полноценное (x64) дерево устройства для Doogee X5 Max Pro - android_device_doogee_x5max_pro. Получившийся релиз прошивки можно забрать здесь - LineageOS 14.1 (x64) [0.1beta]. Там же, в README.md можно найти описание прошивки, краткий FAQ, а также просто некоторые полезные заметки.

* Скриншоты и фото ниже предоставлены пользователем kaito373

Фото аппарата с запущенной прошивкой:


Скриншоты интерфейса:






Тест производительности в Antutu Benchmark:


Обновлено 01.03.2017 (23:43 MSK)

Также доступна сборка Resurection Remix 5.8.2 (x64) на базе Android 7.1.1. Скачать ее можно здесь: RR-N-v5.8.2-20170301-x5max_pro-Unofficial.zip .

Внимание! Материалы приведенные в данной статье размещены в ознакомительных целях. Все действия описанные в данной статье вы осуществляете на свой страх и риск! Автор(ы) статьи не несут ответственности за вышедшее из строя оборудование, в результате ошибочных действий или неверного понимания вами смысла изложенного в ней материала, а также в силу любых прямых и косвенных причин, которые потенциально могут привести к неработоспособности вашего устройства или любым другим проблемам с ним. Если вы не уверены в своих силах, сомневаетесь и т.п. - не выполняйте ничего из вышеописанного. Используя материалы из этой статьи вы соглашаетесь с тем, что ответственность за ваши действия несете вы и только вы.

понедельник, 20 февраля 2017 г.

DNSCrypt for Android: защита DNS-запросов

В этом посте я расскажу о своем коротком опыте использования DNSCrypt для Android. Для тех кто не в курсе что это такое, рекомендую прочитать, например, вот это: Protect: защита DNS-запросов. Речь там правда идет про технологию DNSCrypt, используемую в Яндекс.Браузере, но общий смысл того как защищаются DNS запросы - думаю из нее понятен. Так вот примерно то же самое мы будем делать для нашего смартфона на Android, но не для какого-то определенного приложения, а для всей операционной системы в целом. При этом, я не рассматриваю вопрос использования DNSCrypt на стоковых прошивках, так как зачастую он может потребовать от вас дополнительных действий для того чтобы все это работало автоматически, например, как минимум, получения root-прав, модификации ядра для поддержки init.d или использования приложения Universal Init.d. Вообщем этот путь несколько сложноват ... гораздо проще использовать любую CyanogenMod-based прошивку, в моем случае ей оказалась LineageOS 14, которую я собрал для Tele2 Maxi LTE. Перед тем как мы начнем, давайте ознакомимся со следующими статьями и материалами:


Итак, что мы имеем - Tele2 Maxi LTE с LineageOS 14 и желание попробовать dnscrypt в действии. Я не стал собирать ничего из исходников, а зашел на страницу Downloads проекта dnscrypt и скачал оттуда архив dnscrypt-proxy-android-armv7-a-1.9.4.zip . Она расчитан на armv7a архитектуру, у меня в аппарате правда используется 64-bit'ная ОС, но т.к. CPU, естественно, "понимает" armv7a, то собранный 32-bit'ный бинарник также будет работать. Перед тем как установить этот архив через TWRP или другой кастомный recovery я предлагаю вам открыть его и посмотреть из чего он состоит, т.е. сами бинарники, конфиги и скрипты инициализации которые кладутся в addon.d и init.d. Напомню что CM / Lineage у нас полностью подготовлен для установки этого архива, т.е. после его прошивки с вероятность 99% все заведется.

Посмотрим на скрипт инициализации 99dnscrypt в init.d, последними строками в нем мы видим:

dnscrypt-proxy \
--daemonize \
--loglevel=3 \
--resolver-name="$RESOLVER_NAME" \
--resolvers-list=/system/etc/dnscrypt-proxy/dnscrypt-resolvers.csv && \
iptables -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to-destination 127.0.0.1 && \
iptables -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to-destination 127.0.0.1

Итого ... мы запускаем dnscrypt-proxy в качестве "демона" с резольвером $RESOLVER_NAME (по-умолчанию кстати в скрипте инициализации прописаны dnscrypt.org-fr и okturtles, я бы заменил их на cisco и yandex, первый использует OpenDNS, ну а Yandex в представлении не нуждается), плюс добавляем правила iptables для редиректа всех DNS запросов на наш dnscrypt-proxy.

Перед тем как мы будем разбираться что это, давайте убедимся что все работает. Для этого установим приложение DNS Lookup из Play Market, добавим туда DNS сервер 127.0.0.1 (наш
dnscrypt-proxy) и попробуем разрешить любое имя, например www.decker.su . Если все установлено и работает правильно, то вы получите ответ следующего вида:


Это значит, что вся наша схема работает и DNS Crypt успешно передает шифрованный DNS запрос и отдает нам ответ. Если у вас это так - то поздравляю, если нет - то, печально, и вам нужно разбираться что именно у вас не работает. А я сейчас попытаюсь рассказать как оно должно работать. Для этого я зайду в adb shell и с помощью kill завершу работающий процесс dnscrypt-proxy, чтобы дальше нам уже можно было запустить его вручную с логами и т.п. Т.е. чтобы все было видно наглядно:


Здесь мы запустили dnscrypt-proxy уже в ручную с выбором резольвера "cisco", который использует Cisco OpenDNS. Для проверки того что у нас используется именно этот резольвер и именно OpenDNS откроем страницу теста - http://www.opendns.com/welcome/ в браузере телефона, я запустил Activity браузера прямо с ПК:

adb shell am start -a android.intent.action.VIEW -d http://www.opendns.com/welcome/

Итог:


Здесь мы видим, что сайт определил что мы используем OpenDNS (как я понял резольвер cisco описанный в dnscrypt-resolvers.csv использует именно OpenDNS) в результате чего у нас видна галочка на первом скрине вместо надписи "You aren’t using OpenDNS yet", а второй тест с internetbadguys.com показал нам что защита от фишинговых ресурсов, встроенная в OpenDNS у нас работает на ура. Если вы были внимательны, то наверняка зададите резонный вопрос. Подождите, понятно что dnscrypt-proxy у нас отвечает на 127.0.0.1:53 в телефоне, но почему запросы резольвятся именно через него, а не через DNS серверы вашего WiFi или мобильного подключения? Все дело в тех самых правилах iptables в 99dnscrypt. Давайте посмотрим таблицу NAT:

Как видно, любые DNS запросы на всех интерфейсах у нас заворачиваются на 127.0.0.1 ... счетчик показывает что через правило прошло 145 пакетов. Т.е. было уже 145 обращений к DNS серверам со стороны ОС и все они были пропущены через dnscrypt-proxy. Другими словами, если например какое-то приложение, например, ваш браузер, запрашивает резольвинг имени сервера www.decker.su у дефолтного DNS сервера вашего интернет подключения, то вне зависимости от того какой DNS сервер использует ваше интернет подключение запрос будет перенаправлен к dnscrypt-proxy. Вот такое вот прозрачное "проксирование DNS" и в результате все наши DNS запросы защищены.

Надеюсь после небольшого объяснения и приведенных картинок смысл того что происходит в системе более понятен.

Вообщем-то и все. Единственное что я еще сделал дополнительно, это в файле system/etc/init.d/99dnscrypt изменил два резольвера, которые dnscrypt-proxy пытается использовать по-умолчанию:


p.s. Если прочитав бегло этот пост вы почему-то не захотели вдаваться в технические подробности, а просто установили архив dnscrypt-proxy-android-armv7-a-1.9.4.zip через TWRP и хотите понять работает оно у вас или нет, то просто установите приложение DNS Lookup, как показано выше, и проверьте что сервер 127.0.0.1 отдает у вас имена. Либо воспользуйтесь любым онлайн DNS Leak тестом, например https://www.grc.com/dns/dns.htm или http://dnsleak.com/ :


При этом ни наш интернет-провайдер (если мы подключены через WiFi), ни оператор сотовой связи не видят наших DNS запросов, т.к. они передаются на DNS-сервер с поддержкой DNSCrypt по защищенному каналу. Ну вот как-то так ...

В завершении рекомендую вам прочитать еще одну статью, на этот раз уже на Хабре - Решаем проблему перехвата и подмены DNS-запросов. DNSCrypt в Яндекс.Браузере. Речь в ней опять же идет про Яндекс.Браузер, но у нас как вы понимаете, все описанное в статье, относится не только к браузеру, а к нашей ОС Android полностью, т.к. DNSCrypt в ней работает для всей системы в целом.