как запустить приложение 64 бит на 32 бит на андроид
Как соответствовать новым требованиям Google Play
Начиная с 1 августа Google Play больше не будет принимать новые приложения или обновления приложений без 64-битной версии (если, конечно, вообще не существует нативного кода). Для пользователей Qt это означает, что вам нужно создать дополнительный APK, содержащий 64-битные двоичные файлы.
Qt поставляет 64-битные двоичные файлы для Android (начиная с Qt 5.12.0), поэтому с технической точки зрения соблюдение нового требования не представляет особой проблемы. Но после обсуждения с пользователями стало ясно, что не всем понятно, как настроить приложение в Google Play, которое поддерживает несколько архитектур одновременно.
Этот призыв о помощи в сочетании с тем фактом, что сейчас настраивается новая рабочая станция Windows (Windows work station), предоставило прекрасную возможность взглянуть на разработку приложений Qt для Android в целом. В этом блоге мы начнем с чистого листа и покажем, как начать работу на Android, а также как опубликовать приложение, соответствующее требованиям Google Play.
Первые несколько частей могут быть знакомы многим из вас, поэтому, если вам скучно, и вы хотите ознакомиться с основной темой, можете смело переходить к шагу 4.
Примечание о версиях SDK
SDK Android находится в стадии интенсивной разработки и довольно часто не имеет обратной совместимости, что вызывает проблемы с интеграцией в Qt. Хотя мы максимально быстро реагируем на проблемы, возникающие из-за изменений или регрессий в SDK, но общее практическое правило заключается в том, чтобы подождать, прежде чем обновиться до последних и самых лучших версий Android tools (инструментов Android), пока не появится возможность адаптироваться к несовместимости с Qt.
Хотя на других платформах также были некоторые проблемы, большинство проблем, которые мы видели, были связаны с Windows. Поэтому, если вы находитесь в этой хост-системе, будьте особенно внимательны и проверяйте наличие известных хороших версий перед настройкой среды.
В настоящее время мы рекомендуем использовать следующие инструменты вместе с Qt 5.13.0:
• Android build tools (Инструменты сборки Android) версии 28
• Android NDK r19
• Java Development Kit 8
Шаг 1: Установка JDK
Обратите внимание, что существует несовместимость между инструментом Android SDK Manager и более поздними версиями Oracle JDK, что делает последние версии JDK непригодными для использования вместе со средой Android. Чтобы обойти это, мы рекомендуем вам загрузить JDK версии 8 для использования с Android.
Вы можете использовать официальные двоичные файлы Oracle или другой вариант, такой как проект AdoptOpenJDK.
Загрузите и запустите установщик и установите его в папку по умолчанию.
Шаг 2. Настройка среды Android
В дополнение к SDK нам также необходимо установить NDK. Это набор разработчика, используемый для кросс-компиляции кода C++ для запуска на Android. Как упоминалось выше, мы будем использовать Android NDK r19c, а не последний выпуск, поскольку существуют проблемы с Android NDK r20 вызывают ошибки компиляции. Проблема будет решена в Qt 5.13.1 и Qt 5.12.5, поэтому, когда вы начнете использовать их, возможно обновление до Android NDK r20.
И как последний шаг, мы должны убедиться, что используем версию 28.0.3 Android build tools (инструментов сборки Android), а не последнюю версию. Обратите внимание, что это проблема только для хостов Windows.
Шаг 3: Установите Qt
Мы будем использовать Qt 5.13.0. Если вы этого еще не сделали, начните с загрузки онлайн-установщика из своей учетной записи Qt (Qt Account).
При запуске установщика убедитесь, что вы выбрали целевые архитектуры arm64-v8a и armv7a. Это технические названия, соответственно, для 64-битных и 32-битных версий процессоров семейства ARM, которые являются наиболее часто используемыми процессорами на устройствах Android.
Примечание. В частности, для этого примера нам понадобится Qt Purchasing (Qt Покупки), поскольку он содержит приложение, которое мы планируем использовать в качестве демонстрации. Его также можно выбрать из списка.
Если все настроено правильно, Qt Creator покажет зеленую галочку, и вы будете готовы приступить к разработке Android с помощью Qt.
Шаг 4: Настройка проекта в Qt Creator
Сначала мы откроем Qt Creator, что можно сделать с экрана приветствия. После того, как он был открыт, Qt Creator попросит нас выбрать, какие версии Qt мы хотим использовать для его сборки.
Чтобы соответствовать дополнительным требованиям в Google Play, мы хотим создать два пакета APK: один для 32-разрядных устройств и один для 64-разрядных устройств. Нам нужно настроить каждый из них в отдельности.
На этом снимке экрана показан пример установки для 32-разрядной сборки. Важные вещи, на которые следует обратить внимание:
За исключением директории сборки, настройка для 64-битной сборки должна быть такой же. Выберите 64-битный комплект с левой стороны и внесите в него эквивалентные настройки.
Шаг 5: Подготовка манифеста
Как отметил Феликс Барз в той же теме, это можно автоматизировать в файле .pro проекта. Вот слегка измененная версия его кода:
Этот трюк преобразует VERSION приложения в целое число и добавляет новую цифру, в наименее значимом конце, для обозначения архитектуры. Так, например, для версии 1.2.3 код версии будет 0010020030 для 32-разрядного пакета и 0010020031 для 64-разрядного.
Обратите внимание, что для более эффективной настройки вы, вероятно, захотите автоматизировать этот процесс. Это также вполне возможно, поскольку все инструменты, используемые Qt Creator, могут запускаться из командной строки. Посмотрите на androiddeployqt documentation для получения дополнительной информации.
Шаг 6: Опубликуем приложение в Google Play
Страница публикации в Google Play (Google Play publishing page) довольно-таки самодокументирована, и есть много хороших руководств о том, как это сделать, поэтому мы не будем проходить все этапы заполнения формы. В общем, просто заполните всю запрашиваемую информацию, предоставьте нужные изображения и убедитесь, что все галочки на левой боковой панели имеют зеленый цвет. Вы можете добавить все виды контента здесь, так что не торопитесь с этим. В конце концов, это повлияет на популярность вашего приложения.
Как только это будет сделано, вы можете создать новый выпуск в разделе App Releases (Выпуски приложений) и загрузить в него свои APK.
Стоит отметить, что при первом запуске вам будет предложено разрешить Google Play управлять ключом подписи вашего приложения.
Пока вам нужно будет отказаться от этого, выбрав Opt Out. Чтобы использовать эту функцию, приложение должно быть в новом формате «Android App Bundle». Он пока не поддерживается Qt, но разработчики также работают над этим. На самом деле, Богдан Ватра из KDAB (который также поддерживает порт Android на Qt) уже опубликовал патч (patch), который решает самую сложную задачу получения такой поддержки.
Когда мы получим поддержку, это сделает процесс выпуска более удобным. С форматом AAB Google Play будет генерировать оптимизированные APK-файлы для различных архитектур, но сейчас мы должны сделать это вручную, настроив несколько комплектов и создав несколько APK, как было описано ранее в этом руководстве.
Когда два APK-файла были загружены в релиз (release), вы должны увидеть список, такой как представлен на изображении выше: два отдельных пакета APK, каждый из которых охватывает одну собственную платформу. Развернув каждую из записей, вы можете увидеть, что такое “Differentiating APK details” («Дифференцирующая информация об APK»). Эти критерии используются для выбора одного из другого, когда устройство загружает APK из магазина Google Play (Google Play Store). В этом случае дифференцирующая деталь должна быть родной платформой.
Рекомендуем хостинг TIMEWEB
Рекомендуемые статьи по этой тематике
Возможен ли запуск 64-битных приложений в 32-битной операционной системе?
В настоящее время широко распространены 64-битные ОС [1]. Но и 32-битные ОС еще присутствуют на рынке в достаточно большом количестве. Многие современные программные средства разрабатываются исключительно для работы в 64-битном режиме, так как для обеспечения работоспособности программы и в 32-битной, и в 64-битной ОС требуются дополнительные трудозатраты и, соответственно, стоимость разработки повышается.
Для пользователей 32-битной ОС иногда возникает необходимость использовать программные средства, предназначенные только для 64-битной ОС. Что же делать, если пользователь не готов отказаться от 32-битной ОС как основной рабочей системы?
Для различных ОС существуют свои особенности, связанные с запуском 64-битных приложений в 32-битном окружении. При запуске 64-битного приложения непосредственно в 32-битном окружении теряется преимущество, связанное с возможностью использования большего количества оперативной памяти. Для поддержки 64-битных приложений ваш процессор должен обладать 64-битной архитектурой. Рассмотрим некоторые наиболее популярные ОС.
В Mac OS X ядро является гибридным. Оно позволяет одинаково работать любым приложениям в независимости от того, являются ли они 32- или 64-битными. Единственное отличие гибридного ядра от полноценного 64-разрядного — это невозможность использовать в системе больше 32 ГБ оперативной памяти. Поэтому на данный момент нет совершенно никакой разницы между загрузкой в 32- и 64-битном режимах. А вот в будущем разница обязательно появится по мере увеличения объемов использования ОЗУ и появления новых технологий.
Для ОС семейства Linux и 32-битных ОС семейства Windows запуск 64-битных приложений в 32-битном окружении осуществляется с применением технологий виртуализации [2]. Существует ряд специализированных программных продуктов, позволяющих установить виртуальную гостевую 64-битную OC, в которую вы сможете инсталлировать требуемое вам приложение и осуществить его запуск. При этом, если устанавливаемая ОС платная, то вы вынуждены будете ее купить.
Виртуализация
Вот некоторые популярные решения:
QEMU — свободная программа с открытым исходным кодом для эмуляции аппаратного обеспечения различных платформ.
Аппаратная виртуализация
Для запуска гостевой 64-битной виртуальной машины в 32-битном окружении необходимо, чтобы процессор обладал 64-битной архитектурой и поддерживал технологии аппаратной виртуализации, такие как Intel VT-x и AMD-V. Иногда их необходимо вручную включить в BIOS вашей системы.
Облачные вычисления
Все эти решения требует определенной производительности от системы, и не всегда есть возможность добиться оптимальной работы требуемого вам приложения.
В настоящее время широко развиваются технологии облачных вычислений [3]. Они позволяют развернуть любые ОС на удаленных серверах и запускать на них ваши приложения. При этом никаких ограничений на вашу 32-битную систему не накладывается, все расчеты производятся на удаленных машинах. Например, это Microsoft Azure, с помощью которой можно развернуть множество ОС и исполнять различные, в том числе и высокопроизводительные, приложения.
Часто вопрос о запуске 64-битных приложений на устаревающих 32-битных машинах стоит перед геймерами. Существуют специализированные облачные решения и для таких задач. Например, NVIDIA GRID. GRID воспроизводит 3D игры на облачных серверах, мгновенно кодирует каждый кадр и передает результаты на любое устройство с проводным или беспроводным высокоскоростным подключением к сети Интернет.
Заключение
Мы видим, что запуск 64-битных приложений в 32-битной ОС возможен, но связан с определенными трудностями. Так как некоторые решения являются платными, необходимо оценить, какая технология подходит вам больше.
Принудительный перевод Android приложений на 64-бита как правильное решение
Google начала постепенно отказываться от прошлого. Одним из больших шагов станет отказ от 64-битных приложений. Этот шаг поможет Android избавиться от лишних проблем с софтом.
Google Play ждут перемены. Первым изменением, которое вступит в силу в начале 2018 года станет принудительное добавление цифровой подписи приложениям. Своеобразный знак качества. В теории это поможет избавиться от некачественных и зараженных приложений и игр. По факту, с большой вероятностью, и первые и вторые останутся, лишь уменьшиться количество такого «шлака».
Вторым пунктом станет принудительный перевод всех приложений на 64-битную архитектуру. В 2018 году выйдет Android P который может стать чуть ли не последней версией перед полным отказом. Android R, для корпоративного рынка, уже не сможет запускать 32-битные приложения. Кроме этого, 32-битные приложения не будут пускать в Google Play, А отказ от них на уровне системы, скажется на том, что разработчикам не нужно будет создавать приложение под данную битность.
Но не только разработчикам нужно будет меньше копий создавать. Все старые и необновлеямые приложения, о которых забыли их авторы, также перестанут работать. Мы откажемся от устаревших приложений в пользу более современных и лучше работающих с новыми версиями операционной системы. Что же касается самого железа, уже несколько лет, все устройства выходят на чипах, созданных на 64-битной архитектуре. В продаже не встретить устройств на 32-битной архитектуре (если только сознательно искать раритет).
Как работают Android-приложения в Windows 11? Разбор
Мы все очень ждали презентации Windows 11, но как-то нам ее подпортили. Незадолго до презентации слили рабочий билд и поэтому во время ивента ничего по-настоящему нового мы не увидели. Кроме одной вещи: Android-приложения на винде!
Вот это было действительно неожиданно. И мы даже успели немного порадоваться, но потом сразу возникли вопросы. А зачем это нужно и как это вообще будет работать?
Ведь не так давно Microsoft сильно облажались со своей Windows на архитектуре ARM, в которой очень плохо работали x86-приложения. А если у них ничего не получилось тогда, то по какой причине получится сделать фактически тоже самое сейчас, но только наоборот?
Разбираясь в этих вопросах мы буквально прозрели. И поняли, что на самом деле у Microsoft очень далеко идущие планы.
Поэтому сегодня мы узнаем как работает Rosetta от Microsoft, а заодно разберемся, чем эмулятор отличается от транслятора? Узнаем, как Windows стал на Линуксом? И поразмышляем о том, как Microsoft планируют завоевать мир?
Эмуляторы
Начнем с небольшой теоретической части. Программы общаются с процессором при помощи определенного набора инструкций. И для каждой архитектуры этот набор инструкций разный. Поэтому для того, чтобы запустить приложение, написанное под архитектуру ARM на процессоре Intel с архитектурой x86 надо как-то пояснить процессору, что от него хочет чужеродная программа.
Сделать это можно разными способами. И один из самых распространённых — эмуляция.
Например, эмуляторов Android под Windows есть огромное множество. Но в чём же тогда проблема и зачем придумывать что-то еще?
Дело в том, что эмуляторы — неэффективны. По большому счету, эмулятор — это программа, которая прикидывается железом. То есть эмулятор — это софт, который пытается имитировать аппаратную часть платформы.
Программа, засунутая в эмулятор, даже «не понимает», что сейчас она находится в чужеродной среде. Она как Нео внутри «Матрицы». Вроде вокруг реальный мир, но иногда закрадываются сомнения. Потому что-то там подлагивает, подглючивает, ложки гнутся. Ну вы понимаете. А происходит это потому, что эмуляция несёт огромные накладные расходы.
Представьте, чтобы софт 100% правильно работал вам нужно эмулировать целый процессор и поэтому эмуляторы работают медленно.
И ладно, если речь идет про какую-нибудь простенькую восьмибитную консоль типа Dendy. Такие эмуляторы не смотря на тотальную неэффективность, будут работать быстро даже на смартфоне времен Windows Mobile. Но вот эмулировать какой-нибудь процессор Intel куда сложнее.
Отсюда и тормоза в Windows на ARM. Ведь Microsoft использовал именно эмулятор для запуска x86-приложений. Кстати, эмулятор назывался WOW64, но получилось совсем не WOW, как вы знаете.
Более того, до сих пор в Windows на ARM не поддерживается эмуляция 64-битных приложений, только 32-битных, то есть именно x86, а не x64, что еще сильнее усугубляет ситуацию. Но этому есть объяснение.
Эмулятор WOW64 изначально был придуман для запуска 32-битных приложений на 64-битной Windows, то есть под важную задачу Microsoft даже эмулятор новый не сделали, а скорее всего просто модифицировали старый.
Но в прошлом году Microsoft обещали, что поддержка 64-битных приложений появится, и очень скоро. И возможно она будет реализована совсем по-другому.
Как, спросите вы? Давайте для примера вспомним как это сделал Apple при переходе с процессоров Intel на свои собственные чипы на архитектуре ARM. При помощи невероятной штуки под названием Rosetta 2.
Ведь там на ARM’е каким-то чудесным образом запускаются x86-приложения практически без потери производительности.
Транслятор
Что такое Rosetta 2? По научному, — это двоичный транслятор, то есть переводчик. Rosetta просто переводит набор инструкций одной архитектуры в другую и всё.
Но чем же это лучше эмуляции? Дело в том, что эмуляция всегда происходит в реальном времени. А Rosetta переводит приложение заранее во время его установки или при первом запуске.
Поэтому когда пользователь открывает приложения он уже работает с нативным кодом, который исполняется без каких-либо дополнительных издержек. И в итоге все работает почти также быстро, как на родном железе!
Но, естественно, всё не так радужно! Иначе никто бы не собирал разные версии приложений под разные архитектуры. У трансляторов есть серьёзные недостатки.
Во-первых, перевести весь исходный код, исполняемый для целевой архитектуры — это весьма непростая задача, а в большинстве случаев просто невозможная. Некоторые части исполняемого кода доступны лишь во время использования приложения. Поэтому такие части транслируются динамически, «прямо на лету».
И этот процесс называется Just In Time компиляцией. Или JIT-компиляцией.
Естественно, это накладный процесс, но даже его можно оптимизировать. Результирующую последовательность динамического кода можно кешировать. А к фрагментам кода можно применить агрессивную оптимизацию. Поэтому в некоторых случаях, переведенный под другую архитектуру, но при этом оптимизированный код может выполняться даже быстрее оригинального.
И этот эффект я сам постоянно наблюдаю на новых Mac. Например, неадаптированный Блендер, через Rosetta работал быстрее, чем нативно на моем MacBook Pro 16. Но и за это приходится платить. Как думаете чем? Вашим SSD-диском. Переведенный код занимает много места, а динамическое кэширование изнашивает ресурс SSD. В особенности, такой эффект наблюдается на тяжеловесных программах, которые еще не пересобрали под ARM. Поэтому, приходится выбирать либо быстрая работа, либо долгоживущий SSD.
Intel Bridge
Но почему мы так долго говорим про Apple, если мы тут Windows 11 обсуждаем?
Дело в том, что для запуска Android-приложений в новой Windows, Microsoft решили сделать, примерно тоже самое, что сделали купертиновцы.
Вместе с Intel они разработали технологию Intel Bridge, которую они сами называют пост-компилятор. Но, по сути, это такой же двоичный транслятор.
Microsoft описывает эту технологию так:
«Создается нативное прокси-приложение которое, выступает мостиком между моделью приложения Android и моделью Windows приложения».
Иными словами, как и с Rosetta. Приложение будет переведено в нативный код еще на этапе установки. А недоступные фрагменты будут транслироваться на лету.
А с учетом того, что Android-приложения в своей массе достаточно простые почти не возникает сомнений, что с переводом будет всё в порядке.
В случае Windows, трансляция кода с x86 на ARM — это не основная сложность. Ведь тут еще и несовместимость на уровне ОС.
Android и Windows — это совершенно разные системы. Android основан на модифицированном ядре Linux, а в будущем планирует перейти на чистое ядро Linux. А Windows — это просто Windows. С Linux у Windows нет ничего общего. Так каким же образом тогда будут запускаться Android-приложения?
Это была специальная подсистема которая позволяла запускать Linux приложения в среде Windows. Система работала хорошо, но медленно, так как она работала поверх ядра Windows NT.
Запросы системы Linux переводились в запросы, понятные ядру Windows, и только потом отправлялись дальше. Это было долго.
Но в 2019 году анонсировали вторую версию подсистемы WSL 2, в которой ядро Linux работает параллельно ядру Windows, что ускорило работу системы в двадцать раз и фактически сделало Windows наполовину Linux.
g
То есть вы правильно поняли, WSL работает и на Windows 10, просто её нужно ставить отдельно. А вот в Windows 11 подсистема Linux будут встроена из коробки.
Как понимаете, наличие полноценного рабочего ядра Linux позволило Microsoft добиться максимальной совместимости с Android-приложениями.
По описанию Microsoft Android-приложения будут вести себя также как и обычные приложения Windows и этому можно верить:
Тем не менее, к реализации Android-приложений на Windows остаются вопросы.
Во-первых, что будет с поддержкой Google Play Сервисов? Скорее всего её не будет. Поэтому многие приложения, будут работать неполноценно, либо не будут работать вовсе.
И второй вопрос. А зачем это вообще всё надо? Ведь мобильными приложением на компе пользоваться просто не удобно.
Допустим, на MacBook я могу поставить массу приложений с iOS, но делать этого не хочется. Да на многих Windows-ноутбуках сенсорные экраны, но все равно.
Тогда зачем была проделана вся эта огромная работа по интеграции Linux в Windows, созданию транслятора Intel Bridge, доработки всей этой штуки под Android-приложения?
Будущее Windows
И тут мы готовы высказать смелое предположение. Нам кажется, что поддержка Android приложений это один из этапов полного отказа от ядра Windows NT и перехода на ядро Linux.
Да, это звучит дико. Но во-первых, не мы одни так думаем. Раньше такую же мысль высказал уважаемый человек, евангелист Open Source Эрик Реймонд.
Смотри сами как всё логично:
В мире почти все ОС основаны либо на Unix (как Mac OS) или Linux (Ubuntu, Android и прочее) и только Windows одна такая особенная сидит на своём ядре Windows NT, с которым куча проблем.
Во-первых, его нужно развивать на, что уходит много денег. А Linux-ядро бесплатное.
Во-вторых, в самом ядре куча уязвимостей, которые постоянно нужно прикрывать заплатками.
В-третьих, у Windows ничего не получилось в мобильном сегменте.
В-четвертых, Microsoft уже потратили много лет и ресурсов на создание подсистемы Linux под Windows.
Поэтому переход на ядро Linux вполне логичный шаг. Смотрите, как это может выглядеть:
Сначала мы все переходим на Windows 11 на архитектуре x86. И потихоньку привыкаем, что на Windows нормально работают Android-приложения.
Параллельно, благодаря стараниям Apple, все пилят софт под ARM архитектуру, отчего выигрывает и Microsoft. Поэтому мы потихоньку начинаем переходить на ARM Windows. На которой Android-приложения чувствует себя вообще как родные.
Постепенно Linux ядро становится основной средой, а Windows второстепенной.
А потом ядро Windows NT выпиливается, и Windows становится графической оболочкой для Linux. Ну а на ядре Windows NT остаются работать только серверы и различное оборудование, где наследие старой Windows никак не искоренить.
Это, конечно самый смелый сценарий. Тем не менее, он вполне возможен.
Но даже если этого не произойдёт. В любом случае поддержка Android-приложений — это очень интересный ход. И для Windows на ARM он точно будет полезен, вспоминая планшеты например!
Выводы
Ну и напоследок про сам Windows 11. Мы немного поигрались с новой Windows и у нас сложилось двоякое отношение.
С одной стороны, Windows 11 — это просто «десятка» с новой графической оболочкой. И это немного разочаровывает. Ведь если откинуть ядро Linux, которое теперь будет идти из коробки. Кроме дизайна под капотом не так многое поменялось, зато с совместимостью драйверов вроде проблем нет. Более того, до старого интерфейса, по-прежнему, очень легко добраться.
Тем не менее новый интерфейс действительно симпатичный и понятный.
В нем множество крутых фич как с меню «Пуск», так и с окнами. Привыкаешь к нему буквально за 10 минут. После чего возвращаться к старому скину совершенно не хочется. Еще раз — получилось красиво и удобно! А значит переход на новую Windows пройдет безболезненно и пользователи в целом останутся довольны. А это уже победа…
А там еще можно вспомнить про новый магазин без комиссии для разработчиков с блэкджеком. Но это уже совсем другая история и другие планы Microsoft по завоеванию мира магазинов приложений и ответ лаунчерам.