Godot: О будущем экспорта Android

Голосую за предложение 2.

Если мы говорим о рефакторинге механизма экспорта apk, думаю, важно знать, какая функция Godot Engine отсутствует:

1. APK Динамический контент : позволяет создавать более легкий apk
2. Приложение Google Instant : пользователь может играть в вашу игру / приложение, не устанавливая его.
3. Адаптивные значки : новейшие версии Android (Android P и некоторые версии Android 7.1+) требуют адаптивных значков.
4. Обработчик сбоев: в Godot Engine отсутствует API, вызывающий сбой. Это означает, что когда Godot Engine выходит из строя, мы должны предоставить функцию, позволяющую пользователям отправлять его в свое любимое приложение для анализа сбоев.
5. ANR теперь дает сбой , поэтому при запуске игры мы должны использовать AsyncTask вместо UIThread.

Пока мы реорганизуем механизм экспорта, мы также должны добавить эти функции в Godot Engine.

Мой голос => 2

Может гибрид?
Используйте старый подход, если sdk не найден для тестирования в режиме отладки, но требует установки SDK для пакета выпуска. Если SDK найден, используйте его в режиме отладки и выпуска.
Я голосую за 2, потому что это всегда необходимо, если вы работаете с Android.

@xsellier Я был бы признателен, что смысл этого аргумента не выходит за рамки того, что было предложено в OP. Если кто-то хочет реализовать то, что вы упомянули, это нормально, но давайте, пожалуйста, не срывайтесь.

@HeartoLazor Меньше кода для поддержки лучше imo, поэтому, если вы идете на № 2, гибрид - плохая идея.

Я тоже голосую за предложение 2.

После настройки Android-инструментов большая часть работы становится безболезненной, например, загрузка новых SDK и создание внешних библиотек.

Также было бы проще добавить сторонние библиотеки.

Я голосую за вариант 2

Вариант 2 звучит намного удобнее. Gradle - отличный инструмент, добавлять библиотеки и управлять процессом сборки намного проще, чем текущий поток.

Я голосую за предложение 2

Однажды я создал создателя шаблонов для Android в качестве дополнения к 2.x
https://github.com/vinod8990/godot-addon-aetc

Однако я голосую за предложение 2.
Если мы делаем стандарт, то нужно убедиться, что модуль тоже удаляет api. Когда нам нужно удалить собственный плагин (как в случае с Unity), это огромная PIA.

Голосование -> Предложение 2: Кажется, наиболее логичный выбор, Godot в настоящее время и в ближайшем будущем является лучшим игровым движком для мобильной разработки, и лучшая интеграция admob / инструментов является обязательной при экспорте на Android и мобильные платформы.

Означает ли это, что экспорт в iOS также будет улучшен? По крайней мере, в ближайшем будущем.

Проголосуйте за propsal 2: требуется некоторая интеграция библиотеки, чтобы перестроить apk с файлами, специфичными для приложения, такими как google-services.json для firebase или strings.xml для настройки facebook api. На Godot 2 у меня был патч SConstruct / SCsub / methods.py и несколько файлов шаблонов для правильной интеграции некоторых библиотек.

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

Кто-нибудь готов сделать предложение или PR по варианту №2? :)

Что ж, на данный момент у меня было много боли при добавлении модулей share и Admob, потому что на данный момент есть ошибка в методе get_data из текстуры, поэтому после компиляции вы проиграете.

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

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

Так что №2 с некоторыми флажками для оптимизации под Android было бы здорово.

Конечно, я ценю усилия по созданию всей этой экспортной среды.

Номер 2 кажется чище, поэтому я думаю, что это лучше, чем продолжать работу над хаком, который может принести проблемы в будущем.
Меня беспокоит только время развертывания. В настоящее время тестирование на Android выполняется очень быстро, в основном это зависит от размера ваших активов. Сильно ли повлияет вариант 2 на время сборки?
В любом случае я все еще думаю, что это правильный путь. При тестировании нужно больше полагаться на синхронизацию сцены / сценария.

Предложение 2 намного лучше, потому что Google Play всегда требует, чтобы apk был собран с их последней версией Android SDK.

Кроме того, GDnative вызывает боль, когда я пытаюсь интегрироваться со сторонними IAP и рекламой Amazon, Leadbolt и т. Д.

Предложение 2 точно.

Подобные подходы уже используются в некоторых крупных проектах, таких как Cordova и Flutter . Отличным вариантом будет возможность открыть проект в Android Studio, если пользователь хочет иметь больший контроль над созданием APK.

Вариант 2 кажется чище и больше похож на остальную часть Годо ... т.е. сделанный правильно.

Я только что прошел через боль, чтобы заставить работать экспорт Android. Больше всего проблем было с установкой нужных (версий) инструментов; настройка в Godot была простой.
В моей книге, если сделать это правильно, придется приложить столько же усилий, чтобы установить нужные инструменты, это все равно шаг в правильном направлении, поэтому я тоже голосую за №2.
Я разделяю опасения по поводу скорости запуска на Android для отладки, но если я не могу выпустить в магазин в конце, то это огромная проблема, которую необходимо решить; Мне нужно знать, что магазин будет доступен, когда я буду готов к выпуску.

Однозначно # 2 :)

Я за вариант 2 - установка Android sdk не проблема и открывает множество других возможностей.

На высоком уровне это похоже на то, как работает Flutter, https://github.com/flutter/buildroot

Означает ли вариант №2, что мы должны скомпилировать весь движок, включая код C ++ и Java, чтобы каждый раз экспортировать apk-файл Android для каждого проекта?

Это было бы катастрофой! Cocos Creator использует такой ужасный рабочий процесс.

@Geequlim Если я правильно понимаю, не c ++, а java.

Я за вариант №1. Когда я провожу какие-то эксперименты или отлаживаю рабочий процесс. Мне не нужен такой Android Bundle для отладки небольшого проекта. Сохраняйте хакерский путь. Позвольте программисту выполнять рабочий процесс SDK.

@Geequlim Да, это меня тоже беспокоит. Если проект нужно перекомпилировать и упаковывать в apk каждый раз, как мне кажется, это займет довольно много времени.

@Geequlim @JFonS Полная перекомпиляция не требуется. Gradle имеет большую оптимизацию времени сборки, поэтому полная компиляция (c ++ и Java) потребуется только в первый раз. Кроме того, когда вы применяете сторонний плагин, он изменяет код Java, Gradle увидит, что несколько файлов изменились и добавлена ​​одна зависимость, и перекомпилирует только измененные части. В большинстве случаев экспортер копирует ресурсы проекта (сцены, скрипты и активы) в папку Android, Gradle упаковывает apk из кэшированных исходных файлов и этих ресурсов и запускает его на устройстве Android, это не займет много времени.

@ veloc1 Нам все еще нужно скомпилировать движок дыры для каждого события проекта для тестовых демонстраций из

Рабочий процесс сборки Gradle может быть нарушен по многим причинам ：

• Установлена ​​неправильная версия SDK.
• Зависимости не могут быть загружены при плохом сетевом подключении (что действительно часто в Китае без прокси).
• Доступная память машины составляет менее 4 ГБ, но некоторые сторонние SDK должны включать multiDexEnabled true для компиляции.
• ...

И градиент не всегда перекомпилируется, как ожидалось.

Может быть, я ошибаюсь, но я думаю, что №1 - это стакан молока, а №2 - дойная корова. Я прав?

@Geequlim Насколько я понимаю, нам действительно не нужно перекомпилировать весь движок. Весь код можно упаковать в библиотеку (так что каждый выпуск Godot должен перестраивать библиотеку Android с движком Godot). При создании проекта редактор Godot может распаковать шаблон android в папку «android» с одним классом java, а файл Gradle с включенным движком Godot android-зависимостью от maven (React Native работает точно так же, как я помнил).
Таким образом мы можем минимизировать время сборки, использование памяти и упростить проект Android.

Но вы правы, здесь тоже много ограничений.

И несколько комментариев к вашему списку возможных поломок:

• SDK не играет большой роли, потому что движок Godot не использует многие функции из нового sdk. Для простых проектов подойдет практически любой SDK. Кроме того, загрузку соответствующего SDK можно автоматизировать.
• Проблема зависимости, которую вы описали, может быть болезненной. Мы можем включать зависимости со ссылками из maven, но также мы можем помещать файлы библиотек (jar или aar) в папку проекта и использовать зависимости, поэтому при плохом сетевом подключении вы можете загружать все зависимости в других местах, помещать их на USB-накопитель и перемещать проэктировать. Но это должно быть подробно описано в экспортной документации.
• Мультидекс и память не влияют друг на друга. Мультидекс всегда можно включить в шаблоне проекта. Память будет более сильным ограничением. Я не могу точно сказать, какой объем доступной памяти потребуется для этого, но он должен быть больше 2 ГБ.

И есть свод изменений, которые следует реализовать в Godot (в соответствии с тем, что я описал выше):

• Создайте библиотеку Android, содержащую движок и систему плагинов. (это трудно)
• Автоматизируйте сборку библиотеки Android при выпуске и поместите ее в maven.
• Сделайте шаблон проекта Android.
• Собираем набор скриптов для проверки среды, скачиваем Gradle, Java, Android Sdk
• Внесите изменения в движок Godot, поэтому, когда пользователь запускает проект на устройстве Android, движок должен копировать все ресурсы и вызывать задачу Gradle для создания и запуска проекта.
• Документация на все.

@Geequlim

Означает ли вариант №2, что мы должны скомпилировать весь движок, включая код C ++ и Java, чтобы каждый раз экспортировать apk-файл Android для каждого проекта?

Нет .. Я не вижу для этого никаких причин. Так обстоит дело сейчас, но новый рабочий процесс просто переведет проект Android в предварительно созданное состояние (с файлами Godot .so). Добавление внешних модулей, которые вы загрузили в другие каталоги (например, Admob), очень просто с Gradle, поэтому теоретически вы можете просто загрузить эту поддержку из библиотеки ресурсов, и она будет волшебным образом работать.

@ veloc1

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

Новый рабочий процесс «запуск / экспорт» будет состоять из:
1) Сборка Gradle (если изменений не произошло, ничего не будет сделано, это должно быть довольно быстро
2) Скорее всего, запустите текущую логику экспорта, чтобы разархивировать APK и добавить файлы, плагины gdnative и т. Д. И снова заархивировать его ... так что подпись все равно будет выполняться Годо, а не Gradle, я думаю.

Точно так же, я думаю, Godot мог бы внести необходимое редактирование в AndroidManifest.xml перед сборкой (изменить имя, добавить разрешения и другие вещи), добавить значки и т. Д., Чтобы упростить пользователям, которые все еще могут быть недружелюбны к тому, как работает манифест. Хорошо то, что это делается неразрушающим образом, поэтому вы все равно можете добавлять свои собственные данные в Manifest.

@reduz

Не был уверен, что подписание должно быть на стороне Годо. Плагин Android для Gradle имеет отличную функцию для этого https://developer.android.com/studio/build/build-variants#signing , поэтому при экспорте мы просто проверяем хранилище ключей и пароли, а Gradle выполняет всю работу.

А для Manifest. Когда я говорю о системе плагинов, я имею в виду именно это: каждый плагин объявляет разрешения, а при экспорте мы собираем все включенные плагины и генерируем AndroidManifest.xml. Также таким образом мы можем включить библиотечные сервисы и BraodcastReceivers.

Для ресурсов, таких как имя и значок - как насчет ресурсов-заполнителей, и если они настроены в настройках проекта, просто замените заполнители значениями из настроек проекта? Таким образом, конечные пользователи вообще не увидят всех этих ужасных вещей для Android.

Будет ли возможно с новым рабочим процессом экспорта иметь игровой пакет вне APK, а не заархивировать его снова (папка или .pck)?

@LinuxUserGD - это не для этого Apk Expansion (.obb)?
это уже есть.

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

Что касается манифеста, я бы тоже хотел оставить его редактируемым вручную.

Текущая сборка очень гибкая, я могу редактировать шаблон и добавлять / удалять все, что захочу, и ничто не будет мешать при создании шаблонов.

Думаю, что-то вроде гибридной системы подойдет?

Несомненно, предложение 2 звучит лучше, чище и «правильнее».
@reduz Минусы предложения 2? Думаю, хлопоты возникают только тогда, когда нет быстрого интернета.
Godot, как Android Studio, вероятно, очень легко (в виде текстового файла?) Передать sdkmanager список необходимых пакетов для загрузки https://developer.android.com/studio/command-line/sdkmanager

Предложение 2, точно.

Предложение №2. В настоящее время установка Android SDK довольно проста!

@reduz , я

предложение 2. Gradle также задокументирован, поэтому у нас будет больше ресурсов. У большинства мобильных разработчиков в любом случае будет установлен android sdk где-нибудь в своей системе.

Предложение 2

Когда это будет реализовано, какая-либо информация или что-нибудь
@ akien-mga Это все еще веха для 3.1?

Согласно этому сообщению в блоге godotengine.org/news от 23 ноября 2018 г .:

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

Что ж, особенность текущего выпуска, похоже, привлекла достаточно внимания, чтобы ее можно было рассмотреть в версии 3.2. Есть ли причина, по которой он не был добавлен в блог?

У нас не хватило времени на большой рефакторинг экспорта Android, так что это будет для версии 3.2.

Поскольку android предлагает множество сторонних плагинов и баз данных (Firebase, Cloud, ML), кажется хорошей идеей установить android sdk / jdk / ndk для устойчивого развития. Причина в том, что библиотеки Android меняются с версиями там, возможно некоторые библиотеки зависимостей, отсутствующие при экспорте, выполняются без установленной надлежащей версии SDK, но этот подход, напротив, требует, чтобы пользователь или конечный разработчик отправили весь продукт на платформу Android только для тестирования, что создает накладные расходы времени Альтернативный подход может быть реализован, например, как создание приложения для Android, которое использует SDK студии Android и jdk на устройстве для тестирования. Пользователь может просто запустить приложение, подключившись к компьютеру с помощью кабельного порта, а затем запустить игру в Godot Editor и просматривайте изменения на телефоне или мобильном телефоне. Мобильный телефон использует SDK для Android компьютера через свой порт, и что касается Proposal1, то накладные расходы времени незначительны. а также практически прозрачен, взлома не требуется.
Поскольку в коде ядра Android есть определенные библиотеки, которые, если они не установлены, приведут к сбоям во время выполнения в основном с java.lang.io.exceptions. Также необходимо решить проблему, заключающуюся в том, что если Предложению 1 предоставляется приоритет, это подразумевает взлом на отдельные версии Android, каждая из которых имеет больше зависимостей, чем предыдущие. Предложение 2 можно сделать, просто установив android sdk на компьютер и используя приложение Android (которое будет создано) разработчиками, чтобы мгновенно проверить свои игры на мобильном телефоне; больше похоже на пульт. Для полной сборки приложения или экспорта можно использовать обобщенный подход 2.
Что касается шаблонов, можно использовать адаптивные шаблоны android8 +. Кроме того, чтобы сократить время создания приложения (с использованием sdk), оптимизация движка для улучшения сборщиков мусора, а также оптимизации, такие как подход на основе структур, могут быть использовал.
Это полностью моя точка зрения, если все в порядке, у меня есть некоторые планы относительно приложения (Android), которое использует SDK устройства для мгновенного создания игры-приложения.

Google Play теперь принимает приложения, загруженные в их новом формате Android App Bundle (AAB) .

Этот формат позволяет Google Play динамически генерировать APK-файлы для многих типов устройств, и одна из функций, которая напрямую влияет на игры, созданные в Godot, - это упаковка APK-файлов, содержащих только собственную библиотеку, созданную для этой конкретной архитектуры ЦП.

Это означает, что размер загрузки можно значительно улучшить, если APK, загружаемый устройством x86, будет содержать только библиотеку x86, а загруженный arm64 будет содержать только библиотеку arm64 и т. Д. И т. Д.

Я считаю, что любой подход, который использует Godot, должен поддерживать этот новый формат упаковки, но я не знаю, насколько легко «взломать» пакет AAB по сравнению с пакетом APK, который в основном представляет собой ZIP-файл.

Это означает, что размер загрузки можно значительно улучшить, если APK, загружаемый устройством x86, будет содержать только библиотеку x86, а загруженный arm64 будет содержать только библиотеку arm64 и т. Д. И т. Д.

Обратите внимание, что это уже возможно, но требует ручной работы, создавая один APK для каждой архитектуры, а затем загружая его в Google Play, используя поддержку нескольких APK .

Это было исправлено с помощью # 27781, который в основном реализует сочетание 1 и 2. Старая система сохраняется для развертывания в один клик, но выпуски теперь будут поставляться с предварительно скомпилированным источником шаблона, который можно перекомпилировать в новый APK с пользовательскими модулями. / манифестировать изменения / и т. д. используя gradle.