Comments 46
UFO landed and left these words here
UFO landed and left these words here
Наконец-то грамотная статья на эту тему. Огромное спасибо. Интересно еще почитать про apktool и smali.
обязательно будет.
apktool — одна из самых полезных утилит при работе с кастомами. 1.3.1 версия исключительно хороша, практически идеальна.
было бы еще интересно как создавать свои прошивки, к примеру для HTC, но который изначально под WM6
Да =) как раз чем-то похожим я и занимаюсь только для читалки нук =)))) Делаем русификацию и портируем FBReader =))))

Кому интересно, могут почитать анонс mynook.ru/rucifikaciya-nook-uzhe-skoro/ =)
не за что) всегда приятно сделать что-нибудь для людей) тем более, если мне это легко +)
Вот у меня появились некоторые проблемы и хочется узнать некоторые вещи =)))

дело в том, что я не могу заменить стандартное приложение, я могу удалить, но вот такое же с таким же пакетом (просто пропатченное через APKTool) переустановить не получается. Вообще не работает adb install проги, которая уже установлена…

стандартные проги я переустанавливаю просто напросто через adb push, но при таком варианте я не могу менять код (smali/backsmali), иначе после такого adb push у меня вообще все виснет и т.д. =)

Что-нибудь известно вам по поводу подобных блокировок?
делаете decode всем пакетам из прошивки.
смотрите какой shared uid у вашего приложения. ищите где он еще используется
Самый простой вариант, когда подпишешь своим ключем, кидай его в /system/apps/ и смотри логкат, он там ругнется что подпись не совпадает, и напишет с какими именно пакетами.
А самое лучшее, берешь прошивку, и переподписываешь ВСЕ пакеты, ключики можно взять тестовые, для media, shared и platform.
хорошо, но там какой-то свой загрузчик и надо его смотреть еще, как разобрать/собрать.

А где берутся тестовые ключики?
Обратите внимание на раздел статьи, относящийся к подписыванию прошивки.
Аналогично подписываете и apk-и
спасибо!
А можно узнать зачем разделение такое сделано в ключах?
Видимо в целях безопасности. Описание по ключам:
testkey — a generic key for packages that do not otherwise specify a key.
platform — a test key for packages that are part of the core platform.
shared — a test key for things that are shared in the home/contacts process.
media — a test key for packages that are part of the media/download system.
А потом имеешь проблемы с обновлением маркета (Vending) и прочих гугломапов.
Но можно и так. Я тоже так сперва делал.
о господи. Вы почитайте мой первый пост. я хакаю читалку =) какой маркет?))))
ну у меня живого устройства нет. Я не знаю какие там приложения идут в комплекте.
У меня никаких проблем с маркетом не было. Просто не трогаешь все что относится к маркету.
вот в том-то и дело, что в логкат ничего не пишется. у меня такое ощущение, что все было вырезано из логката на этой железке =)
«Пропатченное через apktool» это очень странное описание. apktool не умеет патчить. Но с его помощью можно разобрать приложение и собрать обратно.
1. После сборки нужно будет его подписать.
2. Если данное приложение использует shared uid, то нужно также подписать все другие приложения, его использующие, иначе приложение не будет принято системой из-за несовпадения сертификатов
3. Если приложение было с .odex-ом, то другие приложения, использовавшие его перестанут работать. Их также необходимо deodex-снуть.
4. Убедиться что в собранном вами приложении имеется classes.dex

А вообще adb logcat во push-а очень хорошо показывает какая именно проблема.

Об этих проблемах и путях обхода я собираюсь рассказать в будущих частях.
1 — подпись не помогает
3 — нет никаких odex
4 — все файлы на месте

пропатченное через apktool — это распакованное, поменянное, собранное +)

дело в том, что adb lolcat ничего не пишет — все просто виснет. причем adb push проходит и заканчивается успешно. Причем это все происходит только при пересборке classes.dex.

надо поковыряться с этими shared uid
Хм. Обрадовали. Пока не сильно хочется шить официал(который может быть на неделе уже будет..). Наслышан, что после обновления нельзя будет шить кастомы. сначала попробую с самопалом поиграться, а там поглядим на поведение htc ;))

и вот как раз вопрос. не сталкивались с этой защитой от кастомных прошивок? ее обходить можно будет?
«Нельзя будет шиться» это как раз ситуация, если вы воспользовались RUU/OTA прошивкой, которая записала hboot/recovery. Упоминается в статье.
Новые версии hboot обычно закрывают експлоиты, с помощью которых были изначально получены права суперпользователя на телефоне. И иногда отключают возможность понижения версии прошивки, что закрывает путь к откату на старую версию с известным эксплоитом.
и забыл.
Я глубоко уверен, что «защита от кастомов» это миф, рожденный от того, что различные разработчики кастомов использовали некорректный fingerprint для телефона, что приводило к тому, что из маркета пропадали платные и drm (не обязательно платные) приложения. Google производит фильтрацию доступных приложений по базе «разрешенных fingerprint». По крайней мере на данном этапе это так. Не исключено, что этот механизм может измениться.
Правильно ли я понимаю, что при перепрошивке на более новую версию, необходимо перенести «драйверы распространяющиеся в бинарном виде (wifi/gps/fm)»? Тогда почему возникают сложности у производителей устройств с новыми версиями Android? В чем именно затык??
С новыми версиями обычно обновляется линукс ядро. Новый abi — значит нужно закрытые драйверы адаптировать под него.
Также с новыми версиями меняется и сам фреймворк андроидовский. Производителям телефонов нужно адаптировать свои наработки под него. Интегрировать новые фишки системы в свои интефрейсы.
А когда изменения от производителя масштабные (например HTC Sense) — таких адаптаций много.

Ну и не исключаем маркетинг. Новые устройства нужно тоже продавать =)
А не подскажите как происходит адаптация драйверов, например с WinMo? Т.е. их дизасемблируют и пишут с нуля непосредственно на Андройд? Можете про это рассказать?
Ух. Не могу рассказать. не имею опыта.
По сути тут нужен серьезный реверсинжениринг. Есть также малый шанс, что уже существует открытая версия драйвера для самого устройства, либо его архитектурного аналога/предшественника.
Читаю коменты и ужасаюсь — какие нехилые проблемы 'созданы' подписыванием, закрытием кода и не только для модификации приложений. И все это при использовании открытых лицензий. Все никак не соберусь разобрать причины, почему вообще разрешается использовать в готовых устройствах комбинации закрытых блобов (драйвера и приложения) и открытого кода, при условии что лицензия не является аналогом LGPL (ядро GPL2).
* причины в наличии каких то юридических лазейках лицензии ядра GPL2 (и на 3-тью переводить никто не собирается)? но это для ядра, а что закрытые приложения, которые формально линкуют, а неформально жестко завязаны на открытом коде?
* что является причиной наличия радиоблоба (драйвера и библиотеки для работы с радиомодулем)? какие то ограничения ОпСоСов? Это как то регулируется на законодательном уровне? Раздолбайство или я просто чего то не знаю и уже давно есть полностью открытый код для работы хоть с какими-либо устройствами — доступными как комплектующие?

P.S. Все никак не соберусь, хотелось совсем немного 'поправить перевод' и может быть немного способ отображения текста (наименование типа номера в контакте) в диалере, так как в русском переводе это название вместо Call to:work красуется бессмысленное и широкое Позвонить по номеру:... в вертикальной ориентации. Для этой примитивной с точки зрения разработки правки необходимо совершить действия сравнимые по трудоемкости чуть ли не взлому защиты средней программы, начиная от реверсинженеринга и заканчивая изучения десятка утилит по перепаковке, подписывания, и поиска способов исправления появившихся странных глюков вида 'исчезание некоторых приложений из маркета'.

Кажется что то не то в мире происходит с открытым кодом, linux и мобильными технологиями… не развитие это!
Ну. Производители пытаются работать по старой схеме к которой они привыкли. Все своё — никому не. Не уверен, на сколько там действительно есть что скрывать от конкурентов. Потому и радио-модуль распростроняется в виде бинарника.
Подписывание пакетов — на самом деле здравый механизм. С одной стороны проверка на валидность и целостность пакета, с другой — защита от подмены источника пакета. Никто ведь не жалуется на сертификаты в ssl.
Если нужно — можно подписать все тестовыми ключами, или своими — что и будет говорить «поставщик — я». Другое дело, что для пользователя такого кастома это ни разу не удобно ждать вашей перепаковки обновления, когда оно выйдет. Ему удобнее обновиться из оффициального источника, а вот тут конфликт смешивания разных «поставщиков».
Если вы хотите исправить оригинальный диалер (не HTC) — то ничто не мешает собрать его из исходников и сделать идеальным. Правда, когда я исправлял диалер от Sprint CDMA для GSM, это потянуло на переподписывание 20 пакетов (хотя сейчас мне кажется, что используя один трик можно было бы избежать этого).
Only those users with full accounts are able to leave comments. Log in, please.