Обычно на Пикабу я тестирую лампы, сегодня хочется поговорить про них максимально просто и понятно.
Разбираю я лампочки давно. Прям много лет уже и, честно говоря, это напоминает постоянный поиск компромиссов. На 10 протестированных лампочек приходится только одна, которая более-менее неплохая.
Ну и, казалось бы, это просто лампочка, фиг бы с ним, как-то светит и ладно, зачем париться? А дело в том, что свет не такой уж безопасный как нам кажется. По ссылочке найдете статью, что пугает сбитыми циклами дня и ночи, головными болями, усталостями и провокациями разных очень плохих болячек.
Я не медик, но давайте поговорим про это на бытовом уровне. Вот мы - люди, эволюционно развивались под светом Солнца (вскоре будем эволюционировать под светом монитора, но еще есть время). Вся наша тысячами лет подстраивалась именно под такой спектр излучения.
Вроде логично, значит нам нужны лампы, которые максимально похожи по своим спектральным свойствам на наше светило.
Таким образом (очень упрощенно и именно для нашего контекста), вводится величина которая характеризует похожесть этого вот излучения лампы на излучение солнышка. И она называется индексом цветопередачи - или Cri (Ra), является безразмерной величиной и измеряется от 0-100. Хороший индекс цветопередачи начинается с 90, в лампах же сегодня мы наблюдаем в основном индекс равный 80. Но иногда попадаются и неплохие экземпляры.
Индекс цветопередачи - это конечно хорошо, но наш естественный источник света имеет очень разные свои спектральные характеристики и сам по себе, например, цветовая температура.
И правда, индекс цветопередачи привязан к цветовой температуре, условно он без нее не имеет особенного смысла, так как это значение становится конем в вакууме. И эту штуку тоже я измеряю.
Видите дугу на этой, так называемой, диаграмме цветности? Вот она называется дугой абсолютно черного тела.
Не будем углубляться в понятия, но я всегда находил забавным что спектр абсолютно черного тела теоретический, а наиболее близким к нему физическим объектом является Солнце.
Когда я измеряю спектр излучения лампы (точка на диаграмме), она должна бы попадать на эту дугу, иначе излучение от нее нельзя назвать естественным.
На удивление, тут обычно производители не косячат.
Прекрасно, а что еще в этих лампах есть? Ну например излучение. Оно вообще как бы непрерывное или как лазер из звездных волн запускает импульсы? Вот у Солнышка вполне непрерывное. А у ламп что?
И тут, конечно, проблема. Лампочки светодиодные выдают свет именно условными импульсами (да-да, это бластеры). А задача вашего мозга при этом сгладить такую картинку и сделать из нее удобоваримую. Чтобы все было гладенько. Конечно же это тоже надо измерять - это называется коэффициентом пульсации.
С ним не все так просто, ведь если пульсации большие, но при этом их частота велика, то вроде как мозгу и хорошо, потому придумали целую диаграмму для понимания что хорошо, а что - нет.
Я почти закончил.
Есть еще такая штука как световой поток. При прочих равных, это то, сколько света даст лампа. фактически представьте что лампочку запихивают в некий объем с датчиками которые понимают сколько света с нее приходят на заданную площадь и потом выдают их интегральную величину.
И эту штуку тоже надо мерить и проверять - тут производители очень часто обманывают.
Вот вроде быстренько мы и прошлись по световым характеристикам ламп. Да, лампочка с виду устройство простое. Оно и правда простое. Но при этом, данная вещь всегда присутствует в нашей жизни. Так уж получилось. Подходите к выбору их с умом.
С момента выхода первой части статьи из рубрики «сам себе экосистема» прошёл уже практически год! За это время, мы успели с вами реализовать клиенты VK и YouTube, которые работают на Android 2.2+, а также на Windows Phone 8, написать небольшую 2D-игру с нуля весом менее 1Мб, которая работает практически везде и довести существующее приложение до ума, дабы оно работало даже на смартфоне с дисплеем 240x320! Но на дворе 2024 год, люди стремительно переходят из соц. сетей в продвинутые мессенджеры и уже сложно себе представить современного человека, который не пользовался бы «телегой» или даже «вайбером» в качестве основного средства общения. Поэтому я решил реализовать клиент Telegram на смартфоне 14-летней давности на базе официальной реализации MTProto от команды Telegram — TDLib. Сегодня мы с вами: узнаем новые причины мотивации вернуть в строй смартфоны прошлых лет, напишем на C# реле-сервер, который обрабатывает пакеты MTProto и кодирует их в простой текстовый формат датасетов, который можно моментально обработать даже при нестабильном GPRS-соединении на 21-летнем Siemens C60, а также узнаем о разработке миниатюрных Android-приложений на базе «голого» API-системы, которые не тянут за собой никаких зависимостей, в том числе и AppCompat/androidx. Интересно? Тогда жду вас под катом!
На дворе уже стукнул 2024 год, современные смартфоны предлагают какие-то немыслимые мощности относительно тех, которые когда-то были в первых Android-девайсах. Сейчас за сотню баксов можно купить смартфон с хорошей 1080p IPS-матрицей, 4Гб ОЗУ и 8-ядерным шустрым чипсетом, который вполне способен плавно тянуть даже стремительно «жиреющие» на ресурсы клиенты социальных сетей, банков и прочие необходимые в повседневной жизни приложения. И казалось бы: всё хорошо, покупай себе редмик раз в год или айфон раз в несколько лет и наслаждайся всеми прелестями работы современных приложений…
Для многих людей смартфон — это лишь инструмент, повседневный компаньон, который помогает облегчить выполнение каких-то задач. Им совершенно не важно, как он выглядит, как ощущается в руках, какой у него дисплей и железо «под капотом», лишь бы работал да и нормально. Но есть и другая категория людей, для которых телефоны, смартфоны и любые портативные гаджеты — это не просто утилитарный девайс, а настоящее инженерное произведение искусства, с которого буквально сдувают пылинки и стараются до последнего пользоваться ими как повседневными устройствами. Хотите пример? Смотрите ниже:
Фактически, среди современных смартфонов по сути и нет представителей такого нынче вымершего форм-фактора, как сайдслайдеры с физической QWERTY-клавиатурой, боковые раскладушки с двумя дисплеями и даже из QWERTY-моноблоков есть только смартфоны от Unihertz. Даже среди моноблоков с тачскринами нет никакого разнообразия, лишь без-рамочные одинаковые девайсы за исключением устройств от Sony.
Galaxy S Plus
Раньше меня часто спрашивали, мол, да как ты вообще можешь пользоваться смартфоном 10-летней давности, на котором давно нет официальных клиентов популярных сервисов и только недавно, с развитием блога, мне перестали задавать этот вопрос, поняв, что это бесполезно — ведь это дело принципа и порыва энтузиазма! Смотрите сами: у нас уже есть простенькие, но вполне рабочие клиенты ВК, YouTube, сейчас я допиливаю клиент «Сбера» на СМСках, реализую карты OpenStreetMap (правда пока без адекватной навигации), а в будущем планирую написать приложение для мониторинга погоды и трекинга посылок. Кроме того, в рамках этой статьи мы реализуем с вами клиент Telegram: так чем же это не функционал современного смартфона?
Но хорошо, с функционалом разобрались, однако для многих читателей слова «старый смартфон» это прямые синонимы «тормозной смартфон», мол «фуу, да как можно пользоваться этим тормозным кирпичом, он же лагает в последней версии моей ВКшечки!». Но давайте поставим вопрос ребром: может, это не столько девайсы немощные, сколько сами приложения, с кодовой базой, которая тянется более 10 лет, откровенно жиреют, обрастают костылями и хаками после далеко не одного поколения программистов, которые над ними работали? :) Один, вот, предпочитал пользоваться чистым AppCompat'ом, другой решил притащить зависимость, которая, например, оптимизирует виртуализацию ListView, третий решил заменить всю сериализацию Json со встроенных классов в Android на что-то стороннее и реализовал это костылями и вот так, по чуть-чуть изначально оптимальный и шустрый код превращается в неповоротливое УГ, которое не рефакторили кучу лет.
На видео Galaxy Pocket Neo — очень дешёвый Android-смартфон из 2011 года с 1-ядерным чипсетом на ~800МГц и 256Мб ОЗУ. При этом всём, Android софтварно рисует все анимации на процессоре, без участия GPU.
А значит у стареньких девайсов всё равно есть шанс быть полезными и стать полноценными повседневными смартфонами даже спустя более чем десять лет после выхода! И в сегодняшнем материале, я вам расскажу об особенностях разработки самопального клиента Telegram с собственным прокси-сервером, которое концептуально допускает реализацию даже на кнопочном Siemens C60 2003 года. Как? Читаем ниже!
❯ Принцип работы
В отличии от ВК (который разрабатывали те же самые люди, что и Telegram), API которого построено на базе REST-запросов и концепции Longpolling'а для моментального получения событий с сервера, Telegram построен на базе собственного протокола под названием MTProto, который может работать поверх любого «транспорта» (протокола нижнего уровня) — TCP, HTTP, WebSocket и т.п. Сам по себе MTProto в современном виде, разработка прожженного математика Николая Дурова и его команды — протокол относительно сложный для реализации «на коленке» и в первую очередь требует довольно серьезного понимания принципов работы современной криптографии, да и документирован он всё ещё не особо хорошо. Кроме того, у MTProto весьма интересный бинарный формат пакетов, эдакий велосипед Protobuf. В долгосрочной перспективе поддерживать свой велосипед MTProto может быть весьма проблематично, учитывая не самую лучшую документацию.
Но городить велосипед и не нужно, поскольку у команды Telegram есть официальная реализация MTProto — библиотека TDLib, которая инкапсулирует в себе не только детали реализации протокола, но и сетевой ввод/вывод и выбор транспорта, хранение базы данных сообщений и авторизации, автоматическую загрузку фото и видео, конвертация объектов из бинарного формата MTProto в JSON и полная многопоточность и частичная потоко-безопасность. С одной стороны это плюс — уже готовое решение для реализации клиента на новой поддерживаемой платформе, где есть OpenSSL (можно статически слинковать), zlib (линкуется статически), сокеты и файловый ввод/вывод, а также довольно неплохой механизм JSON-based API, которое позволяет использовать библиотеку в любом языке, который поддерживает вызов C-функций, а с другой и минус — библиотека довольно много весит, в одиночку прибавляя ~20Мб веса приложения для каждой архитектуры, у неё течёт память и у нее странный механизм получения данных с сервера (например, нельзя ответить на сообщение, зная его ID, если сообщение предварительно не загружено, при том что на сервере весь ответ — это просто ID, на какое сообщение прилетел ответ).
Понятное дело, что на стареньком смартфоне использовать оригинальный TDLib будет проблематичным — даже если собрать либы современным NDK и запилить JNI-интерфейс, библиотека «жрёт» много ОЗУ (20-100Мб «вхолостую», в зависимости от числа диалогов и частоты прилетающих событий, плюс со временем течет до 1-2Гб, если не использовать базу данных сообщений. Скорее всего, это косяк в реализации пулов, объекты из которых выгружаются при сбросе в базу, но не выгружаются при высоком потреблении ОЗУ) и уж тем-более TDLib не запустить на любимых кнопочных Java-сонериках! Поэтому я решил написать прокси-сервер, который отправляет команды, слушает ивенты TDLib и предоставляет REST-like API для клиентских программ, которые просто вызывают какой-либо метод, а в ответ получают простой и короткий строковой датасет только с необходимыми полями, весом до 10Кб (что позволяет его быстро загрузить даже с GPRS-интернетом), который можно быстро распарсить даже на преусловутом Siemens C60!
К сожалению, поскольку TDLib прожорлив, я не смогу захостить на своём сервере инстансы для читателей, которые хотят поюзать приложение, поэтому вам придется ставить и запускать сервер на своём VDS/компьютере с белым IP/роутере, если под него есть .NET Core :)
Клиентом же будет выступать Android-смартфон, где приложение будет фронтэндом данных с сервера. Ничего сложного на первое время нет: первое окно — это список диалогов, второе окно — список сообщений в диалоге + поле для написания сообщения, третье окно — информация о пользователе. Всё это я реализовал за три дня не-напряжной работы «на коленке».
Давайте же перейдем к реализации сервера!
❯ Прокси-сервер
Сервер я решил писать на C#, поскольку у .NET Core сейчас всё очень хорошо с кроссплатформенностью и производительностью. Его можно даже на Raspberry Pi запустить :)
Итак, какая-же архитектура такого сервера может быть? Программа инициализирует TDLib, начинает слушать её события в отдельном потоке, пока в основном потоке крутится HTTP-сервер, который обрабатывает каждый отдельный запрос с клиентского приложения. Почему синхронно? Потому что TDLib фактически не возвращает никаких идентификаторов для возвращаемых датасетов, дабы их можно было отличить друг от друга. Приведу пример: у нас есть метод getChatHistory, который возвращает n-сообщений. При этом TDLib сам определяет, сколько хочет сообщений вернуть (и в первый вызов возвращает одно сообщение вне зависимости от настрое и отправляем пакет message n-раз. При этом в пакете message нет какого-либо ID, который позволял бы ассоциировать текущий объект с какой-либо операцией. Увы!
Начинаем с коммуникации с TDLib. Для работы с библиотекой, мы будем использовать json-интерфейс. Для .NET есть биндинги через C++/CLI, но в таком случае, сервер не будет работать на Linux. Для работы с библиотекой хватит лишь три функции: CreateClientID, которая аллокейтит новый инстанс клиента, Send, которая асинхронно отправляет JSON-объект с командой, которую затем обработает TDLib и Receive, которая ждёт N-секунд и возвращает в виде ASCII-строки (!) JSON-объект с описанием события или данными после одного из запросов. За это у нас отвечает класс TDLibInterface, который объявляет PInvoke-методы для вызова нативных методов из библиотеки. .NET Core сам подгрузит библиотеку tdjson (причём на Linux он добавит ей префикс а-ля libtdjson.so, а на Windows загрузит tdjson.dll) и сам разберется с маршаллингом аргументов функций: например, string автоматически преобразует в const char*. Тем не менее, с const char* возвратами нужно быть аккуратнее — у меня был SIGSEGV, пока я ручками не конвертировал их в обычную строку.
З.Ы: На Пикабу нет отдельного тега для кода, а вставить листинги картинками я не могу из-за ограничения на 25 медиаэлементов. Так что листинги будут совсем без табов, но алгоритм их работы понять можно :)
Позволю себе чуточку критики в сторону TDLib. Во первых, почему нет s-версии функции с возможностью указать длину входной строки, а tdjson полагается исключительно на \0 в конце строки? Во вторых, почему const char*, а не wchar_t*? Сейчас юникод во входной строке приходится escape'ами превращать в \u-последовательности. После этого, нам нужно написать обёртку над TDLib, которая будет вызывать для зарегистрированных событий специальные функции, называемые коллбэками. При этом закомментированный WriteLine снизу — это «дебаг» для того, чтобы узнать названия неизвестных мне ивентов :)
В каждом объекте, полученном с помощью receive, есть поле "@type", которое содержит в себе имя класса возвращаемого объекта. Первый же вопрос от читателей — почему я использую JObject с ручным дерганьем нужных полей и вручную пишу JSON в виде строковых литералов вместо нормальной сериализации/десериализации? Ответ прост: во-первых, для актуализации Data-классов придется писать кодогенератор из TL-схемы, а во-вторых иногда TDLib может возвращать немного разные объекты в JSON, из-за чего приходится мудрить с атрибутами на этих самых Data-классах, иначе десериализатор выбросит исключение. Это решается нормальными юнит-тестами на всех вариантах данных, но зачем себе в колени стрелять, если нужен конкретный фиксированный функционал и лишь малое число от всех полей, возвращаемых TDLib?
string recv = NativeInterface.Receive(10.0d);
if (recv != null) { JObject json = JObject.Parse(recv);
if (!handlers.ContainsKey(type)) { //Console.WriteLine("Unknown event type: {0}", type); continue; }
handlers[type](recv, json); }
Теперь переходим к самому интересному — обработке событий и реализации синхронного клиента, который позволяет без async/await просто запросить список сообщений и сразу же его получить (такой подход может быть полезен и юзерботам, которые не хотят размазывать стейты по всей программе). Почему без асинков? Честно сказать, мне они просто не нравятся: как привык к концепции wait/notify и коллбэков из Java, так их и юзаю всю жизнь :)
Сначала TDLib запрашивает параметры инициализации (стейт authorizationStateWaitTdlibParameters), затем если пользователь не авторизован — запрашивает номер телефона и код подтверждения (плюс дополнительные шаги для авторизации если они есть). В конце, TDLib возвращает стейт Ready, что означает готовность библиотеки к работе:
После этого, можно начать работу с данными. Обратите внимание, мой подход потоко-небезопасен, его нельзя дергать из нескольких потоков одновременно! В коде ниже, я вызываю метод для фетча сообщений, а затем в соответствующем коллбэке от TDLib обрабатываю данные (дабы статья не разрасталась на 20+ минут, я чуть урезал все листинги).
public List<Message> QueryMessagesInChat(long chatId, long lastMessage, int count) { messages.Clear();
public User QueryUser(long userId) { string json = Utils.Format("{\"@type\": \"getUser\", \"user_id\": \"{0}\" }", userId); NativeInterface.Send(InstanceID, json);
waitHandle.WaitOne(); return user; }
Переходим к реализации самого сервера, для наших целей хватит обычного HttpListener. Сначала мы зарегистрируем все поддерживаемые методы и занесем их в ассоциативный список ключ-значение. Сами методы реализованы в виде делегатов, которые принимают лишь один аргумент — список параметров из строки запроса, а возвращают строку — все ответы, за исключением особых (связанных с загрузкой вложений) — текстовые.
Переходим к обработке запроса. Метод ищет, зарегистрирован ли запрошенный метод и если да, то парсит строку запроса, которая начинается с "?", которую затем передаёт в виде коллекции ключ->значения обработчику метода:
А сами методы, в свою очередь, дергают соответствующие функции из клиента и формируют на их основе датасет в примитивном формате:
public staticstring QueryChats(Dictionary<string, string> args) { if(args.ContainsKey("count")) { int count = int.Parse(args["count"]); StringBuilder ret = new StringBuilder();
В результате получаем вот такой простой датасет, который, как я и говорил, легко распарсить и на Siemens C60, и на Atmega328 — да где угодно! В целом, такой сервер можно использовать для реализации бота в телеграме, который будет передавать показания каких-то датчиков, сигнализацию и прочие клевые штуки!
Переходим к реализации клиента, т.е. приложения на Android. Здесь будет не менее интересно!
❯ Пилим для Android
В геймдеве есть своеобразный мем — некоторые инди-разработчики сначала начинают делать меню, вместо основного геймплея, что становится предметом насмешек среди других разработчиков. Но в разработке приложений для смартфонов всё по другому — здесь как-раз таки хорошо заранее продумывать макет будущего приложения!
Поскольку у нас с вами мессенджер, то главный экран должен представлять из себя список чатов (ListView) и верхнюю панельку, где в будущем могут разместиться настройки и свайп-менюшка:
Такой вот простой макет.
Каждый пункт меню — это тоже отдельный layout, в котором мы по шаблону строим внешний вид будущего элемента списка. На немолодых устройствах есть смысл использовать как можно меньше контейнеров в layout'е, поскольку пересчет позиций и размеров элементов — одна из самых «тяжелых» операций в UI-фреймворке вообще. Кроме того, не стоит использовать кучу картинок и drawable — в Android 2.x всё 2D рисуется софтварно, аппаратное ускорение появилось только в 3.0 (частично).
Но дабы в списке диалогов что-то появилось, нужно сначала реализовать фетчинг (получение) этих самых диалогов с сервера! Сам объект, который занимается обработкой запросов называется ClientManager и является синглтоном — он в единственном экземпляре на все время работы программы. Помимо менеджмента «ноды» (т.е. прокси-сервера), токена для авторизации и обработчика ошибок, ClientManager реализует метод для асинхронного запроса информации с сервера и, собственно, формирует строки запросов с помощью соответствующих методов:
Подгрузка чатов и сообщений реализована через Adapter — концепция «виртуальных» списков, которая предполагает что система создаст не 50 элементов интерфейса на каждую кнопку чата, а только 5 и будет их виртуально «мотать по кругу», обновляя только данные в уже существующих элементах. Это позволяет значительно ускорить отрисовку, учитывая то, что Android 2.x Canvas рисуется программно.
Ну вы уже явно замучились видеть простыни кода, давайте посмотрим что у нас вышло!
Шустренько, да? А ведь это ультрабюджетник Alcatel OT-916D, один из последних массовых дешевых QWERTY-смартфонов за 5 000 рублей из 2012 года. Кстати, смартфон подарил мне читатель chuvakoff с Хабра!
Переходим к окну чата. Основной макет почти такой-же, как и у основного окна: только добавилась панелька для ввода сообщения снизу.
Концептуально, всё тоже самое — запрашиваем данные с сервера, парсим их и загружаем в адаптер, благодаря чему мы сможем листать наш диалог. Однако в сообщения я добавил контекстное меню с стандартными фишками типа копирования, ответа и прочих подобных действий. Поскольку у нас нет ни пушей, ни еще каких-либо средств для поулчения данных о новых сообщениях, я раз в определенный интервал просто получаю сообщения — и если новый датасет отличается от старого — обновляю окошко чата.
Переходим к реализации поля для ввода сообщения. Здесь всё просто — на серверсайде за это отвечает метод SendMessage. Однако для того, чтобы с нашего клиента можно было ответить на другие сообщения, я ввёл также «контекст ответа», в котором запоминается сообщение, на которое мы хотим ответить. Telegram также поддерживает Markdown, однако его полная поддержка пока не реализована.
В остальном же, функционал конечно пока совсем базовый, однако клиент работает очень шустро даже бюджетной X10 Mini Pro и позволяет чатится с моими читателями в Telegram. В будущем хотелось бы допилить:
Поддержка картинок: Сейчас уже есть кривоватый механизм кэширования изображений на стороне сервера, который позволяет загружать аватарки чатов. В будущем, я добавлю поддержку «галерей» с картинками!
Поддержка голосовых сообщений: Не все их любят, но они порой удобны и выручают. Реализую как прослушивание, так и запись!
Подробный просмотр профилей и менеджмент чатов: Удаление сообщений, чатов и прочие фишечки из официальных клиентов.
Казалось бы — до официальных клиентов ещё очень далеко. Но сам факт, чтобы всё это работало достаточно шустро на девайсах, которым уже более 10 лет!
❯ Звучит интересно! Как заюзать твой клиент?
Тут всё очень и очень просто! В первую очередь, нам понадобится ПК с белым IP, роутер (если под него есть сборка dotnet), либо VDS. Виртуальные сервера сейчас стоят копейки, у ТаймВеба есть тариф за 188 рублей в месяц, которого с головой хватит для нашего сервера.
Такая вот рекламная интеграция (к слову, прокси для всех приложений уже более года крутятся именно на мощностях TimeWeb Cloud)!
Программа сначала запросит номер телефона, а затем код подтверждения Telegram. После этого будет создана папка tdlib/, где будут хранится данные вашей сессии, а также файл authkey.txt, где хранится случайный ключ для сессии (md5 phone_number + response code + псевдослучайное число). Не оставляйте его в /var/www/!
Если всё нормально, программа начнёт слушать порт 13377 на всех сетевых интерфейсах, в т.ч и в локальной сети. После этого, ставим уже предварительно собранный, либо собираем сами в Android Studio APK и в окне авторизации пишем адрес ноды и ключ авторизации. Если всё настроено верно — программа запомнит сервер и будет работать без проблем! Вот так всё легко :) Как видите — всё очень и очень просто!
Кроме того, буквально за пару дней до публикации статьи я сел вечерком из интереса что-нить под Java-телефоны попилить… и, как и обещал, реализовал Proof of Concept возможности работы Telegram даже на сонериках, которым скоро 20 лет стукнет! А ведь если ещё чуть заморочится, можно запустить приложение даже на преусловутых монохромных сименсах!
❯ Заключение
Вот такой у нас получился проект с реализацией лёгкого, примитивного, но тем не менее рабочего клиента Telegram, который на клиентской части вообще не использует никаких зависимостей. Вес собранного APK в release-версии — всего 54 килобайта! Понятное дело что с ростом функционала, вес программы будет увеличиваться, но я обещаю — больше 1Мб он не вырастет :)
Ну а вам, моим читателям, надеюсь было интересно прочитать такой «двойной материал» не только о разработке сетевой части без использования Apache/nginx/IIS, но и UI-фронтэнда для Android-смартфонов, которым уже более 10 лет! Исходный код проекта можно найти на моём GitHub: как приложения, так и сервера, а также убедиться в отсутствии каких либо закладок и, если совсем не доверяете, собрать бинарники сами! Для сборки понадобится VS2017 или свежее, а также Android Studio 2.3.2 (если собираете для Android 2.1 и ниже).
Друзья! Сейчас на Хабре опросы сломаны, поэтому если у вас есть желание, вы можете проголосовать в комментариях: какой стиль статей вам больше нравится — где больше конкретики и кода с пояснением как конкретно работает та или иная часть программы, или наоборот стиль ближе к научпопу, где фрагментов кода нет, или их значительно меньше? Пишите своё мнение о проекте в комментариях!
Кроме того, у меня есть канал в Telegram, куда я публикую бэкстейдж статей, ссылки на новый материал, свои наработки, а также посты о ремонте девайсов и различные мысли.
Статья подготовлена при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, чтобы не пропускать новые статьи каждую неделю!
Моддинг-сцена с разработкой и портированием кастомных прошивок для Android-устройств существует вот уже более 10 лет. В основном, энтузиасты пытаются проапгрейдить свои устройства путем портирования более свежих версий Android, чем предлагает производитель девайса. Чего уж говорить, если Galaxy S III, которому уже 12 лет стукнуло, получил неофициальный апгрейд до Android 14. Порой мне в голову приходят различные, весьма странные моддерские мысли: например, почему бы не портировать на старенький смартфон… ещё более старую версию Android, дабы посмотреть «что будет». Казалось бы «портировал и портировал», но в процессе работы я столкнулся с множеством интересных нюансов и особенностей работы Android, о которых хотел бы рассказать и вам — моим читателям! Сегодняшняя статья будет в классическом «научпоп»-стиле без кода, зато с подробными объяснениями одной из техник портирования Android-прошивок путем патчинга скриптов для конфигурации системы и подмены Board-specific библиотек, дабы система «увидела» всё необходимое железо! Интересно? Тогда жду вас под катом!
❯ Мотивация
У меня, как и у многих моих читателей, одной из первых версией Android в жизни была 2.x. Наверное, я уже никогда не смогу забыть первые впечатления от использования своего новенького, пусть и бюджетного и слабого Android-смартфона после простеньких китайских кнопочников. Эти ощущения были прекрасными: вот я разблокирую смартфон, потянув «замочек» вправо, свайпаю рабочие столы и тапаю на значок приложения браузера, выполненный в стиле скевоморфизма, загружаю полноценную страницу Википедии через GPRS-сеть (мой первый смартфон не имел 3G) и плавно скроллю страницу, не забывая смахнуть шторку вниз и проверить статус уведомлений в пока ещё совсем простенькой панели нотификаций… Это были по настоящему ламповые впечатления, которые не смог превзойти ни один современный девайс: ни AOSP, ни MIUI, ни OneUI.
Моим первым смартфоном была китайская реплика Samsung Galaxy S III Mini, купленная в самом начале 2013 года. Возможно, кто-то из вас помнит, как подобные дешевые смартфоны и планшеты «Sumsanc» можно было купить на рыночных развалах, в метро и прочих местах, где допускается торговать несертифицированными гаджетами. Даже с учётом накрутки, эти смартфоны стоили всего 2 000 рублей, что было просто «подарком» для цены абсолютно нового гаджета. Девайс был крайне простым для начала 2013 года и имел следующие характеристики:
Процессор: Spreadtrum SC6820. Одно ядро Cortex-A5 на частоте до 1ГГц, Mali400 MP в качестве GPU. Чипсет был крайне высоко-интегрированным для своих лет: в одном корпусе располагалось ARM-ядро, GPU, контроллер питания, GPS, множество периферии (например, DAC), а также Baseband-часть GSM-радиотракта. BT/Wi-Fi реализовывались в отдельном комбочипе разработки RDA.
Память: 256Мб DDR1 ОЗУ/256Мб NAND-памяти в одном чипе eMCP от Hynix. Предположительно, эти чипы остались на складах ещё со времен первых Android-смартфонов, но очень быстро потеряли актуальность и их, вероятно, отдавали «за бесценок» что позволило ещё сильнее снизить цену производства таких смартфонов.
Дисплей: безоговорочно, TFT, обычно с разрешением не выше 480x320, что для 3" дисплея было нормальным, но для 5" — уже несколько маловато. Тем не менее, сами дисплеи были нормальными и глаза от них не «вытекали». Тачскрин обычно ёмкостной, на 2 касания.
Android: 2.2, на некоторых похожих моделях встречался 2.3.
Аккумулятор: ~1.500мАч, не больше. По форм-фактору напоминает BP-4L, без проблем подходит от многих S60 смартфонов Nokia тех лет.
Не густо, да? Уже в апреле того же года вышел Galaxy S4 с Snapdragon 600, 2Гб ОЗУ и 32Гб встроенной памяти, а мы тут с одноядерным чипсетом и 256Мб ОЗУ сидим. Но мне, будучи школяром, это было за счастье — чего я на нём только не делал, и на PHP какие-то WAP-сайты динамические пытался писать и на FTP заливать, и даже ADT Bundle скачал, дабы попытаться что-то своё запилить под собственный смартфон! В общем, я был счастлив, несмотря на лаги девайса. Именно того девайса у меня уже давным-давно не осталось… но память я всё ещё храню и стараюсь дать новый дом таким китайчикам, которые в большинстве своем оказались на свалке истории в новом мире современных смартфонов!
Но на самом деле, смартфоны 10+ летней давности могут быть интересны и своим форм-фактором: в современном мире едва ли можно найти хоть какие-то телефоны с полноценной QWERTY-клавиатурой (исключение — смартфоны UniHertz, которые стоят недешево) и уж тем более, боковые слайдеры. Поэтому мой интерес к подобным девайсам очень легко объяснить!
Однако, порой мне самому хочется снова пережить эти эмоции и ещё раз походить с подобным девайсом «на каждый день», даже когда на Android 2.2 особо никакие сервисы уже не работают. Отчасти, я решаю свои проблемы сам и пишу клиенты нужных мне сервисов, если они действительно нужны, дабы рано или поздно всё таки вдохнуть новую жизнь в «старенькие» девайсы. И казалось бы, это можно списать на синдром утёнка и банальную ностальгию, но мои ощущения «ламповости» отнюдь не мимолетны и всё равно меня тянет именно на те смартфоны, с тем самым интерфейсом, которые я когда-то увидел впервые!
Пожалуй, сказать что я решил портировать старый Android на отнюдь не новый смартфон «просто так» было бы ложью. Я всё ещё верю в то, что смогу в одиночку хотя бы частично вдохнуть новую жизнь в эти девайсы и позволить им работать с современными сервисами, дабы они могли приносить пользу не только мне, но и другим людям, которые намеренно занимаются дауншифтингом или вынуждены сидеть на девайсах с старыми версиями Android! Сегодняшним нашим подопытным станет один из представителей подобных noname-смартфонов тех лет, реплика Galaxy S III Mini на том самом железе, на котором работал мой первый смартфон. Однако с завода на нём стоял Android 2.3 — слишком свежая, по моему мнению, версия системы, которую я конечно-же захотел откатить до Android 2.2!
Задача облегчалась тем, что смартфоны на этом чипсете с Android 2.2 уже выходили, что позволило мне портировать прошивку путем несложных патчей скриптов инициализации и копирования Platform-specific файлов, дабы завести все необходимые для смартфона модули. А поскольку о таком простом способе портирования свежих и старых прошивок знают далеко не все мои читатели — я решил написать об этом отдельный подробный материал! Давайте же перейдём к практической части нашей статьи.
❯ Первые шаги
Перед тем, как начать портирование системы, нам необходимо разбираться в том, как вообще происходит процесс загрузки Android и какие процессы при этом загружаются. Вкратце, описать весь процесс загрузки можно так:
Загрузчик: при включении смартфона, первичный загрузчик BootROM, аппаратно-прошитый в чипсет ещё на этапе изготовления чипа, инициализирует некоторую периферию, загружает вторичный загрузчик из NAND (коим может быть SPL — Second Program Loader, занимающийся инициализацией контроллера DDR и UART) и передаёт ему управление. Вторичный загрузчик в свою очередь передаёт управление U-Boot — в задачи которого входит также инициализация периферии, обработка устройств постоянной памяти (например, NAND или контроллер SD), загрузка ядра Linux и конфигурация самого процесса загрузки. U-Boot можно считать эдакой альтернативной UEFI/BIOS в мире не-x86 устройств. В смартфонах на базе чипов MediaTek и Qualcomm, роль U-Boot выполняет LK — маленькая ОС, в задачи которой входит инициализация периферии и передача управления ядру Linux с помощью программы aboot.
Ядро Linux: после загрузки образа ядра с initrd (небольшая файловая система, которая загружается сразу в память и содержит в себе скрипты для конфигурации всего остального) и передачи управления ядру, Linux начинает выполнение программы с PID 0 — /init, в задачи которой входит выполнение скриптов инициализации userspace-окружения системы в init.rc. При этом смартфон уже фактически готов к работе — в одной из своих статей я показывал, как можно приостановить загрузку Android и выполнять свой код, используя все ресурсы смартфона для своих целей.
zygote и app_process: помимо запуска необходимых для работы смартфона служб, динамической загрузки драйверов (с помощью insmod) и определения режима загрузки (например, если телефон подключили выключенным к зарядке — необходимо показать анимацию этой самой зарядки), init.rc запускает две программы, одна из которых необходима для функционирования системы. Первая — это bootanimation, которая проигрывает анимацию включения смартфона и app_process, который в одном из режимов работы превращается в zygote — самый важный процесс для работы Android, который предварительно при старте системы загружает системный Java-байткод, отвечающий за отрисовку интерфейса, проигрывание звука и т. п. из framework.jar и другие системные ресурсы (например темы и изображения), а затем при запуске каждого приложения просто клонирует сам себя (с уже загруженными ресурсами) и начинает выполнение байткода любого запущенного Android-приложения или службы.
Каждое запущенное приложение или служба — это отдельный app_process, в том числе и лаунчер, и Google-сервисы и клиент любого мессенджера.
Всё выглядит просто и логично, не так ли? Подытожив, можно сказать что для того, чтобы система минимально стартовала, нам необходима подходящее ядро для нашего устройства, рабочий init.rc и адекватно запускающийся init.rc. Кроме того, Android зависит от некоторых платформо-специфичных библиотек: в основном, они находятся в /lib/hardware и без них система может не запуститься или что-то может не работать. Особенно осторожно надо подходить к libhardware.so.
Как я уже сказал выше, прошивку мы будем портировать от другого смартфона на том-же чипсете и что забавно — такую же реплику, просто более-раннюю! «Из коробки», мой смартфон работает на Android 2.3, значительно более стабильной, чем изначальный порт 2.2 на эту платформу. Отличий 2.3 от 2.2 достаточно: например, на 2.2 совсем иной цвет шторки, по умолчанию стоит Light-тема, нельзя закрывать уведомления смахиванием и в целом система несколько отличается внешне. Для работы нам нужно будет два образа прошивки: ту, которую будем портировать и та, которая стоковая. Прошивки в смартфонах на платформе Spreadtrum распространяются в формате pac, однако нет никаких проблем подменить образ раздела в ResearchDownload — фирменной утилите для прошивки смартфонов на этом чипсете.
Я решил взять прошивку от FeiTeng N9300 Mini, родная для моего смартфона — M-Horse 9500 Mini. В случае моего девайса, разметка и список разделов между устройствами никак не отличалась, поэтому изначально я напрямую прошил раздел system.img, дабы посмотреть что будет с устройство. Не забывайте, что ядро и init.rc хранится в образе boot.img — поэтому прошивка раздела system безопасна!
❯ Первый запуск
После прошивки чужого раздела system, смартфон стартовал… однако работал несколько странно: во первых, у нас не было сети, во вторых не работал тачскрин (при родном то ядре), а в третьих, Android ни в какую не видел аккумулятор, вися на 0% и моментально отключаясь, если смартфон не стоит на зарядке, а при попытке воткнуть кабель — смартфон показывал индикацию зарядки, но потребление было на нуле.
Поскольку тачскрина у нас нет, root доступ через adb придется включать «ручками» — для этого нам необходимо перепаковать наш родной раздел boot. Для распаковки и запаковки образов, я пользуюсь MtkImgTool — весьма удобная «кухня» для работы. Вытаскиваем boot.img из pac, закидываем в Unpack/Image/ и распаковываем с помощью Boot -> Unpack -> boot.img
В Unpack/boot/ramdisk/default.prop нам необходимо изменить ro.debuggable на 1, а ro.secure на 0. Это даст возможность отлаживать устройство даже если Android фактически не загрузился.
Теперь у нас есть root-консоль устройства, даже если смартфон висит на заставке. Прошиваем обратно образ, пишем adb shell в консоли и смотрим, что же тут не так… Вообще, драйвер тачскрина обычно статически слинкован с ядром, но в случае устройств Spreadtrum — они вынесены в динамические модули ko, которые можно найти в папке /lib/modules/, либо /sps/. Давайте глянем init.sp6820a.init.3rdparty.rc, который отвечает за специфичную для этой модели смартфона инициализацию.
Ага, видим insmod gt868.ko? Это команда загрузки драйвера тачскрина, в нашем случае — это вышеупомянутый GT868. Иногда встречаются другие модели тачскринов, но главное отличие прошивки 2.2 от 2.3 — разные названия папок с драйверами и некоторые службы. Достаём из родного образа драйвер gt868.ko, используя всё тот-же MtkImgTools, распаковывая его как обычный ext2 раздел:
И наслаждаемся тем, что у нас теперь появился тачскрин! Android сам подхватил новое устройство ввода, поскольку драйвер тачскрина — обычное устройство в /dev/input/. Чтобы драйвер грузился при загрузке, его достаточно добавить в init.sp6820a.3rdparty.rc, предварительно закинув в раздел /system/. Перед этим, раздел нужно перемонтировать для возможности записи:
После модификации rc-скрипта, нужно обратно запаковать boot.img с помощью MtkImgTools и прошить его с помощью ResearchDownload — тачскрин будет работать даже после перезагрузки!
❯ Поднимаем зарядку и сеть
Переходим к отсутствию связи с аккумулятором и нулевым потреблением АКБ. Здесь мне пришлось несколько покопаться и почитать логи ядра с помощью команды dmesg. Я обратил внимание на то, что некая служба пишет что-то об аккумуляторе, но разобраться было несложно: в папке /system/bin я нашёл программу charge, которая, очевидно, отвечает за настройку КП для старта зарядки. Что она точно делает — мне неизвестно, возможно корректирует какие-то значения в sysfs, возможно с помощью ioctl общается с драйвером КП и даёт разрешение на старт зарядки и обновление информации в sysfs. В любом случае, после замены /system/bin/vcharged на оный из родной прошивки, зарядка заработала.
Для этого мы снова перемонтируем /system/ в режим записи и копируем vcharged, не забыв вернуть обратно необходимые права:
Перезагружаем устройство и… зарядка с индикацией появилась!
Вроде всё работает на первый взгляд: и звук, и вибро, и Wi-Fi с Bluetooth… однако сети-то нет! Девайс не определял наличие SIM, а вместо IMEI у нас был null/null:
Чтобы её поднять, нам необходимо разобраться в том, как работает подсистема взаимодействия с радиомодулем в Android, которая называется ril — Radio Interface Library. RIL предоставляет API для системы, дабы оперировать не напрямую AT-командами (которые могут быть проприетарными, а на некоторых чипсетах, как, например, Qualcomm вообще отсутствовать), а удобным набором функций — например о запросе статуса радиомодуля, начале звонка, поиска сети и т. п. RIL состоит из сервиса rild в /system/bin/ и библиотеки libril.so, которую можно найти в папке /system/lib/. При запуске системы, TelephonyManager открывает сокет с rild и опрашивает его состояние. Именно из TelephonyManager система берет информацию о силе сигнала, название оператора, IMEI и другие данные.
Путем ковыряния в dmesg я понял, что система флудит из-за невозможности запустить проприетарный сервис Spreadtrum — sprd_monitor. При попытке позвонить в 112, смартфон бесконечно пытается включить радиомодуль. Я ковырялся в UI-части исходного кода Android, дабы понять логику работы, но проблема крылась как раз в упомянутых выше службах sprd_monitor. Берём их из /system/bin/ оригинальной прошивки, закидываем их в устройство, не забыв установить права и отправляем систему в ребут:
Ошибки в dmesg пропали, IMEI появился, но устройство до сих пор не хочет никуда звонить и просто висит на экране звонка. В настройках смартфон говорит о том, что уровень сигнала недоступен, а значит, радиомодуль до сих пор не работает :(
Но и мы так просто не сдаемся! Поковыляв по файловой системе, в директории /system/opl/telephony/bin/ я нашел скрипт, отвечающий за инициализацию радиотракта, который вызывает родной 3rdparty.rc! Запускаем sh-скрипт и обнаруживаем, что сеть появилась и девайс дозвонился в 112, а также увидел SIM-карту!
Теперь всё полностью работает :) Дабы радиотракт запускался при старте устройства, я перенес часть инита из boot.img от прошивки, которую мы портировали. Для кого-то, казалось бы, это всё достаточно сложно и долго. Но у меня ушел всего один день на полную отладку и запуск такой кастомной прошивки на своем устройстве! Можно сказать, это самый базовый и краткий экскурс в такое нелегкое дело, как моддинг Android-устройств.
Но мы ведь это всё не просто так делали! Давайте глянем, как будет работать такой девайс на Android 2.2 в 2024 году — спустя 14 лет после выхода системы. Всё ли так плохо, как кажется?
❯ Знакомимся с девайсом
Думаю, многие читатели вспомнят этот ламповый интерфейс, обои с одуванчиком и лаунчеры а-ля TouchWiz на тех смартфонах, где интерфейс Samsung был не предусмотрен. А эти «бульк»… их сложно забыть!
Конечно, изначально может показаться, что устройство плохо подходит для выполнения современных задач: браузер не способен загрузить большинство страниц, а из альтернатив есть только Opera Mini, где вообще нет динамического контента, а официальные клиенты ВК, WhatsApp и YouTube уже давно не работают. Опечаленный читатель может подумать, что девайс, как и многие его ровесники уже давно превратились в звонилки…
Но это отнюдь не так! Ведь как я уже говорил, я стараюсь своими силами вдохнуть в подобные девайсы новую жизнь, реализуя на них клиенты нужных мне сервисов сам! Да, пусть примитивно и корявенько, далеко не ынтырпрайз-уровень, но эти приложения выполняют свои функции и что, немаловажно, весят очень мало (до 100Кб) и работают крайне шустро! Клиент ВКшечки просто летает, несмотря на то, что фактически реализован только мессенджер с нотификациями и музыка.
Пожалуй, многие читатели удивятся — но на таких девайсах есть YouTube! Мой самопальный клиент не поддерживает стриминг из сети (да и многие девайсы объективно не потянут), поэтому предварительно загружает видео на MicroSD-флэшку и затем уже их воспроизводит. Как приятный бонус — видео потом можно посмотреть в любой момент в галерее.
Я помню насколько было лампово слушать музыку с таких девайсов. И если претензии к основному динамику не очень актуальны, то к качеству звука в наушниках были придирки — звук был громкий, но ему не хватало низких частот, из-за чего он звучал несколько плоско, хотя мне и этого хватало — ведь я слушал музыку в наушниках по 200-300 рублей с рынка! Я всё ещё помню те времена, как качал mp3-треки по 2-3 мегабайта через 2G-интернет… слушаешь один трек — как раз загрузится другой и так по кругу наполнял свою фонотеку. Эх времена то какие были! Тем не менее, для некоторых базовых мультимедийных возможностей девайс подходит и сейчас, например в машину в качестве BT-хоста с музыкой. А ещё на таких девайсах порой клёво скачать какой-нибудь Temple Run образца 2011 года и вспомнить самое начало смартфонного гейминга тех лет… ведь далеко не все игры того времени запускаются на свежих версиях Android!
❯ Заключение
В остальном же, подобные девайсы отнюдь не бесперспективны! Несмотря на совсем не новое железо, они всё ещё могут выполнять многие задачи, стоит лишь снова запилить необходимые приложения для них! Мессенджеры, соц. сети, музыкальные сервисы и даже просмотр видео — всё это доступно даже для таких, казалось бы, «устаревших» девайсов, когда есть запал энтузиазма и жгучее желание походить именно с этим конкретным устройством как с основным!
Для кого-то это просто проявление синдрома утенка или картинки «вот кому-то делать не.»… ну а для меня — это крайне интересное, захватывающее и кайфовое времяпровождение: начиная от аппаратного ковыряния с такими девайсами и копания исходников ядер/драйверов, заканчивая написанием оптимизированных клиентских приложений, которые весят не 100-200Мб, а 100-200Кб :)
Друзья, если у вас есть подобные китайчики и вы не разделяете желания пытаться вдохнуть в них жизнь, но выбрасывать их жалко — можете задонатить их мне :) Как сами видите — девайсы попадают в хорошие руки. Из недавнего — я взял нерабочую, утопленную китайскую копию 14 Pro Max из под СЦ в качестве основного смартфона. Также у меня есть канал в Telegram, куда я выкладываю бэкстейджи статей, различные заметки о ремонте, моддинге, программировании и реверс-инжиниринге и свои мысли. Кому интересно — залетайте!
Понравилась ли вам статья? Какими были ваши первые Android-смартфоны? Пишите в комментариях, будет интересно почитать!
Взять с собой побольше вкусняшек, запасное колесо и знак аварийной остановки. А что сделать еще — посмотрите в нашем чек-листе. Бонусом — маршруты для отдыха, которые можно проехать даже в плохую погоду.
Осторожно: в статье аппаратная диагностика и ремонт, реверс-инжиниринг и патчинг загрузчика, а также программный моддинг noname-устройства, для которого нет вообще никакой информации. В материале куча познавательного контента, даже если вы не фанат такого своеобразного класса устройств, как подделки на брендовые девайсы.
Пожалуй, споры о том, какая мобильная платформа лучше не утихнут никогда. Люди из года в год спорят, какая же мобильная платформа круче: iOS или Android, и какие только аргументы не выдвигают в сторону оппонента. Но что делать, когда хочется усидеть сразу на двух стульях и иметь смартфон в корпусе iPhone, но при этом с привычным Android на борту? Когда душа моддера и любителя красноглазия просто требует чего-то необычного!? Правильно, обратиться к китайским «подвалам» и взять себе дешевую реплику на андроиде! А в моём случае — ещё и Б/У утопленную подделку 14 Pro Max чуть больше, чем за «тыщу» рублей, так ещё и проапгрейдить её! Сегодня будет познавательный и интересный материал, в котором мы с вами: узнаем как диагностировать некоторые аппаратные проблемы с помощью минимального и дешевого оборудования, оживим наше «яблочко» после попадания влаги, «отреверсим» и пропатчим в IDA Pro загрузчик, дабы разрешить загрузку unsigned-ядер, портируем кастомное рекавери и накатим рут, а также узнаем что из себя представляет такой «айфон» в повседневной жизни и как мне вообще взбрело в голову купить китайскую подделку яблочной техники! Материал диковинный, но обещаю — будет интересно! Жду вас под катом :)
❯ Содержание
Ещё каких-то 10-12 лет назад люди собирались в комментариях под различными постами и жарко спорили о том, чья платформа более продвинутая. Чаще всего темой спорой была iPhone vs Android, реже — iPhone vs Windows Phone, а иногда и Android vs Symbian! Но годы идут, на рынке осталось только два крупных игрока, а споры всё не утихают. Стоит только зайти на профильный сайт, зайти в любой пост с новостями и насладится всеми прелестями споров «A vs B». Кто-то поддерживает экосистему Apple, кто-то Android в чистом виде, а кто-то микс фишек Apple в Android окружении от Xiaomi. Некоторые люди даже поддерживают, казалось бы, «неактуальные» платформы как Symbian/WP и среди них есть мои читатели (я и сам очень люблю их и запилил клиенты ВК и YouTube на них, о чём рассказываю в отдельной статье) :)
Но как мои давние читатели наверняка знают, я лично всегда придерживался позиции, что и iOS, и Android, и Symbian, и WP — замечательные системы, которые так или иначе нашли своего пользователя. У меня сейчас есть довольно много смартфонов прошлого десятилетия: полтора года назад я взял себе Galaxy S4 Mini в качестве основного девайса, год назад ходил уже с обычным Galaxy S4, а чуть больше полугода назад читатели подарили мне оригинальные iPhone, от 2G до 5s! И лично я очень люблю iPhone за отличный дизайн, за шуструю iOS, за достойную поддержку старых девайсов, но в тоже время… я ведь и сам вырос на 4pda, пользуясь ультрабюджетными «декспами», «зте» и «флаями»! И тяга к аппаратному и программному моддингу, а также написанию хоумбрю-приложений и прочим фишкам действительно открытых платформ отнюдь не угасла, скорее только наоборот!
Поэтому от нового девайса, с которым я хотел бы походить как с основным, я требовал лишь три вещи:
Дизайн одной из последних моделей iPhone. Пожалуй, кто-то из читателей сочтет это за «тупой понт», но это не совсем так, яблочные дизайны действительно неплохо продуманы и их приятно держать в руках. Важно понимать, что выпуская подделки, заводы откровенно экономят на железе, но при этом стараются достаточно качественно скопировать корпус, используя в конструкции и алюминий, и каленое стекло, а также установить относительно неплохую IPS-матрицу, пусть и низкого разрешения.
Поддержка LTE. Вы удивитесь, но да, всё ещё выходят реплики iPhone, Samsung, да даже Poco и Realme, которые построены на базе чипсета 2015 года — речь, конечно же, о MT6580. И к сожалению, радиотракт этого чипсета не умеет работать с LTE, да и у платформы очень серьезные ограничения на объём ОЗУ (не более 2Гб) и разрешение дисплея (не выше HD) :(
Android на борту. Ну, по этому пункту я всё рассказал выше. При этом для меня не имеет значение версия системы, я не гонюсь за самыми новыми фишками: китайцы уже не ставят Android ниже 6-7 версии (впрочем, это спорно, предположительно ещё попадаются девайсы с 5.1 на борту среди самого дешевого сегмента), а «шестерки» мне вполне достаточно для всех моих применений, в том числе и YouTube с ВКшечкой. Чего там говорить, если мне чего-то действительно не хватает и у меня есть настроение — я сам себе запилю приложение :) Касательно статуса загрузчика я не волнуюсь: в «подвальных» девайсах практически никогда не бывает секьюрбута и нет никакой необходимости патчить загрузчик, что открывает широкие возможности к его моддингу. Эх, вот бы еще исходники ядер выкладывали — но это уже мечты :)
И под эти требования вполне попадают «новодельные» реплики последних моделей iPhone в среднем ценовом сегменте (от 10 000 рублей). Казалось бы, кто-то из читателей спросит: «автор, ты дурак за фуллпрайс брать такой девайс?». И нет, не дурак, поскольку смартфон я купил за 1 500 рублей (и это ещё дорого за его состояние, после покупки мне попался похожий девайс, но уже рабочий, с коробкой и всего за 500 рублей). Девайс продавал человек из СЦ, с которым мы состоим в одной беседе посвященной ретро-телефонам. Смартфон был заявлен как «невключайка» без признаков жизни, в непонятном состоянии, с битой задней крышкой и даже без базовой информации, такой, как о потреблении девайса на зарядки и при зажатой кнопке включения. Ну, как вы и сами понимаете, это настоящее комбо: не подающий признаков жизни китайский смартфон без какой-либо сервисной документации и схемы, который уже побывал в СЦ (потенциально в качестве донора) и наверняка разбирался, да ещё и, как потом оказалось, утопленный в воде… Это же только интереснее! Конечно берем!
Когда девайс приехал ко мне, то ещё до прихода домой я решил оценить его тактильные качества. Конечно, задняя крышка, увы, была подбита, но в целом мне всё равно девайс очень понравился. Как я уже сказал, рама смартфона выполнена из алюминия (за исключением толкателей кнопок), а задняя крышка из стекла с приятной на ощупь текстурой и, конечно же, выгравированным яблочком! Пока дисплей выключен, даже рамки дисплея едва ли дают себя выдать: по сути, определить реплику сможет только человек, который в теме яблочек и сможет опознать фейковые линзы с обратной стороны смартфона. Остальным можно наплести про «китайский дисплей» и т. п. :)
Придя домой, я понял — приключения только начинаются. Отклеив заднюю крышку с помощью фена, выяснилось, что девайс вскрывался: пару винтов потеряли, да и заводскую пломбу содрали.
Замеряем напряжение на АКБ и понимаем, что она села ниже 3.4В (3.5В — это уже 0%) и контроллер питания должен начать зарядку в режиме Precharge (режим «расталкивания» аккумулятора низким током). В режиме Precharge смартфон не показывает никакой индикации зарядки, поэтому остаётся лишь смотреть на потребление девайса и терпеливо ждать включения! Я ещё немного помог устройству раскачать АКБ с помощью внешнего 5В источника и вот, потребление поползло выше 0.2А — а девайс показал яблочко и индикацию зарядки. Неужели он рабочий?
На фото выше не видно, однако смартфон был залит водой и на дисплее появились большие разводы. И попадание воды не прошло просто так: он просто перезагружался на «яблочке», как и настоящий айфон… Вы, читатели, можете пока предположить, что же с девайсом было не так, а я включаю логическое мышление и перехожу к диагностике.
Друзья! Если вам не особо интересны технические детали аппаратного ремонта, или наоборот программного и вы хотели увидеть только обзор на устройство — можете прыгнуть сразу к обзору смартфона. Однако в технической части тоже много всего интересного!
❯ Диагностируем и ремонтируем
Итак, давайте сделаем выводы, которые мы можем понять из существующих симптомов:
Девайс заряжается и у него есть потребление, пусть оно и кажется заниженным, а значит модуль чарджера в контроллере питания, скорее всего, исправен.
Девайс включается и есть изображение яблочка, а значит, есть связь с eMMC и контроллер DDR инициализируется успешно, девайс проходит цепочку загрузки Preloader -> LK и возможно ядро, а также КП нормально реагирует на кнопку включения и включает необходимые выходы LDO для питания всех основных модулей смартфона (процессор и его периферия, чип памяти eMCP, драйвер bias-напряжений дисплея и т. п.). Скорее всего (но это не 100% гарантия), от воды не пострадали ни процессор, ни флэш-память.
Девайс уходит в перезагрузку: здесь причин может быть масса, например, данные на eMMC были повреждены в процессе залития и требуется прошивка, или всё же процессор или его обвязка оказались частично повреждены и при обращении к одному из встроенных периферийных модулей основное вычислительное ядро виснет и встроенный в КП WatchDog при отсутствии сигналов «сердцебиения» считает смартфон зависшим и отправляет его в намеренный ребут, из-за чего мы получаем циклическую перезагрузку. Не исключён вариант, что одна из внешних шин данных оказалась посаженной на массу в следствии КЗ одного из чипов на плате (или их обвязки), из-за чего драйвер, например, вываливает систему в Kernel panic и WatchDog также отправляет систему в ребут…
Наш девайс отказывался зайти в рекавери, что даёт нам понять, что до init дело скорее всего не доходит и девайс стопорится либо на LK (который и показывает анимацию зарядки и первое лого), либо на загрузке ядра. Казалось бы, столько причин, а метод лечения у многих ребят один: сейчас будем делать диагностический прогрев, а потом снимать все чипы и катать их, и если не поможет — глянем обвязку и межслойные обрывы :) Но не стоит так торопиться, ведь в некоторых случаях для диагностики аппаратных проблем можно использовать программные инструменты!
Дело вот в чём: многие китайские производители, особенно это касается ультрадешёвых смартфонов и планшетов, специально оставляют диагностические пятачки, которые дублируют контакты АКБ, если вы случайно сорвали пятачки при пайке аккума, USB, если вы не смогли найти китайский Lightning под замену, а также пятаки UART, иногда даже на несколько каналов, которые позволяют читать логи — диагностическую информацию, которую девайс выводит при загрузке и работе устройства! И порой, подписанные пятачки с включенным дебагом на UART'е полезнее даже полной схемы устройства с бордвью!
На фото отмечены пятаки, дублирующие USB
Ой-ой, а ведь присмотревшись к плате, мы увидим, что кто-то снимал защитный экран и пытался прогревать BT/Wi-Fi/FM комбочип, а также то, что вся плата в подтеках флюса! Да ещё и всю обвязку кто-то посдувал фиг пойми куда, да так, что часть обвязки лежала прямо на пинах комбочипа, а у нас ведь даже схемы нет! Не беда — эти смартфоны построены на базе референсной платы MediaTek и с большой вероятностью, обвязка будет расположена идентично с другими смартфонами на базе этих чипсетов. Но в моем случае, я просто поставил SMD-компоненты туда, где они, очевидно, стояли: резисторы к резисторам, конденсаторы к конденсаторам, а иных элементов у меня пока-что не было. Дабы комбочип точно не вмешался в работу устройства, я временно его сдул с платы:
За качество фото извиняюсь, сделано в попыхах
Я сразу же снял дамп своего устройства и нашел по платформе прелоадера и названию сборки оригинальную прошивку (линк в описании, решил оставить оригинальную ссылку, поскольку автор нормальный и не просит писать ему в мессенджеры за паролем для архива), дабы исключить вероятность косяка со стороны eMMC.
Обратите внимание — я сначала сделал дамп, дабы в случае неподходящей прошивки, прошить свою или собрать из двух прошивок одну! Поскольку мой китайский псевдолайтнинг уже был слегка подуставший (хотя 14 Pro Max ещё относительно свежий девайс) и сигнальные линии D+ D- были просажены, а девайс не определялся ПК, я отключил нижнюю плату АКБ и подпаялся напрямую к дублирующим пятачкам USB: после этого, девайс определился в системе как MTK Preloader, что дало мне возможность прошить официальную прошивку, но ожидаемо, эффекта это не принесло — смартфон всё так же перезагружался на яблочке :(
Затем я решил подпаяться к UART'у и всё же почитать логи подробнее: для этого, нам пригодится UART-преобразователь. Также, в качестве UART-преобразователя подойдет и ESP32, который частенько можно найти в местных радиомагазинах за копейки. Сигнал EN необходимо кинуть на 3.3В - это погрузит МК в RESET и не даст ему влиять на шину!
Подпаиваемся так, как я отметил на фото ниже, не забывая подключить общую массу. Для чтения UART'а я использую putty.exe: выбираем наш COM-порт, ставим бодрейт 921600 и запитываем девайс: теперь у нас побежали логи…
С левой стороны каждой строки лога написано время с момента старта ядра — т. н. «аптайм». На него тоже важно обращать внимание, поскольку он помогает приблизительно понять, на каком визуальном (т. е. то, что мы видим на дисплее) этапе стопорится загрузка. Мой девайс падал в Kernel panic и уходил в перезагрузку на 30 секунде работы… казалось бы, что можно понять из этих логов и как определить неисправность? Вот тут мы фокусируем наше внимание на двух строках:
Первая — это то, что у нас пытается проинициализироваться драйвер stk301x — датчика освещенности и приближения к уху, а вторая, где написано таймаут — означает об ошибке передачи данных на шине I2C к устройству по адресу 47. И чтобы понять суть ошибки, нам нужно иметь базовое понимание о принципах работы самых часто применяемых аппаратных протоколах для общения с другими чипами: SPI, I2C и 8080. В протоколе I2C, у каждого устройства есть собственный адрес, выраженный в 7-битном формате (до 127 адресов на одной шине), в случае stk301x — это 47. Что делает драйвер: он посылает датчику набор команд для инициализации или получения данных, при этом на хост-устройстве (т. е. процессор в нашем случае), сначала формируется состояние СТАРТ и посылает всем устройствам на шине адрес нужного устройства. Затем, нужный чип должен «подхватить» свой адрес и на все байты передаваемых данных формировать статус ПОЛУЧЕНО (ACK). Если статус ACK не получен аппаратным I2C-контроллером процессора телефона за определенное время (допустим, 1 секунда), то он формирует прерывание (или просто изменяет статусный регистр), который обрабатывает драйвер контроллера I2C, который затем и выдает драйверу датчика статус таймаут, а тот в свою очередь выводит ошибку в логи!
Пример с сайта компании Microchip
Всё равно ничего не понятно? И снова мы с вами включаем смекалку. Если устройство жалуется на отсутствие состояния ACK, значит, возможны две причины поломки: обрыв линии SDA/SCL до устройства, либо то, что в следствии попадания воды, одно из периферийных устройств «сгорело» и садит всю шину I2C на массу, из-за чего, например, драйвер другого устройства на шине I2C крашится, а поскольку это драйвер работающий в пространстве ядра — он тащит за собой все! Может быть и такой вариант, что драйвер КП не может посылать сигналы Heartbeat из-за просаженной шины и КП отправляет устройство в ребут.
Сдуваем наш датчик освещенности, включаем девайс и он вроде даже не выключился спустя 30 секунд… проходит пару минут и…
Решил вставить оригинальное фото первого включения, как раз сделанное «по быстрому» и в порыве радости :)
Он включился и работает! Он выжил, хотя разводы воды заметно сказались на состоянии его дисплея! Но поскольку комбочип пока что выпаян, у нас не будет ни Wi-Fi, ни BT, ни GPS, ни радио. Поэтому отключаем девайс и припаиваем обратно комбочип, не забыв восстановить всю обвязку. В финале мы отмываем плату от подтеков флюса (не весь флюс мне удалось нормально вымыть, потому что старый прикипел).
После установки комбочипа и остатков обвязки (а может, это и вся обвязка что была с завода, китайцы ведь часто экономят и на этом — ставят необходимый минимум), я проверил и Wi-Fi, и BT — теперь девайс звонит и без проблем выходит в интернет!
На этом аппаратный ремонт закончен. Поскольку девайс теперь работает, можно приступать к его программному моддингу! Но сначала, нужно отключить проверку подписи образа ядра.
❯ Патчим загрузчик
Как я уже говорил выше, в подобных репликах и просто дешевых noname-девайсах фактически отключен полноценный секьюрбут. Однако конкретно в этой реплике, при сборки прошивки, производитель включил в lk (загрузчик второго уровня) принудительную проверку подписи у образов ядра boot.img и recovery.img, предварительно включив возможность его отключения (т. е. разблокировки загрузчика) в режиме fastboot. На многих девайсах достаточно лишь перезагрузить устройство в режим fastboot и выполнить специальную oem-команду:
adb reboot bootloader fastboot oem unlock
Которая вызовет соответствующий диалог. Но вот незадача: девайс не реагирует на кнопку вверх, из-за чего загрузчик разблокировать не получается. Намеренная подлянка от производителя? Скорее недосмотр при проектировании платы, благо исходный код вторичного загрузчика LK, который и реализовывает режим fastboot сливали в сеть. Давайте изучим его подробнее!
Итак, что мы здесь видим? При запросе разлочки устройства, девайс падает в бесконечный цикл, в котором проверяет и реагирует на одну из соответствующих клавиш — громкость вверх, или кнопка «ОК», которая считается кнопкой вниз. Почему же девайс не определяет кнопку вверх? В чипсете есть отдельный периферийный модуль, который отвечает за обработку Keypad-кнопок клавиатуры. Он же позволяет реализовать полноценную QWERTY-клавиатуру без внешних контроллеров, если того захочет производитель. Однако он оперирует не конкретными логическими уровнями на GPIO (иначе потребовалось бы слишком много пинов и, скорее всего, сильно увеличивать размер чипа), а специальным АЦП (аналогово-цифровой преобразователь) с низким разрешением, который вычисляет, какая кнопка нажата относительно определенного сопротивления. Следовательно, если производитель каким-то образом накосячил при разводке платы и резистором иного номинала «присвоил» громкости вверх другой аппаратный KeyCode-клавиши, функция mtk_detect_key банально не «увидит» нажатие нужной нам кнопки, которая захардкожена как 0x0.
Но почему тогда в Android, кнопка громкости вверх работает нормально?
У Android есть отдельный механизм для маппинга кнопок, называемый keylayout'ами. В текстовом файле хранятся ассоциации числовых KeyCode'ов с константными обозначениями, такими как VOLUME_UP и VOLUME_DOWN например. Поэтому вы без проблем можете поменять их значение местами, или, например, если у вас сломалась кнопка включения, переназначить её на громкость вверх без необходимости кидать перемычку!
Подробнее о подсистеме ввода в Android я рассказывал в другой своей статье.
Как же это поправить? Не собирать же нам lk самим, да и будет ли пропатченный загрузчик работать? И да, будет! Как я уже сказал, в девайсе не включен полноценный секьюрбут с верификацией того, что вы прошиваете через FlashTool в внутреннюю память устройства. Preloader (первичный загрузчик после BootROM) не проверяет ни целостность lk, ни хэш-суммы, просто читает его в 0x0 и передает ему управление… А что это значит? Что мы можем просто пропатчить условие, отвечающее за «громкость вверх», дабы lk считал, что мы все таки нажали эту кнопку! Открываем дизассемблер IDA Pro и наш lk.bin в нём, как обычный binary-файл со смещением 0x0 и ищем те строки, которые встречаются ближе всего к нужному нам условию. В нашем случае, это Start unlock flow.
Как видите, IDA Pro, как самый крутой дизассемблер по моему мнению, уже построил xref'ы (все ссылки на бинарные данные из инструкций) и сразу показывает нам куда обращается тот или иной код. Опана! А вот мы и нашли код функции, которая отвечает за старт анлока загрузчика и проверяет нажатые кнопки. Что же нам с этим делать? Правильно, переключится в режим графа и анализировать код подробнее. Я не так силен в ARM-ассемблере, как x86, но всё же не без помощи ISA-мануала от ARM понял значение всех мнемоник.
Обратите внимание на инструкцию BL — она вызывает подфункцию и сохраняет адрес PC + длина инструкции в стек, дабы продолжить выполнение после возврата из неё. Это и есть вызов нашей функции mtk_detect_key. Оптимизатор сократил код так, что сразу после возврата из функции, её возвращаемое значение оказывается в регистре R4, который программа переносит в регистр R0, а затем сравнивает R0 с нулем. Если R0 оказывается ноль (инструкция BEQ, branch if equal to zero, т. е. кнопка не нажата), программа прыгает к проверке кнопки «вниз», а если нет — то продолжает выполнение кода, который стартует разблокировку загрузчика. Уже смекнули, о чем я? Нам достаточно лишь пропатчить CMP R0, #0, дабы заставить программу считать, будто кнопку мы все таки нажали и перейти к процессу разблокировки!
Обратите внимание, что в #0 (т. е. с решеткой) — это Immediate-значение, которое уже является операндом инструкции, а не загружается, например из регистра, а значит мы можем просто найти это значение в HEX-редакторе и пропатчить его на 1, либо просто NOP'нуть всю инструкцию. Адрес операнда инструкции — 0x1FB0C, поэтому сразу переходим к нему в hex редакторе и просто меняем 0 на 1 и сохраняем:
Прошиваем новый lk.bin с помощью SP Flash Tool, перезагружаемся в fastboot, пишем fastboot oem unlock и… сработало! Смотрим статус разлочки с помощью fastboot oem device-info (unlocked и secure) и видим что девайс действительно разлочен! Теперь смартфон каждое включение будет напоминать нам о том, что мы разлочили загрузчик. Ну разлочили и разлочили, зато теперь у нас полная свобода действий :) Переходим к ответственному действияю — портированию рекавери и накатыванию рута! Но здесь всё уже гораздо проще.
❯ Портируем рекавери и накатываем рут
Поскольку мы с вами уже разблокировали загрузчик, то и без проблем можем грузить что захотим: и LineageOS, и MIUI — всё что уже портировано для этого чипсета на этой версии ядра. Правда не забывайте, что чипсет 64х-битный, множество прошивок — тоже, а китайцы почему-то собрали 32х-битную прошивку — это стоит иметь ввиду при портировании. Если честно, изначально я хотел включить часть с портированием прошивки в основную статью, но опросив читателей понял, что вам не особо комфортно читать статьи 20+ минут длиной, поэтому если вам интересен подробный материал о портировании прошивки без пересборки ядра на нонейм устройствах — проголосуйте в опросе ниже (или маякните в комментариях)!
Начинаем с накатывания «кухни». Я пользуюсь MTK Img Tools, весьма удобный софт. Для его использования, нужно вручную создать папки Pack/Image и Unpack/Image.
Закидываем в папку Unpack/Image родной recovery.img, и тот, который будем портировать — назовем его recoverytwrp.img. Распаковываем их в менюшке Unpack image -> Boot. После распаковки, у нас появятся папки recovery и recoverytwrp в папке Unpack, где мы и будем вести нашу работу. В целом, на MT6753 в нашем случае достаточно лишь перенести родное ядро в тот рекавери, который мы портируем. fstab же трогать не нужно. Делается это легко: просто копируем recovery/kernel/kernel в recoverytwrp/kernel/kernel с заменой и пересобираем образ командой Pack image -> Boot обратно. Собранный образ мы найдем в папке Pack/Image, его можно либо прошить в флэштуле взамен стандартного, либо загрузить прям из фастбута без необходимости прошивать память устройства (это, кстати, ещё один отличный способ грузить Android с MicroSD если флэшка «закончилась»).
fastboot boot recovery.img
Кастомный рекавери загрузился без проблем — а это значит, что нам открыты большие возможности по кастомизации нашего девайса! Берем SuperSU с официального сайта, прошиваем SuperSU.zip с помощью adb sideload и балдеем, теперь с полноценным рут-доступом к устройству и без необходимости патчить Magisk'ом или распаковывать раздел system!
Теперь можно вычистить весь мусор из предустановленных приложений благодаря спец. софту для менеджмента приложений на смартфоне.
❯ Можно ли пользоваться девайсом?
Давайте посмотрим! Девайс из коробки похож на iOS 16, при этом, поскольку такие «айфоны» работают на общей аппаратной платформе, теоретически есть возможность поставить на 12 Pro Max прошивку от, например, 15 Pro Max (с некоторыми изменениями) :)
Функционал системы скопирован достаточно точно. На некоторых репликах особо не заморачиваются и просто чуть изменяют значки на айфоновские, не убирая даже нижнюю панель кнопок. Здесь же все скопировано с настоящей iOS: свайп снизу вверх сворачивает приложение, свайп до центра экрана открывает меню многозадачности, свайп шторки с левой стороны открывает панель нотификаций, а справа — панель управления. И ведь это не просто чужие готовые лаунчеры из условного Play Market, компания-производитель либо аутсорсит копирование некоторых фишек разработчикам на стороне, либо держит свой собственный штат программеров, который, в том числе, занимается сборкой прошивок и портами с рефборды!
В настройках, система гордо называет себя iOS, а модель смартфона — iPhone 14 Pro Max! Но что на практике? CPU-Z говорит о следующих характеристиках:
Тоже не знали, что Apple A16 разрабатывала MediaTek? :)
Более половины характеристик — брехня. Настоящие спецификации девайса следующие:
Процессор: MediaTek MT6753. 8 ядер Cortex-A53, 4 из которых работают на частоте 1.5ГГц, а оставшиеся — на частоте 1.3ГГц. Чипсет выпущен в 2015 году и выполнен по техпроцессу 28Нм, поддерживает до 3Гб ОЗУ.
GPU: Mali T720, преемник легендарного Mali 400. Уже немолодой, но всё ещё кое-что, да может. Vulkan не умеет.
ОЗУ: 3Гб DDR3. Не так много, но в целом пока ещё относительно адекватно.
Флэш-память: хотели 512Гб? Получите 32Гб, а недостаток можно нарастить MicroSD-флэшкой, слот под которую производитель заботливо предусмотрел под крышкой устройства. Это частая практика для китайских айфонов.
Дисплей: с диагональю не наврали, честные 6.7". А вот с разрешением, конечно-же, приукрасили: здесь стоит HD+ IPS матрица с разрешением 720x1540. Не особо высокое разрешение для такой диагонали дисплея, но в остальном дисплей показывает себя адекватно: яркость приемлемая, цвета хорошие, матрица отзывчивая.
В целом, характеристики ближе к ультрабюджетным моделям Realme и Poco. Нельзя сказать, что всё прям очень плохо, но ожидать что он будет работать на уровне флагманов, конечно же, не стоит. Но как оно на практике?
Начинаем с мессенджеров: ВКшечка и Telegram. В качестве клиента ВК, я юзаю исключительно Kate Mobile, который шустро работает даже на 10-летних китайцах на MT6572. Официальный клиент давно не признаю, всё таки при grishka он был лучше :)
Последний официальный клиент телеги работает шустро. Чипсет, конечно, печка ещё та, но посидеть в чатиках, посмотреть видосы и всякое такое можно без каких либо проблем. Главное чтобы память резко не закончилась. WhatsApp здесь тоже работает нормально.
Переходим к видосам. Ни официальный клиент, ни ревансед последних версий нормально здесь работать не будет — официальные клиенты требуют Android 8+. Но разве ж это проблема для нас, когда есть SkyTube? :) Работает шустренько, девайс без проблем держит 720p видосы, а больше и смысла нет.
Как насчет навигации? Google-карты работают адекватно. Всё весьма шустренько, хотя порой просадки FPS всё же бывают. Но я лично предпочитаю выкидывать гаппсы из своих смартфонов и накатывать навигацию по OSM. Что забавно — в девайсе есть собственный клон AppStore'а! И если рескины Google Play в стиле яблочного магазина для меня не удивление, то наличие полноценного бренда CH с эдаким фидбеком у смартфона меня весьма удивило. Я всё ещё помню GooPhone'ы, которые когда-то предоставляли хороший клиентский сервис покупателям своих реплик айфонов, но не думал что эта практика даже сейчас актуальна. Вполне возможно, что CH — это и относительно крупный завод-производитель со своим R&D отделом, поскольку маркировка есть и на межплатном шлейфе, и на АКБ. Эта компания также производит реплики Galaxy S и Note серии, на базе той-же аппаратной платформы.
И переходим, конечно-же, к камере! Самое приложение скопировано 1 в 1 с оригинала, даже есть какие-то панорамные режимы и фишки с цифровым зумом и подобием изменения FOV. Но понятное дело, тест не может быть объективным на 100%: девайс после воды, топился в районе камеры и на фото явно видны засветы. Есть вероятность, что оптика всё же оказалась немного повреждена :(
"Фотосет" из двух наиболее удачных фотографий есть на imgur. Увы, на Пикабу очень большие ограничения на число картинок в одном посте!
Но на скринах всё красиво, а как на деле? Смотрим:
❯ Заключение
В целом, девайс весьма хорош для моих повседневных задач. Работает шустренько, выглядит как айфон как с внешней точки зрения, так и с точки зрения системы, дисплей весьма неплох по качеству, смартфон отлично поддаётся моддингу. Собственно, а почему-бы и нет?
Цель материала была рассказать вам не только о том, на что подобные реплики способны «из коробки», но и об их возможностях моддинга и кастомизации с подробной практической частью, а не на уровне «пойдите туда и сделайте это»! Но учтите, я не рекомендую покупать реплики айфонов, если вы ожидаете от них хорошей работы из коробки и у вас нет желания в них ковыряться. Зато мне очень понравилось с ним возиться и я надеюсь, по итогу было интересно и вам! Пишите своё мнение в комментариях, будет интересно почитать! Также у меня есть канал в телеге, где я публикую бэкстейджи статей, различные посты по тематике аппаратного и программного моддинга, программирования, а также разработки собственного DIY-железа!
Кстати, если у кого-то из читателей есть похожие подделки будучи нерабочими, тормозящими, или окирпиченными и вам не хотелось бы выкидывать их на свалку, а наоборот, отдать их в хорошие руки и увидеть про них статью — пишите мне в Telegram или в комментах! Готов в том числе и купить их. Особенно ищу донора дисплея на китайскую реплику iPhone 11 Pro Max: мой ударник, контроллер дисплея калится и изображения нет :(
Что думаете о девайсе?
Что думаете о покупке его за 10.000 рублей? А за 1.000 рублей?
Материал полезен?
Статья подготовлена при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, дабы не пропускать новые статьи каждую неделю!
Человек постоянно находится под воздействием электромагнитного излучения из-за гаджетов, бытовых приборов, терминалов оплаты в магазине, сотовых вышек, радио в машине и т.д. Какое излучение представляет для нас наибольшую опасность? Облучает ли нас микроволновка? Зачем алюминиевая пластина под чехлом для телефона? И чем может навредить обычный свет от экрана ноутбука? Рассказывает Эргаш Нуруллаев, кандидат физико-математических наук, доцент кафедры прикладной физики Пермского Политеха.
Все волны разделяют на ионизирующие и неионизирующие. Под ионизирующим понимают такое излучение, которое способно отделять электроны от атомов веществ или живых организмов, что сопровождается образованием ионов — электрически заряженных частиц. На это способны радиационное излучение, например, гамма-лучи, которые в медицине применяют для лечения онкологических заболеваний, а на АЭС — для получения энергии, рентгеновские лучи и ультрафиолет, который испускает Солнце. В обычной жизни человек подвергается воздействию только УФ-лучей, при этом самые опасные из них рассеиваются в атмосфере, превращая кислород в озон. Эффектом от частого нахождения под солнечными лучами будет фотостарение: ультрафиолет разрушает коллаген и эластин — «строительные» элементы нашей кожи.
— Все приборы и устройства вокруг нас — мобильные телефоны, ноутбуки, беспроводные наушники и смарт-часы с Bluetooth, Wi-Fi-роутеры, электрические зубные щетки, микроволновые печи, холодильники и т.д. — излучают неионизирующие электромагнитные волны. Прежде всего, речь идет о сверхвысокочастотном излучении (СВЧ-излучение или микроволновое излучение), которое имеет диапазон частот от 300 МГц до 300 ГГц, а длину волны — от 1 м до 1 мм, — рассказывает ученый-физик Пермского Политеха.
Стоит ли бояться микроволновок?
Опасность СВЧ-лучей кроется в их способности передавать тепловую энергию: нагретые молекулы начинают колебаться интенсивнее, что приводит к их разрыву и разрушению вещества. Самым сильным источником такого излучения у нас дома являются микроволновая печь, еда в ней разогревается благодаря воздействию сверхвысокочастотных лучей. Но бояться работающей микроволновки все же не стоит: современные модели со всех сторон обшиты материалом, блокирующим вредное излучение. Даже стекло на дверце покрывают специальным металлическим напылением. При такой защите СВЧ-лучи все равно попадают за пределы микроволновой печи, но в тех дозах, которые не обожгут человека. Специалисты при работе микроволновки рекомендуют сохранять дистанцию в 1 метр.
— Если бы защитный экран в микроволновой печи «запирал» излучение внутри нее полностью, извне также нельзя было бы воздействовать на содержимое микроволновки. Существует тест с мобильным телефоном: устройство нужно поместить в неработающую печь и позвонить на него. Ранее считалось, что если телефон зазвонил, то устройство некачественное и пропускает СВЧ-лучи. Но поскольку экран в микроволновке все же пропускает излучение, этот тест может быть не корректен, — объясняет Эргаш Нуруллаев.
Кстати, страх перед микроволновой печью возник из-за мифа о том, что она излучает радиацию. Сейчас мы знаем, что это не так: в ее механизме не используются радиоактивные вещества.
Что излучают мобильные телефоны?
От смартфонов исходит комплекс излучений, в который входят микро- и радиоволны, инфракрасное (тепловое) излучение, а также малые порции низкочастотных волн в диапазоне от 2 до 15 Гц. Последние — самые небезопасные, поскольку по частоте совпадают с колебаниями молекул головного мозга, из-за чего при приближении телефона к уху происходит резонансное поглощение лучей и частицы мозга начинают разрушаться. Микроволновое излучение, как в случае с микроволновкой и едой, нагревает молекулы нашего организма, что также может привести к патологии.
— Самое сильное излучение телефон испускает во время звонка, когда передает сигнал от вышки сотовой связи. Разовая доза такого облучения вреда не принесет — она слишком мала. Однако это воздействие имеет накопительный эффект. И негативные последствия от беспрерывного использования мобильных устройств могут настигнуть через 40-50 лет в виде заболеваний иммунной системы, психических отклонений, заболеваний раком, — отмечает ученый-физик ПНИПУ.
Особенно восприимчивы к микроволновому излучению маленькие дети, у которых еще не сросся родничок, — мягкий участок между черепными костями. К тому же головной мозг ребенка содержит больше жидкости, чем жира. В таком случае ткани будут лучше поглощать электромагнитные лучи.
Как можно защититься от сверхвысокочастотного излучения? Одним из вариантов будет положить в чехол от телефона алюминиевую пластинку, которая оградит вас от лишнего излучения, когда телефон лежит в кармане и не используется. А во время звонка устройство лучше держать на расстоянии от головы и по возможности сократить время разговора. На время сна специалисты рекомендуют держать телефон минимум в полуметре от головы, ни в коем случае не класть его под подушку или на кровать рядом с собой.
Почему вредно читать в транспорте?
Персональные компьютеры — незаменимый инструмент для работы, и ограничить исходящее от него излучение алюминиевой пластинкой не получится. За последние 10-15 лет количество микроволнового излучения от них уменьшилось. Тем не менее дополнительным источником излучения является Wi-Fi-роутер, заменить который можно менее удобным интернет-кабелем.
Не стоит забывать, что экран ноутбука (как и смартфона) излучает свет. Разрушить структуру молекул в нашем организме или вызвать ожог он не может, но способен испортить зрение сильной пульсацией. Человек зрительно различает частоты в диапазоне от 35 до 60 Гц. Показатель выше 400 Гц не имеет влияния на организм человека, поскольку на таких частотах просто не воспринимаются сетчаткой глаза. Но значения ниже этого будут утомлять глаза, что в последствие приведет к снижению остроты зрения.
— Даже если ваше устройство, смартфон или ноутбук, имеют комфортный показатель пульсации, вибрация, возникающая из-за движения транспорта, создает колебания, которые мешают глазу сфокусироваться на тексте или изображении. Это перетруждает зрение, — добавляет Эргаш Нуруллаев.
Где разместить гаджеты, чтобы снизить риски от излучения?
Мобильный телефон на время сна специалисты рекомендуют держать минимум в полуметре от головы, ни в коем случае не класть его под подушку или на кровать рядом с собой. Лучше всего, если любые гаджеты будут удалены от кровати на 2-3 метра. Роутер для Wi-Fi можно разместить в нежилой зоне, например, коридоре, подальше от спального или рабочего места.
Следует понимать, что излучение — это распространяющееся в пространстве изменение состояния электромагнитного поля. Закон обратных квадратов говорит, что воздействие этого поля уменьшается пропорционально расстоянию то источника излучения, взятого в квадрат. То есть если разместить Wi-Fi-роутер или умную колонку в два раза дальше, то мощность излучения от них уменьшится в 4 раза.
Приборы с электромагнитным излучением окружают нас постоянно. Их длительное воздействие продолжают исследовать, при этом в России такие товары проходят обязательную проверку на допустимый уровень излучения.
В последние годы эволюция роботов подошла к черте водораздела, породив две уникальные ветки развития: мягкую и жёсткую робототехнику.
мягкий робот
С экзоскелетами произошло то же самое. Так называемый «жёсткий» экзоскелет стал своеобразным эталоном для большинства приборов этого класса. Он повышает силу человека, позволяя поднимать тяжёлые грузы и снимая избыточное напряжение с костей и связок. Разумеется, экзоскелеты вызывают большой интерес у спасателей, пожарных и медиков, которые работают в условиях больших нагрузок. Экзоскелет, в первую очередь, «заточен» под биомеханику человеческого тела и должен работать в плотной интеграции с опорно-двигательным аппаратом носителя. Эта черта выступает основным ограничением для экзоскелетов, но в ней же сокрыт и потенциал их развития.
Контакт тела с плотной деталью экзоскелета быстро вызывает конфликт между ней и живыми тканями. Обойти его можно двумя путями: использовать биологически инертные и нетравматические материалы или же физически разделить человека с роботизированной периферией. Первый подход неплохо показывает себя в деле бионического протезирования конечностей. Второй использовала научная группа, которая занималась разработкой «третьей» руки.
Но кроме силы существуют и другие параметры. В первую очередь — выносливость. Во вторую — ловкость. А вот с ловкостью у «жёстких» экзоскелетов большие проблемы. Сложная система рычагов и приводов, характерная для классического подхода к носимой робототехнике, мало напоминает одежду.
Мягкий экзокостюм не наделяет человека сверхъестественной силой. Вместо этого он поддерживает работу врождённой мускулатуры, позволяя экономить энергию во время марш-бросков и выполнения стереотипных движений. Вместо прибавки к силе он повышает выносливость человека. Функционирование устройства осуществляется по интуитивно понятному принципу. Его суть — помощь в подошвенном сгибании и разгибании голеностопного сустава, а также аналогичных действиях по отношению к бедру.
В биологическом организме движителем выступают мышцы. Сокращаясь, они тянут сухожилия, а те, в свою очередь, передают усилие на кость. Интересен факт, что наши рычаги не слишком эффективны. Точка на кости, где «сидит» сухожилие, расположена вдали от дистального конца руки или ноги. Тянуть рычаг за короткое плечо — значит проиграть в силе. С другой стороны, такая особенность анатомии даёт ощутимую прибавку к скорости движения.
Именно поэтому все наземные животные адаптированы к отталкиванию от поверхности. Но тут возникает новый вопрос: почему человек не опрокидывается во время ходьбы? Посудите сами — наш центр масс расположен достаточно высоко. Во время движения мы переносим точку опоры, регулярно оказываясь в состоянии контролируемого падения.
Если рассматривать стоячего человека как математический маятник, то у него будут две точки равновесия — верхняя и нижняя. Точки равновесия можно описать как состояния системы с наименьшей энергией. При этом равновесие в верхней точке будет неустойчивым и нарушится от любого возмущения. Или нет? Выяснить это наверняка помогает маятник Капицы. Этот прибор поражает своей неочевидностью. Груз, прикреплённый к нерастяжимой спице, соединён с вибрирующим подвесом. В случае цикличных вибраций подвеса по направлению вверх-вниз наш грузик не просто выталкивается в возвышенное положение — он как бы застревает там
Вибрационная механика родилась в тот момент, когда академик Капица сумел разработать математический аппарат для описания уже известных колебательных процессов.Человеческое тело приобретает устойчивость во время ходьбы за счёт колебательных движений голеностопного сустава. Во время шага или бега любой из нас напоминает перевёрнутый маятник, чей центр находится около стопы, а подошвенная поверхность играет роль вибрирующего основания. Центр маятника не стоит путать с центром массы. Наше прямохождение развивалось в ходе долгих эволюционных процессов, но даже они так и не смогли решить проблему возможного опрокидывания человека.
Вернёмся к экзокостюму. Исходя из принципов биомеханики ходьбы, учёные получили возможность прямо влиять на перевёрнутый маятник и даже усиливать его конструкцию.
Устройство состоит из двух критически важных блоков: системы срабатывания и передающего комплекса, который транслирует усилие на приборы-исполнители. Первый блок установлен в рюкзаке армейского образца. Тросы Боудена выступают проводником, через который экзокостюм развивает необходимое усилие.
Контроллер функционирует пошагово. Он разбивает программу движения на комплекс итеративных команд. Так обеспечивается многосуставная помощь для сгибания подошвы и разгибания бедра во время шага. Этот метод хорошо показывает себя, когда усилие формируется в соответствующий момент. Для этого был разработан весьма прогрессивный метод онлайн-мониторинга, о котором будет рассказано позже.
Контроль эффективности
Как определить реальную эффективность костюма? Ответ простой: замерить метаболические затраты человека с этим устройством и без него. Для этого испытуемым предложили идти по беговой дорожке со скоростью 1,5 м/с, неся на плечах рюкзак весом 6,8 килограмм.
Результаты оказались интересными. Начнём с того, что в подобных исследованиях существует множество «подводных камней». Главным, но отнюдь не единственным выступает индивидуальная анатомия. Все люди разные, хоть и относятся к одному биологическому виду. Кто-то экономно расходует энергию, а кто-то прожигает питательные вещества, как мартеновская печь. Следовательно, константа, выведенная для конкретного добровольца, может оказаться мало применимой к другому!
Метод онлайновой настройки параметров позволяет нивелировать этот негативный эффект и динамически адаптировать экзокостюм под потребности конкретного носителя. Для начала исследователи строили положительную карту возможностей. Она описывает спектр воздействий, позволяющих повышать усилие голеностопного сустава и не наносить ему травматических повреждений.
Калибровка экзоскелета
Любой экзоскелет — это устройство для расширения человеческих возможностей. Даже наиболее совершенные гаджеты не могут выступать в роли телепатов. Чтобы механика «разобралась», чего от неё хотят, нужно каким-то образом наладить контакт приводов с нервной системой человека.
Исследовательские группы по всему миру активно работают над разработкой методов управления, но аспекты адаптивной настройки контроллера до сих пор представляют изрядную сложность. Традиционный подход сводится к ручной настройке экзоскелета. Оператор или носитель устройства смотрит на параметры походки, а после вносит исправления. При всей простоте этот метод априори будет субъективным. Значит, оператор должен быть весьма продвинут в работе с программно-аппаратной оболочкой экзоскелета. Более современное решение — отдать часть «скучной» работы на своеобразный аутсорс.
В этом случае на носимом компьютере будут непрерывно обрабатываться сложные алгоритмы, чей список весьма обширен:
Принятие решения, в какой момент направить физическую помощь суставу.
Для этого система должна знать, от чего ей отталкиваться. Метаболические затраты человека можно исследовать разными способами, но самым простым выступает измерение дыхания. По его частоте, глубине, а также концентрации углекислого газа на выдохе можно делать выводы о том, насколько интенсивно протекает энергетический обмен.
Динамические модели передвижения всегда ориентированы под конкретную модель экзоскелета. Вычислительные алгоритмы представлены множеством вариантов. К ним относят обучение пользователя с помощью инструктора, поиск экстремумов и адаптивное динамическое программирование.
Как уже говорилось в этой статье, многосуставной мягкий экзоскелет облегчает ходьбу через подошвенное сгибание, а также разгибание в тазобедренном суставе. Его компоненты представлены поясным ремнём, двумя набедренными блоками, мягкими подвесами между икрами и передней частью талии, а также специальной обувью. Общая масса всех комплектующих — всего лишь 1 кг 100 г с учётом двух металлических кронштейнов на задниках ботинок.
Устройство активно взаимодействует с ногой через две точки приложения:
Сгибание бедра во время первой фазы отталкивания.
Многосуставное разгибание, после которого наступает новая стадия ходьбы.
На этом изображении видны компоненты экзокостюма и некоторые устройства для аппаратного облегчения ходьбы. А: Красные и синие линии — прокладки тросов Боудена. Толстыми линиями обозначены оболочки, а тонкие показывают ход самих тросов. Зелёные и жёлтые кру
Обратим внимание на исполнительную систему. Её части расположены в рюкзаке. Четыре независимых приводных блока обеспечивают развитие усилия. Механизм-исполнитель представлен безрамным шестиполюсным мотором Emoteq от американской компании Allied Motion Ink. Коробка передач Spiroid обеспечивает передаточное число 38:1 для приводных блоков и 36:1 в случае процесса разгибания бедра.
Исполнительная система передаёт развиваемое усилие на экзокостюм с помощью тросов Боудена. То есть при втягивании струны сокращается расстояние между несколькими точками крепления, которое можно и нужно замерить. Желательно — в режиме онлайн.
Всё это запитано от литий-полимерного аккумулятора весом 2 кг. Его заряда вполне хватает на 8 км непрерывной ходьбы.
На каждой ноге испытуемого расположено по шлейфовому жгуту. Он включает пять инерциальных блоков для динамических измерений: IMU, MTi-3, а также два тензорных датчика LBS200. Эти приборы собирают данные в реальном времени. Блоки инициируют каскад принципиально важных замеров, таких как определение ориентации экзоскелета в плоскости движения, а также угловой скорости каждого сегмента.
Датчики нагрузки идут параллельно с боуденовскими тросами. Они мониторят уровень вспомогательной силы, которая направляется носителю системами экзокостюма.
Экзокостюм обеспечивает поддержку ходьбы, втягивая тросы Боудена синхронно с движениями в суставе. Профили положения троса рассчитываются исходя из четырёх параметров: Т0, Т1, Т2 и Т3. Каждый из них занимает определённую процентную величину в цикле ходьбы. Следующие параметры, PosOffset и PosMax, можно получить, выполнив комплекс итеративных вычислений во время работы устройства.
На этом изображении представлены данные о работе многосуставного контроллера. Вверху обозначен профиль положения боуденовского троса. Результирующий профиль, через который выражена вспомогательная сила, можно видеть ниже.
Уделим немного внимания разбору этих циклов:
Т0 определяет пределы цикла походки и время запуска контроллера.
Т1 — точка активного втягивания троса.
Т2 выражается в момент завершения активного втягивания — то есть когда механика прекращает адаптивную помощь.
Отпускание троса закодировано в Т3.
Соответственно, PosOffset проявлена в точке Т1 выражает максимальное вытягивание троса Боудена, а PosMax — экстремум, при котором струна оказывается полностью втянута. Он длится от Т2 до Т3.
Удар пятки о поверхность — момент, в который запускается работа экзокостюма. Львиная доля помощи во время фазы отталкивания осуществляется именно в виде реакции на этот триггер. Зелёный цвет выделяет фазу активного втягивания троса. Параметры этой фазы определены промежутком между Т1 и Т2. Настройка параметров управления происходит в тесной интеграции с данными об увеличении развиваемого усилия.
Эта иллюстрация демонстрирует репрезентативные данные о работе контроллеров сгибания бедра. Вверху показан профиль положения троса Боудена. Снизу — результирующий профиль вспомогательной силы. В данном случае поддержка разгибания начинается с выявления точ
И здесь мы подходим к более сложному вопросу: механизму работы контроллера, который следит за нагрузкой в нескольких суставах. Сначала происходит удар пятки в нижней точке траектории. Это не остаётся незамеченным для гироскопа. Такое событие выступает триггером для запуска многосуставного контроллера Т0МА. Тогда включается двигатель, обеспечивая втяжение троса со скоростью 394 мм/с. Такое значение удалось получить в ходе многочисленных испытаний. Если скорость будет ниже, то экзоскелет и носитель начнут работать вразнобой. При ускорении втягивания возникает иной риск — вызвать сгибание до того, как оно понадобится в следующих фазах ходьбы. В таком случае возможно падение человека, а подобных инцидентов следует избегать.
Таким образом устройство достигает PosOffset и сохраняет положение до начала активного втягивания троса в Т1. Оно будет длиться вплоть до PosMaxМА, чья финальная точка — положение Т2.
Затем контроллер фиксирует положение троса, пока тензодатчик не распознает падение силы носителя, которое проявляется во время сгибания голеностопного сустава. Выяснив, что сейчас человек готовится к новому шагу, экзокостюм начинает отпускать трос.
Скорость выпускания зависит от ритма ходьбы. Её верхняя граница — 606 мм в секунду, пока система не достигнет нулевого положения. В нём трос пассивно повисает, чтобы испытуемый не испытывал затруднений при повороте тела и смене траектории. На этом цикл активной помощи можно считать завершённым. После удара пяткой он снова запустится, проходя те же самые итерации.
В конце каждого шага контроллер динамически определяет, уменьшить или увеличить PosOffset PosMax для следующего шага. Это решение принимается исходя из сравнения желаемой и измеренной силы. Учёные экспериментально выявили, что оптимальной пиковой силой в PosOffset будет 75 Н, которая будет приложена во временной промежуток между Т0 и Т1. PosMax обеспечивает пиковую силу в 400 Н между Т1 и Т3 соответственно. Выходит, 400 Н — это и есть выигрыш в силе, которая проявлена во время активного втягивания кабеля.
Это устройство предназначено для помощи в походке, когда разгибательная мускулатура бедра проявляет наибольшую активность. Нюансы биомеханики таковы, что максимальное сгибание бедра наступает на 12% быстрее, чем контакт пятки с поверхностью. В этом случае Т0 соответствует отметке в 0% от полного сгибания бедра. С этого момента двигатель начинает втяжение троса со скоростью 800 мм/с, пока система не достигнет PosOffset.
Такое состояние поддерживается, пока ползунок не заполнится до 7%. От 7 до 28% наступает повторное втяжение троса, которое закончится PosMax на 28%. Пройдя немного больше четверти глобального цикла, контроллер дожидается 34% сгибания. В этот момент наступает следующая фаза работы: отпускание троса со скоростью 800 мм/с.
Контроллер разгибания бедра обеспечивает поддержку в 10 Н в PosOffset между Т0 и Т1, которая переходит во взрывное увеличение силы до 300 Ньютонов между Т1 и Т3. Звучит неплохо, но многосуставная помощь требует калибровки под конкретного человека. Здесь в полной мере раскрывается потенциал онлайновой настройки параметров управления, благодаря которым получится обеспечить максимальную силу, развиваемую в голеностопном суставе. Этот показатель имеет явную корреляцию с метаболическим преимуществом, ради которого и был начат столь прорывной эксперимент.
В цикле ходьбы существует великое множество важных точек. Из него экспериментаторы особенно выделяют два параметра: Т1 и DMA, который рассчитывается по простой формуле DMA = Т2МА — Т1 МА. Следовательно, через DMA выражена продолжительность активного втяжения троса.
Показатели Т1 и DMA лучше всего отображают состояние троса во время активной фазы отталкивания — следовательно, именно в этот момент экзокостюм сообщает большую часть силы голеностопному суставу. Исследователи разработали весьма аскетичный алгоритм, позволяющий наблюдать критически важные параметры ходьбы в режиме онлайн. Настройка занимала 15 минут, пока испытуемые ходили по беговой дорожке. Многосуставной контроллер не сидел без дела, активно замеряя 16 параметров, а также отыскивая те настройки, при которых адаптивная помощь даст максимальный прирост силы.
Всё начиналось с проверки четырёх стартовых условий, при которых Т1 изменяется в пределах 35, 40, 45 и 50% от глобального цикла сгибания бедра. В это же время DMA оставался неизменным на протяжении начальных 15% временного интервала. Среди этих четырёх значений устройство находило такую настройку адаптивной помощи, при которой лодыжка развивает максимальное усилие. При этом экзокостюм получил ряд ограничений, не дающих развивать прирост силы более 400 Ньютонов.
Повторяя эти проверки каждые 2,5-5,0% от длительности цикла, программная оболочка находила значения, при которых прирост силы укладывался в заданные коридоры. Преимущества такого алгоритма состоят в его простоте. Процесс тонкой настройки состоял в динамической смене двух параметров управления. Каждая математическая развёртка по двухмерной матрице учитывала лишь один параметр, а второй оставляла неизменным.
Существуют и другие методы проводить этот комплекс алгебраических вычислений, но такой подход позволял выяснить, в какой мере изменение одного параметра влияет на все остальные процессы во время ходьбы.
Тестирование
Тестирование экзоскелетов включает ходьбу с нагрузкой без экзокостюма, с отключенным устройством и те же самые действия при включенном гаджете.
Для чистой скорости метаболизма и процентного снижения его интенсивности учёные выявили два важных критерия. Ими стали межсубъектное среднее значение и стандартная ошибка среднего значения. Двусторонние парные t-тесты определили статистическую значимость для разницы в чистой скорости между двумя состояниями.
На следующем рисунке можно видеть положительную карту возможностей для увеличения силы, развиваемой в голеностопном суставе:
Так выглядит положительная карта мощности во время настройки контрольных параметров. Звёздочки отражают условия, за которыми наблюдали системы контроля. Числа под каждой из них — положительная односторонняя мощность усиления. Она выражена в ваттах. Стрелки
На следующей картинке показаны параметры управления для конкретного испытуемого, найденные методом адаптивной настройки параметров по результирующим профилям. Начало втягивания троса у пользователя происходило во время фазы Т1 или 43,75-46,25% цикла ходьбы. При этом DMA варьировалась от 13,75 до 22,5%. Эти различия неизбежно приводят к возникновению широкого диапазона профилей силы.
Использование многосуставного мягкого экзокостюма существенно улучшает энергетические затраты на переноску грузов. Как видно из приведённых данных, включенное устройство экономит до 15% энергии носителя и понижает скорость его метаболизма на 20-24%:
Здесь показаны метаболические затраты на переноску груза, собранные по данным трёх статистических выборок. Сплошные столбцы отображают усреднённое значение чистой скорости метаболизма. Двойные звёздочки указывают, что разница между двумя условиями (работа
Экзоскелет оказался жизнеспособным. Он принёс явную метаболическую пользу, сделав движения носителя менее затратными.
Резидент "Сколково" компания "КардиоКВАРК" представила кресло, которое делает ЭКГ за минуту. В кардио-кресло встроили электрокарограф, который позволяет самостоятельно проверить здоровье. Устройство можно располагать в общедоступных местах.
Для исследования показателей ЭКГ пользователю не нужно раздеваться, достаточно сесть в кресло и положить руки на рукоятки, к которым крепятся электроды.
Далее нужно будет пройти регистрацию в программе и ввести свой номер телефона, на который через минуту придут результаты.
Издание involta.media добавило, что на официальном сайте его можно купить за 189 тысяч рублей.
Думаю, многие мои читатели встречались с таким неприятным явлением, как отвал чипа. Эта поломка свойственна многим топовым и околотоповым гаджетам из нулевых: ноутбуки с «отваливающимися» видеочипами и мостами, первые ревизии Xbox 360 (три красных огня) и PlayStation 3 (жёлтый огонёк и моментальное выключение), телефоны-«ударники» и другие девайсы с достаточно горячими чипами. Недавно я листал барахолки на предмет интересных девайсов «за копейки» и наткнулся на топовый игровой ноутбук 2007 года выпуска всего за 1.000 рублей (~10$) — Toshiba <модель>, с просто дичайшими характеристиками для тех лет: GeForce GTS 7900 Go, Core Duo Txxx, 1гб DDR2 ОЗУ и аудиоподготовкой от Harman-Kardon.
Сегодня мы с вами узнаем: почему отваливаются чипы и как продлить жизнь старому топовому железу, «дунем» на видеочип, «воскресим» его на некоторое время и посмотрим, что же крутого было в топовых ноутбуках тех лет. Интересно? Тогда добро пожаловать под кат!
❯ Почему чипы «отваливаются»?
В мире производства электроники и плат есть несколько различных видов монтажа чипов на платы. Все они зависят от корпусировки того или иного элемента. Обычно, сложные микросхемы выпускаются в нескольких различных корпусах, которые отличаются маркировкой и иногда функциональностью. В современном мире принято использовать несколько самых распространенных типов корпусов:
DIP— один из самых старых и тем не менее, до сих пор распространенных видов корпусов для чипов. Для таких микросхем сверлятся отверстия в плате, а затем чипы вставляются в отверстия и припаиваются, благодаря чему чип надежно держится на плате. Плюсов у такого способа довольно много: удобство пайки, возможность лёгкой установки чипа в сокет и быстрой его замены (привет Arduino и чипы памяти с BIOS на старых материнских платах), большая надежность соединения, и вероятно, простота производства. Минусов у такого способа тоже хватает: невозможность сделать микросхему с очень большим количеством пинов, громоздкость чипа, без фена чипы с большим количеством ножек выпаять проблематично. Известные примеры: сдвиговые регистры, МК AVR, Z80, MOS6502.
QFP/QFN/SOIC— современный способ монтажа чипов с большим количество пинов на плату. По принципу все они похожи: по разным сторонам микросхемы есть выводы, которыми можно припаять чип к плате. Однако у QFP ножки «торчат» наружу, что даёт возможность легко припаять их к плате, а у QFN контакты спрятаны под пузом самого чипа, из-за чего их можно припаять только феном (если чип достаточно мал — можно попробовать паяльником). Плюсы: надежность пайки, относительная простота монтажа и демонтажа (дунул и чип слетел). Минусы: для таких чипов практически нет сокетов (на самом деле есть, но особо никакой унификации нет — чаще всего сокеты можно встретить в материнских платах и программаторах у ремонтников). SOIC немного другой тип монтажа, поскольку там ножки выводятся только по бокам чипа (как у DIP), но я не стал выносить его в отдельный типаж.
LGA/PGA/SMT— кристалл или кристаллы (пример — процессорное ядро и отдельно кэш-память на старых процессорах) распаяны на специальной небольшой плате, которая называютсяподложкой. Такие микросхемы обычно предназначаются для установки в сокет (процессоры), либо для пайки платы на плату (SIM800L). Даташит на SIM800C называет свою корпусировку какSMT, поэтому я отнесу его и различные системы на модуле («процессорные» платы с ОЗУ и ПЗУ) к LGA. Один раз я видел PGA-процессор AMD Geode, который запаивали напрямую штырями в плату — но может, меня обманывает память.
BGA— основной тип корпуса для сложных и компактных микросхем таких как SoC или видеочипы. Его суть проста: на плате и на нижней стороны чипа есть маленькие пятачки круглой формы (их размер отличается в зависимости от числа пинов, но стандартизирован), благодаря которым микросхема припаивается к плате. Такой корпус позволяет компактно вывести довольно большое количество пинов — например, SoC MediaTek MT6572 поставляется в корпусе аж с 428-шариками! С завода чипы приходят с уже накатанными шарами, в то время как работнику или машине остаётся их только припаять на плату. Несмотря на большое количество крошечных пинов, при наличии сноровки и должном оборудовании, пайка микросхем очень простая: физика всё сделает за вас и сама «притянет» чип к нужным пятачкам на плате. Это один из самых распространенных корпусов для микросхем и один из самых проблемных. Но почему? Давайте разбираться!
Отвал BGA-чипов далеко не всегда связан с термическим воздействием, как принято считать в широких кругах (от чего и идут советы по типу «погрей видяху в духовке»). Шарики достаточно сильно подвержены влиянию множества внешних факторов: попадание воды — в таком случае, шарики окисляются и со временем могут отгнить вместе с пятачками, падениям — такие устройства называются «ударниками» и шары могут дать микротрещину, что уже может сказаться на нестабильной работе устройства, и в немалой степени — термическому воздействию. Причём здесь мнение делится на два лагеря и сильно зависит от самого устройства.
Отвалы на смартфонах/планшетах в основном являются следствием неудачного падения и лечатся перекаткой уже установленного процессора, иногда — заменой на точно такой же «донорский» и с идентичной маркировкой (да, среди SoC бывают свои «подверсии»). Реже бывает срывает пятачки — тогда опытные мастера ковыряют плату и ставят перемычки вместо отвалившихся шаров (моё почтение вам!). В последнее время замена отдельных чипов на мобильных устройствах сильно затруднена: у девайсов есть жёсткая привязка между ID-процессора (прожжен на заводе в SoC), ID-процессора, записанного в флэш-памяти устройства (в специальном RPMB-разделе, доступный только для чтения, используется для Secure Boot, просчета ключей, шифрования и т. п.) и привязки к модему (насчет Android-устройств точно не могу сказать, но у iPhone такая привязка есть ещё с начала 10х годов: в один момент, после очередного апдейта iOS, многие девайсы с замененной NAND или процессором без замены всех трех чипов, висели на «сбое активации» — и в официальном сервисе такой аппарат не принимали), из-за чего при замене процессора или флэш памяти, придётся менять вообще всю пару на оный с донорского аппарата (а в случае iPhone — еще и не привязанный к iCloud).
Нормальные мастера обычно именно перекатывают чипы, т. е. снимают старые шары и накатывают с помощью трафарета новые, поскольку прогрев может поднять устройство, но это не ремонт, а лишь диагностика — такое устройство может в любой момент «отвалиться». Правда, есть и исключения.
Другой вопрос — отвалы чипов на ноутбуках и десктопах. На десктопных материнских платах отвал — не очень частое явление, поскольку отваливались обычно «горячие» северные мосты по типу nForce (которые славились довольно неплохими интегрированными GPU — тут уж попробуй не нагрейся при очень слабеньком пассивном охлаждении). Сейчас «северник» переместился в процессор, поэтому свежим десктопным материнкам это почти не грозит, однако другое дело — ноутбуки.
Система охлаждения на ноутбуках частенько подразумевает расположение ЦПУ и чипсета (а иногда и GPU) на одной теплотрубке, из-за чего тепло отводится заметно менее эффективно. А особенно ситуация плохая на тех девайсах, которые никто не чистит. И если процессор ещё может начать троттлить (занижать частоты) для того, чтобы понизить температуру ниже определенного порога — то что делать чипсету? После пары лет работы в таком режиме, девайсы внезапно начинают виснуть посередине работы, перезагружаться, выключаться или выдавать непонятные артефакты. Тем же самым когда-то страдала печально известная первая ревизия Xbox 360 — Xenon, которая выдавала три красных огня. Не обошла проблема и PS3 — вспоминаем желтые глазки и выключение устройства.
Даже если взять пример с Xbox 360, когда игрок нёс устройство в неофициальный СЦ, ему перекатывали горячий GPU от ATI (отваливался именно он) и снова припаивали к плате, включили — устройство работает и выдали обратно игроку. Игрок приходит довольный домой, играет день, месяц или даже год и… сталкивается с той же самой проблемой! Снова три красных огня, хотя девайс вроде бы чистый, шуба пыли из него не торчит, а при разборке оказывается, что система охлаждения визуально в норме и кулер работает… в чём же тогда дело?
Всё дело в том, как припаивается кристалл процессора или GPU к плате-подложке. По сути, подложка может быть любой, хоть LGA, хоть BGA: китайские умельцы как-то приноровились делать десктопные подложки для мобильных процессоров в BGA-корпусах. Но сам кристалл припаивается к подложке с помощью точно таких же BGA-шариков, как и подложка к плате, только гораздо меньших размеров. Перекатать такие шары доманевозможно, это можно сделать только в заводских условиях. Но поскольку сами кристаллы залиты компаундом (как раз таки с целью предотвратить внешнее влияние, в том числе и термическое — иначе кристаллы сдувались бы только так), а шарики достаточно маленькие — при прогреве устройства феном, в духовке (популярный когда-то метод), или даже перекатке шаровна подложке, из-за термического воздействия контакт между кристаллом и подложкой на время восстанавливался. Однако поскольку GPU Xbox 360, который я привожу в пример, очень и очень горячий сам по себе, вне зависимости от того, как хорошо от него отводится тепло, со временем контакт кристалла с подложкой снова нарушался и устройство переставало работать…
Происходило это по причине выбора неправильного типа припоя: в целях сохранения природы, использовался не совсем верный состав. Однако зная о проблеме, производители продолжали использовать его примерно до середины 2010-х годов: насколько мне известно, GeForce 1xxx серии и выше не страдают отвалами GPU вообще (но там своих болячек хватает — как минимум, те же банки памяти). Почему так происходило? Вероятнее всего, это изначально закладывание ресурса в технику. И если бюджетные ноутбуки со встроенной графикой и Celeron'ами от этого особо не страдали (их до сих пор очень много на юлито, живеньких и вполне рабочих), то топовые и дорогие устройства с горячими видеочипами отваливались только так…
Прогрев — это исключительно диагностический способ, им можно пользоваться либо в домашних условиях «для себя», либо для того, чтобы выявить неисправность одного из элементов устройства. Брать деньги за прогрев — прямой обман, но если делать просто «для себя», ради того, чтобы немного продлить жизнь крутому девайсу из прошлого — почему бы и нет? Предлагаю в практической части нашей статьи глянуть на топовый ноутбук 2007 года отToshiba, который я купил всего за 1.000 рублей (~10$). Девайс сам по себе очень крут, однако страдал отвалом GPU, который мы на время «вылечим»!
❯ Практическая часть статьи
Сегодняшнего подопытного продавала женщина на запчасти. Состояние было неизвестным: я не спрашивал её ни о симптомах поломки, ни о том, включается ли ноутбук вообще. Я списался с продавцом, договорился об условиях доставке и зарезервировал девайс себе. Через несколько дней ноутбук наконец-то приехал ко мне и я решив не медлить, сразу полез его диагностировать:
Внешне девайс очень симпатичный и сейчас — самое время его включить! Единственный нюанс: проприетарный трапецевидный разъем зарядки. Не беда: до этого я брал другой тошибовский ноутбук за… 300 рублей, который тоже оказался вполне живым, но у него были сломаны петли ( к буку за 3 доллара шёл и родной БП, который уже кто-то ремонтировал на скрутках, но он всё ещё оставался рабочим).
Включаем девайс, прощелкиваем нумпадом и видим, что реакция на него есть, однако изображения нет! Это значит, что ноутбук нормально проходит POST и висит на «CMOS Error, F1 to Continue», однако отсутствие картинки было для меня первым звоночком винить видеочип. Поскольку POST ноутбук проходил, то и реагировал на хоткей смены матрица/VGA: подключаем внешний монитор и видим…
Да, это самый классический отвал GPU. Ну а что вы хотели, GeForce 7900 это вам не шутки! Поскольку это ноутбук с дискреткой 7 серии, ни о каком UMA и речи не идет: отключить GPU и направить вывод на встроенный адаптер не получится. Вернее теоретическая возможность то есть, но линии LVDS/VGA идут с GPU, а не с хаба, как это происходит в современных ноутбуках. Девайс то может и включится, но никакой картинки вообще не будет — если устройство вообще пройдет POST.
Самое время разобрать красавца. Делается это не особо сложно: классическая разборка «с клавиатуры». Для обслуживания системы охлаждения придётся разбирать ноутбук полностью (в том числе снимать матрицу), но никаких особых проблем с этим не возникает: девайс хорошо продуман. При разборке выяснялась причина отсутствия изо на LVDS — матрицу банально отключили. Девайс явно обслуживали до меня и чистили, видимо в надежде что всё «оживет». А может и грели уже, кто его знает? :)
Да, «охлад» здесь и правда довольно серьезный: круче я видел только в ноутбуке с дискреткой ATI и… десктопным Pentium 4!
На ноутбуках тех лет частенько практиковались по настоящему съемные видеокарты. Помимо стандарта MXM (его сейчас вроде только Clevo как-то поддерживает), который предусматривает замену видеокарты в ноутбуке, некоторые вендоры придумывали свои коннекторы а-ля PCI-E. Наш девайс как раз из таких: видеокарту, при желании, можно было заменить на идентичную (возможно и какие-то другие от младших «тошиб» подходили, но мне это неизвестно).
Снимаем массивную систему охлаждения, которая отводит тепло и от GPU, и от чипов памяти и приступаем к прогреву. Для прогрева подойдет фен от паяльной станции, или даже регулируемый строительный фен (с ним осторожнее, есть шанс угреть чип). Для наглядности «дриставрации», я буду пользоваться именно строительным «интерсколом». Ставим температуру ~250 градусов (в случае строительных фенов — это погода на луне или попугаи, ну или средний режим) и осторожно греем кристалл по периметру. Для временного оживления чипа хватит дунуть секунд 15-30. Дольше не стоит — могут повылазить шары. Никаких утюгов и духовок — это кощунство!
Подсобираем ноутбук и включаем его. Ура, в биосе изображение есть и на первый взгляд всё нормально. Однако, после такой «дриставрации», проблемы могут вылезти где угодно: ошибка 43, артефакты в 3D-режиме, самопроизвольные ребуты и зависания системы. Самое время накатить систему и проверить это.
И таки да, они вылезли практически сразу, причём совершенно с неожиданной стороны. Девайс начал самопроизвольно отключаться в определенные моменты времени (обычно при старте Windows и игр), причём вне зависимости от подключения БП (отметаем версию, что АКБ не держит нагрузку) и заряда аккумулятора (отметаем, что не хватает мощности БП), а температуры судя по датчикам — в норме. Вероятнее всего, проблема в питальниках на GPU/CPU.
К сожалению, нормальные тесты при таких условиях сделать не получится — девайс нужно диагностировать дальше, но делать это с отвальным видеочипом такое себе. Но Proof of Concept есть: многие чипы вполне реагируют на прогрев и могут даже поработать какое-то время. Надолго ли?
❯ Заключение
Данный материал писался в эдаком «научпоп» стиле. Для опытных ремонтников, написанный текст отнюдь не станет каким-то откровением, но полагаю, было всё же интересно почитать о том, почему их любимые девайсы из нулевых «помирают».
Статья подготовлена при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, , чтобы не пропускать новые статьи каждую неделю!