Godot android app bundle

Вышла новая версия открытого движка Godot с упором на оптимизацию

Разработчики движка с открытым исходным кодом Godot представили версию 3.3. Работа над ней велась в течение семи месяцев. Среди основных нововведений — веб-версия редактора, новый API для iOS -плагинов, поддержка чипов M1 , а также улучшенные инструменты рендеринга, организации многопоточности и работы с HTML5 .

Веб-редактор в Godot 3.3

Разработчики отметили, что сейчас большинство команды сосредоточено на работе над четвертой версией Godot. Однако они решили не бросать поддержку Godot 3.x, поскольку сейчас многие используют ее для разработки и выпуска своих игр.

Изначально предполагалось выпустить это обновление как Godot 3.2.4, однако из-за большого числа изменений команда решила представить новую ветку 3.3. Ее поддержка будет вестись параллельно с созданием Godot 4.0, пока разработчики не будут готовы выпустить новую, полностью рабочую и оптимизированную, версию движка.

Основные нововведения Godot 3.3

• Веб-версия редактора, работающая в браузерах и синхронизированная с настольной версией;
• экспорт игр для Android в формате Android App Bundle (AAB) для загрузки нативных библиотек, которые нужна для работы на текущем устройстве;
• встраивание в Android-приложения элементов на движке Godot в формате субкомпонентов, поддержка слепых зон экрана и ввода с внешней клавиатуры;
• новый API для сборки и дистрибуции iOS-плагинов, включая ARKit , GameCenter , InAppStore ;
• улучшенные инструменты для портирования веб-приложений на базе HTML5 — поддерживаются не все браузеры, поскольку инструмент работает на базе SharedArrayBuffer ;
• сборка приложений и игр для устройств Apple на базе процессора M1, поддержка архитектуры ARM64;
• новый API для организации многопоточности, который изначально разрабатывался только для версии 4.0: оптимизация производительности, поддержка стандарта C++14 и повышенная надежность кроссплатформенной работы;
• улучшенные возможности рендеринга: настраиваемое число источников света, трансформация скрытых 3D-объектов, улучшенная отрисовка теней и т.д.;
• новый инструмент создания карт освещения, улучшенная симуляция столкновений, поддержка бесконечной динамической 3D-сетки в редакторе, плагин OpenXR для создания XR-приложений и т.д.

С полным списком изменений и новых функций можно ознакомиться здесь .

Источник

Add Android Application Bundle option in the Android export template options #342

Comments

mickael-h commented Dec 29, 2019

Describe the project you are working on:
Mobile game
Describe the problem or limitation you are having in your project:
I want to export an AAB bundle for the play store, but the export template only allows to export an APK file
Describe how this feature / enhancement will help you overcome this problem or limitation:
I would be able to use the AAB format to send to the Google play store, which would allow me to get more lightweight applications.
Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:
https://i.imgur.com/AIRZdLO.png
Describe implementation detail for your proposal (in code), if possible:
No idea, to be honest
If this enhancement will not be used often, can it be worked around with a few lines of script?:
I wish
Is there a reason why this should be core and not an add-on in the asset library?:
It’s not an asset

The text was updated successfully, but these errors were encountered:

Calinou commented Dec 30, 2019 •

See also godotengine/godot#30711. Note that you can already perform the splitting manually using Google Play’s multiple APK support.

mickael-h commented Dec 30, 2019

Yeah I know. It’s just that AAB files are very lightweight in comparison and I also fear Google might make it mandatory in the near future, considering the big warning sign they show you when you upload an APK file to the Play Store. When I think about it, it mustn’t be very hard to implement. All you really need to do is to replace the gradlew assembleRelease command with gradlew bundleRelease.

Calinou commented Dec 30, 2019 •

@mickael-h As of 3.2, we now have two ways to export projects for Android: the old way, where you download an APK export template and use it to export a project, and the new way, where you download a Gradle project bundle that contains just the native library ( .so ) and build the Java part before exporting.

I don’t know whether we intend to support AAB when exporting using «the old way», but if we do, that means it’ll be more work to support it. Also, this stuff needs to be tested to make sure it works with third-party modules.

@m4gr3d Do you know what it’d take to support exporting a project into an AAB using «the new way»? Thanks in advance 🙂

alexzheng commented Jan 4, 2020

Supporting AAB using the new export way would be enough.
Hope it would be available soon.

neverdieboy commented Jan 5, 2020

Hi, recently tried to publish my app in Google Play, and appeared the same problem with Android App Bundle. So now I just can`t publish an app without it. Hope Godot 3.2 will support it, it will be really good

mickael-h commented Jan 5, 2020

@neverdieboy That’s weird. you should be able to publish an APK. For the moment, Google only recommends you to use an AAB, but it’s not mandatory.

neverdieboy commented Jan 6, 2020 •

@neverdieboy That’s weird. you should be able to publish an APK. For the moment, Google only recommends you to use an AAB, but it’s not mandatory.

Maybe I cant understand something. I attached screens, maybe you can help me, because I just can`t start rollout.

mickael-h commented Jan 6, 2020

@neverdieboy Yeah, that’s just a warning. The reason why you can’t deploy is because you have uncompleted sections in your app project. You need to make those green in order to deploy your app.

neverdieboy commented Jan 6, 2020

@mickael-h Oh, I just didn`t think about that, thanks a lot. First time publishing)

bobbles911 commented Apr 28, 2020

+1, this would be a nice feature to easily reduce app sizes. Multiple APKs is possible but more complex having to deal with version numbers

TheNeoGameFactory commented Jun 13, 2020

Godot need this Feature, now.

m4gr3d commented Jun 13, 2020

@TheNeoGameFactory we’ll be working on this feature for Godot 3.2.3.

amanj120 commented Jun 23, 2020 •

I opened a similar issue earlier today to go alongside an proof of concept PR (#39761) I made, and I was told to paste my proposal here.

Describe the project you are working on:

Android App Bundles (AABs) are Google’s preferred method of publishing Android apps to the Google Play Store. Starting sometime in 2021, they will be the only way to publish. The best way to build an AAB is to use the Android Gradle Plugin. This project aims to modify the existing “Use Custom Build” process in Godot to create self-contained Gradle projects.

Describe the problem or limitation you are having in your project:

Currently, there is no way for a Godot developer to build an AAB. The Gradle project created by the existing custom build is incomplete: it has no assets, an incomplete resource table, and an incomplete Android Manifest file. This means that a developer cannot use Gradle commands to build their game as an APK or an AAB; they must rely on the editor.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:

This proposal changes the Android “Use Custom Build” from building and then updating a template APK to performing the entire build using Gradle. With this change in place it’s possible to add an “Export AAB” checkbox to the UI that will result in Godot exporting an AAB. This change will also open the door to future enhancements, such as Play Asset Delivery support.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:

When a user checks “Use Custom Build” in their Android project and then clicks “Export Project”, the Godot engine will now use a different approach to generate a custom build:

The exporting script will first check that the following are true:
a. The res://android directory exists
b. There is a path to the Android SDK
c. The version of Godot matches the version of the custom build template

The exporting script will look for the specified icon files for the game, and then it will appropriately resize the icon(s), create res://android/build/res/mipmap folders, and copy the resized icons into those folders. This is what the _copy_icons_to_gradle_project and _resize_launcher_icon functions are for
a. The store_file_in_gradle_project method is used to store files inside the gradle project (in the res://android/build directory )

The exporting script will create a new Android Manifest file in a separate directory. This manifest file will be merged with the manifest file in the root directory during build time by passing in command line parameters to gradle.

The exporting script goes through all of the assets in the res:// directory that are necessary for the game, and it stores them inside the res://android/build/assets directory of the gradle project. This is done by the already existing export_project_files method, which takes in two function pointers as part of its argument
a. The first function pointer points to rename_and_store_file_in_gradle_project which renames a file and stores it in a gradle project
b. The second function pointer points to ignore_so_file . This is because all the .so files are copied from the AAR files already.

After these modifications to the res://android directory, the gradle commands to build the app remain unchanged.

The benefit to this method is that by using this new method, a fully fledged gradle project exists for the developer to use. This is different from the original “Use Custom Build” process because that process did not give the developer a useful gradle project to work with, instead it just provided a base gradle project, and the exporting script would still have to build that apk, unzip it, and insert assets and such to this unzipped apk to create the final game apk.

If this enhancement will not be used often, can it be worked around with a few lines of script?:
This enhancement will end up being used by everyone who publishes a Godot game to the Google Play Store. The Google Play store will stop accepting APKs and only accept Android App Bundles starting some time in 2021. The only way to build Android App Bundles is by modifying the exporting script inside the Godot engine. There are no simple lines of script that can solve this problem, because the current build system does not use Gradle as the primary build tool.

Is there a reason why this should be core and not an add-on in the asset library?:
Being able to export Godot games for Android is a core feature of the Godot editor/engine.

How will this PR be broken down into reasonable, smaller PR’s?

Adding store_file_in_gradle_project , store_so_file_in_gradle_project and rename_and_store_file_in_gradle_project methods. These are all methods related to storing files in the gradle project.

Refactoring of permissions into the _get_permissions method. This refactoring is only related to handling permissions for Android Apps.

Creating the _resize_launcher_icon and _copy_icons_to_gradle_project methods, which are used to copy launcher icons to the gradle project

Adding the _copy_value_xml_files method, which is used to copy the values.xml files into the gradle project.

Adding the _fix_manifest_plaintext method, which is used to fix the Android Manifest file.

Refactoring the gradle_build method, which ties everything else together.

Источник

Android: Changes needed to support API 30 (Android 11) requirements from August 2021 #48636

Comments

akien-mga commented May 11, 2021 •

Godot version:
All Godot versions, but realistically only master , 3.x and 3.3 .
Older versions don’t support AABs which will become a requirement. (This might finally force EOL for 2.1 , unless someone is really motivated to backport all this work to the 2.1 branch.)

Issue description:

Like clockwork, Google Play has updated requirements for new apps and updates that will be enforced from August 2021 (new apps) and November 2021 (updates). These requirements are described in https://developer.android.com/distribute/best-practices/develop/target-sdk (archive.org link).

From the above documentation, we need to support:

• Publish with the Android App Bundle format. Supported in 3.3 and later.
  • AAB should likely be made the default option, and APK support deprecated? I’d keep it in 3.3 but we can possibly remove it in 3.4 (or deprecate and remove in 3.5 once Google Play no longer accepts APKs).
• Use Play Asset Delivery or Play Feature Delivery to deliver assets or features that exceed download size of 150MB. Expansion files (OBBs) will no longer be supported for new apps.
  • Where do we stand here for asset delivery features?
• Target API level 30 (Android 11) or above and adjust for behavioral changes. Behavioral changes are:
  • Scoped storage enforcement: Access into external storage directories is limited to an app-specific directory and specific types of media that the app has created. #38913
  • Permissions auto-reset: If users haven’t interacted with an app for a few months, the system auto-resets the app’s sensitive permissions.
  • Background location access: Users must be directed to system settings in order to grant the background location permission to apps.
  • Package visibility: When an app queries for the list of installed apps on the device, the returned list is filtered.

We need to assess all of the above, implement it ASAP for the 3.x and master branches, and cherry-pick to 3.3 . It would be great if we could have this in a 3.3 release at least by late June/July.

The text was updated successfully, but these errors were encountered:

Источник