Godot: Tentang masa depan ekspor Android

Saya memilih proposal 2.

Jika kita berbicara tentang refactoring mekanisme ekspor apk, saya pikir mungkin penting untuk mengetahui fitur mana yang hilang dari Godot Engine:

1. APK Konten dinamis : Memungkinkan untuk menghasilkan apk yang lebih ringan
2. Google Instant App : Pengguna dapat memainkan game/aplikasi Anda tanpa menginstalnya
3. Ikon adaptif : Android terbaru (Android P, dan beberapa Android 7.1+) memerlukan ikon adaptif.
4. Handler mogok: Godot Engine tidak memiliki API yang mogok. Artinya ketika Godot Engine mogok, kami harus mengekspos fungsi yang memungkinkan pengguna mengirimnya ke aplikasi analisis kerusakan favorit mereka
5. ANR sekarang macet , jadi saat game dimulai, kita harus menggunakan AsyncTask alih-alih UIThread.

Saat kami memfaktorkan ulang mekanisme ekspor, kami juga harus menambahkan fitur tersebut ke Godot Engine.

Suara saya => 2

Mungkin hibrida?
Gunakan pendekatan lama jika SDK tidak ditemukan untuk pengujian dalam mode debug, tetapi memerlukan pemasangan SDK untuk paket rilis. Jika sdk ditemukan, gunakan dalam mode debug dan rilis.
Saya memilih 2, karena selalu menjadi persyaratan jika Anda bekerja di Android.

@xsellier Saya akan menghargai titik argumen ini tidak melampaui apa yang diusulkan di OP, Jika seseorang ingin menerapkan apa yang Anda sebutkan baik-baik saja, tapi tolong jangan menggagalkan.

@HeartoLazor Lebih sedikit kode untuk dipelihara lebih baik, jadi jika memilih #2, Hybrid adalah ide yang buruk.

Saya juga memilih proposal 2.

Setelah menyiapkan alat Android membuat banyak pekerjaan menjadi sangat mudah, seperti mengunduh sdk baru dan membangun lib eksternal.

Juga menambahkan perpustakaan pihak ke-3 akan lebih mudah.

Saya memilih opsi 2

Opsi 2 terdengar jauh lebih nyaman. Gradle adalah alat yang hebat, menambahkan perpustakaan dan mengelola proses pembangunan jauh lebih mudah daripada aliran saat ini.

Suara saya untuk proposal 2

Saya pernah membuat pembuat template android sebagai addon untuk 2.x
https://github.com/vinod8990/godot-addon-aetc

Namun saya memilih proposal 2.
Jika kita membuat standar, maka perlu memastikan modul menghapus api juga. Ini adalah PIA besar ketika kita perlu menghapus plugin asli (seperti dalam kasus Unity).

Suara -> Proposal 2: Sepertinya pilihan yang paling logis, Godot saat ini dan dalam waktu dekat adalah mesin permainan terbaik untuk pengembangan seluler dan integrasi admob/alat yang lebih baik adalah suatu keharusan ketika harus mengekspor ke platform Android dan seluler.

Apakah ini juga berarti bahwa ekspor iOS juga akan ditingkatkan.? Setidaknya dalam waktu dekat.

Pilih propsal 2: Beberapa integrasi perpustakaan diperlukan untuk membangun kembali apk dengan file khusus aplikasi seperti google-services.json untuk kustomisasi firebase atau strings.xml untuk api facebook. Di Godot 2, saya memiliki patch SConstruct/SCsub/methods.py dan beberapa file template untuk mengintegrasikan beberapa lib dengan benar.

Tampaknya sebagian besar kesepakatan di sini.. Jadi saya kira peretasan APK harus dihilangkan, dan template ekspor harus cukup banyak di direktori Android sebelum Gradle dijalankan..

Adakah yang ingin membuat proposal atau PR untuk opsi # 2? :)

Nah saat ini saya mengalami banyak kesulitan menambahkan bagian dan modul Admob, karena saat ini ada bug dalam metode get_data dari tekstur jadi setelah dikompilasi dan Anda kalah.

Saya juga harus memiliki konfigurasi khusus untuk membuat semuanya bekerja bersama Java, gradle, dan lainnya yang baik-baik saja tetapi sulit.

Juga mengetahui metode shader apa yang tersedia dan memiliki fisika yang lebih cair akan sangat bagus karena saya harus menulis ulang banyak hal untuk mengubah posisi alih-alih menerapkan kecepatan sederhana karena beberapa masalah yang akan berubah di 3.1 sehingga memiliki halaman dengan tips di Android akan juga menjadi langkah besar.

Jadi # 2 dengan beberapa kotak centang untuk mengoptimalkan Android akan sangat bagus.

Tentu saja saya menghargai upaya yang menciptakan semua lingkungan ekspor ini.

Nomor 2 tampaknya lebih bersih, jadi saya pikir itu lebih baik daripada terus mengerjakan peretasan yang mungkin membawa masalah di masa depan.
Satu-satunya kekhawatiran saya adalah waktu penyebaran. Saat ini pengujian di android sangat cepat, pada dasarnya sebagian besar tergantung pada seberapa besar aset Anda. Apakah opsi 2 akan sangat memengaruhi waktu pembuatan?
Dalam hal apapun saya masih berpikir itu cara untuk pergi. Ini akan menjadi masalah lebih mengandalkan sinkronisasi adegan/skrip untuk pengujian.

Proposal 2 jauh lebih baik karena Google Play selalu membutuhkan apk untuk dibangun dengan SDK Android terbaru mereka.

Dan juga GDnative sakit ketika saya mencoba berintegrasi dengan IAP & iklan pihak ketiga dari Amazon, Leadbolt, dll.

Usulan 2 pasti.

Pendekatan serupa sudah digunakan di beberapa proyek besar seperti Cordova dan Flutter . Pilihan yang bagus adalah kemungkinan untuk membuka proyek di Android Studio jika pengguna ingin memiliki kontrol lebih besar atas pembuatan APK.

Opsi 2 tampaknya lebih bersih dan lebih seperti Godot lainnya... yaitu dilakukan dengan benar.

Saya baru saja mengalami kesulitan untuk membuat ekspor Android berfungsi. Yang paling menyakitkan adalah memasang (versi) alat yang tepat; mengkonfigurasi di Godot itu mudah.
Dalam buku saya, jika melakukannya dengan benar melibatkan rasa sakit yang sama dengan memasang alat yang tepat, itu masih merupakan langkah ke arah yang benar, jadi saya juga memilih #2.
Saya berbagi kekhawatiran tentang kecepatan peluncuran di Android untuk debugging, tetapi jika saya tidak dapat merilis ke toko di akhir maka itu adalah masalah besar yang perlu ditangani; Saya perlu tahu toko akan tersedia saat saya siap untuk rilis.

Pasti #2 :)

Saya untuk opsi 2 - menginstal SDK Android tidak menjadi masalah, dan itu membuka banyak kemungkinan lain.

Pada tingkat tinggi, tampaknya mirip dengan cara Flutter melakukan sesuatu, https://github.com/flutter/buildroot

Apakah opsi #2 berarti kita harus mengkompilasi seluruh mesin termasuk kode C++ dan Java untuk mengekspor file apk android untuk setiap proyek setiap saat?

Itu akan menjadi bencana! Cocos Creator menggunakan alur kerja yang mengerikan.

@Geequlim Jika saya mengerti benar, bukan c++ tapi Java.

Saya untuk opsi #1 .Ketika saya melakukan beberapa eksperimen atau alur kerja debug. Saya tidak ingin Bundel Android seperti itu untuk Debug Proyek Kecil. Pertahankan cara peretasan. Biarkan progammer melakukan alur kerja SDK.

@Geequlim Ya, itu juga menjadi perhatian saya. Jika proyek perlu dikompilasi ulang dan dikemas ke dalam apk setiap kali saya merasa itu akan memakan banyak waktu.

@Geequlim @JFonS Kompilasi ulang penuh tidak diperlukan. Gradle memiliki banyak optimasi waktu pembuatan, sehingga kompilasi lengkap (c++ dan Java) hanya diperlukan untuk pertama kali. Juga, ketika Anda menerapkan plugin pihak ketiga, itu akan memodifikasi kode Java, Gradle akan melihat bahwa beberapa file diubah dan satu ketergantungan ditambahkan, dan hanya akan mengkompilasi ulang bagian yang diubah. Sebagian besar waktu eksportir akan menyalin sumber daya proyek (adegan, skrip, dan aset) ke folder android, Gradle akan mengemas apk dari file sumber yang di-cache dan sumber daya ini dan menjalankannya di perangkat android, ini seharusnya tidak memakan banyak waktu.

@veloc1 Kami masih harus mengkompilasi mesin lubang untuk setiap acara proyek untuk demo uji dari aset lib kan?

Alur kerja build gradle mungkin rusak karena banyak alasan：

• SDK versi yang salah diinstal.
• Ketergantungan tidak dapat diunduh dengan koneksi jaringan yang buruk (yang sangat sering terjadi di China tanpa proxy).
• Memori mesin yang tersedia kurang dari 4 GB tetapi beberapa SDK pihak ketiga harus mengaktifkan multiDexEnabled true untuk dikompilasi.
• ...

Dan gradle tidak selalu dikompilasi ulang seperti yang diharapkan.

Mungkin saya salah, Tapi saya pikir #1 adalah segelas susu dan #2 adalah sapi perah. Apakah saya benar?

@Geequlim Seperti yang dapat saya bayangkan, kami tidak benar-benar perlu mengkompilasi ulang seluruh mesin. Semua kode dapat dikemas dalam perpustakaan (jadi, setiap rilis Godot harus membangun kembali perpustakaan Android dengan mesin Godot). Saat proyek dibuat, editor Godot dapat meng-unzip template Android di folder "android" dengan satu kelas java, dan file Gradle dengan dependensi Android engine Godot yang disertakan dari maven (React Native bekerja dengan cara yang sama, seperti yang saya ingat).
Dengan cara ini kita dapat meminimalkan waktu pembuatan, penggunaan memori, dan meningkatkan kesederhanaan proyek Android.

Tapi Anda benar, ini juga melibatkan banyak batasan.

Dan beberapa komentar untuk daftar hal-hal yang mungkin rusak:

• SDK tidak banyak berperan, karena mesin Godot tidak menggunakan banyak fitur dari SDK baru. Untuk proyek sederhana, hampir semua SDK akan baik-baik saja. Juga, mengunduh SDK yang sesuai dapat diotomatisasi.
• Masalah ketergantungan, yang Anda gambarkan bisa menyebalkan. Kami dapat menyertakan dependensi dengan tautan dari maven, tetapi kami juga dapat meletakkan file perpustakaan (jar atau aar) di folder proyek, dan menggunakan dependensi, jadi dengan koneksi jaringan yang buruk Anda dapat mengunduh semua dependensi di tempat lain, meletakkannya di stik USB dan memindahkan untuk memproyeksikan. Tapi ini harus sangat dijelaskan dalam dokumentasi ekspor.
• Multidex dan memori tidak saling mempengaruhi. Multidex dapat diaktifkan selalu dalam proyek template. Memori akan menjadi batasan yang lebih kuat. Saya tidak bisa mengatakan dengan tepat, berapa jumlah memori yang tersedia yang diperlukan untuk itu, tetapi ini harus lebih besar dari 2GB.

Dan ada rangkuman perubahan yang harus diterapkan di Godot (sesuai cara yang saya jelaskan di atas):

• Buat perpustakaan android, yang berisi mesin dan sistem plugin. (ini sulit)
• Otomatiskan pembuatan perpustakaan Android saat dirilis dan letakkan di maven.
• Membuat template proyek android.
• Kumpulkan satu set skrip untuk memvalidasi lingkungan, mengunduh Gradle, Java, Android Sdk
• Buat perubahan di mesin Godot, jadi ketika pengguna menjalankan proyek di perangkat Android, mesin harus menyalin semua sumber daya dan memanggil tugas Gradle untuk membangun dan menjalankan proyek.
• Dokumentasi untuk semua hal.

@Geequlim

Apakah opsi #2 berarti kita harus mengkompilasi seluruh mesin termasuk kode C++ dan Java untuk mengekspor file apk android untuk setiap proyek setiap saat?

Tidak .. Saya tidak benar-benar melihat alasan untuk itu. Inilah masalahnya sekarang, tetapi alur kerja baru hanya akan membuat proyek Android dalam keadaan siap pakai (dengan file Godot .so). Menambahkan modul eksternal yang Anda unduh di direktori lain (seperti, Admob) sangat mudah dengan Gradle, sehingga Anda secara teori dapat mengunduh dukungan itu dari pustaka aset dan itu akan bekerja secara ajaib.

@veloc1

Sudah ada _is_ sistem plugin yang memodifikasi Gradle build untuk menambahkan hal-hal, yang kemungkinan besar tidak memerlukan atau sedikit perubahan.

Alur kerja "jalankan/ekspor" baru akan terdiri dari:
1) Membangun Gradle (jika tidak ada perubahan yang terjadi, tidak ada yang akan dilakukan, itu seharusnya cukup cepat
2) Kemungkinan menjalankan logika ekspor saat ini untuk membuka zip APK dan menambahkan file, plugin gdnative, dll. dan zip lagi.. jadi penandatanganan masih akan dilakukan oleh Godot dan bukan Gradle, saya kira.

Demikian juga, saya kira Godot dapat melakukan pengeditan yang diperlukan ke AndroidManifest.xml sebelum membangun (mengubah nama, menambahkan izin, dan hal-hal lain), menambahkan ikon, dll. Untuk memudahkan pengguna yang mungkin masih tidak ramah dengan cara kerja manifes. Hal baiknya adalah ini dilakukan dengan cara yang tidak merusak, sehingga Anda masih dapat menambahkan barang Anda sendiri ke Manifest.

@reduz

Tidak yakin bahwa penandatanganan harus berada di pihak Godot. Plugin Android untuk Gradle memiliki fitur hebat untuk itu https://developer.android.com/studio/build/build-variants#signing , jadi pada ekspor kami hanya memeriksa keystore dan kata sandi, dan Gradle melakukan semua pekerjaan.

Dan untuk Manifes. Ketika saya mengatakan tentang sistem plugin, maksud saya persis seperti itu: setiap plugin menyatakan izin, dan pada ekspor kami mengumpulkan semua plugin yang disertakan dan menghasilkan AndroidManifest.xml. Juga, dengan cara ini kami dapat menyertakan Layanan perpustakaan dan BraodcastReceivers.

Untuk sumber daya seperti nama dan ikon - bagaimana dengan sumber daya placeholder, dan ketika dikonfigurasi dalam pengaturan proyek, cukup ganti placeholder dengan nilai dari pengaturan proyek? Jadi, pengguna akhir tidak akan melihat semua hal android yang mengerikan ini sama sekali.

Apakah mungkin dengan alur kerja ekspor baru untuk memiliki paket game di luar APK alih-alih di-zip lagi (folder atau .pck)?

@LinuxUserGD bukan Apk Expansion (.obb) untuk itu?
itu sudah ada.

Apa pun yang kita lakukan, itu harus fleksibel dan perlu memastikan itu tidak seperti cara persatuan. Ini berantakan ketika kita mencampur dan mencocokkan beberapa plugin yang memiliki ketergantungan yang sama.

Adapun manifes, saya juga ingin membuatnya tetap dapat diedit secara manual.

Build saat ini sangat fleksibel sehingga saya dapat mengedit template dan menambah/menghapus apa pun yang saya inginkan dan tidak ada yang akan mengganggu saat membuat template.

Saya pikir sesuatu seperti sistem hybrid akan bekerja?

Tidak diragukan lagi proposal 2 terdengar lebih baik, lebih bersih dan lebih "tepat".
@reduz Kontra proposal 2? Saya membayangkan itu merepotkan hanya ketika Internet cepat tidak tersedia.
Godot, seperti Android Studio mungkin dapat dengan mudah (sebagai file teks?) meneruskan ke sdkmanager daftar paket yang diperlukan untuk mengunduh https://developer.android.com/studio/command-line/sdkmanager

Usulan 2, pasti.

Usulan #2. Instalasi Android SDK cukup mudah saat ini!

@reduz , saya memilih proposal 2. Tapi, tolong jangan lupa tentang #18141

proposal 2. Gradle juga didokumentasikan sehingga kami akan memiliki lebih banyak sumber daya. Sebagian besar pengembang seluler akan menginstal Android SDK di suatu tempat di sistem mereka.

Usulan 2

Kapan ini akan dilaksanakan, ada info atau apa
@akien-mga Apakah ini masih tonggak untuk 3.1?

Menurut posting blog ini dari godotengine.org/news dari 23 November 2018:

Godot 3.1 akan menjadi rilis yang mencakup area permukaan yang jauh lebih luas dari apa yang diharapkan pengguna kami, jadi kami tidak terlalu membutuhkan fitur baru lagi. Satu-satunya fitur besar yang direncanakan setelah 3.1 adalah porting rendering ke Vulkan...

Nah, fitur dari masalah saat ini tampaknya telah mengumpulkan cukup perhatian untuk dipertimbangkan untuk 3.2. Apakah ada alasan mengapa itu tidak dialamatkan di posting blog?

Kami kehabisan waktu untuk refactor besar ekspor Android, jadi ini untuk 3.2.

Karena android menawarkan berbagai plugin dan database pihak ketiga (Firebase, Cloud, ML,), sepertinya ide yang baik untuk menginstal android sdk/jdk/ndk untuk pengembangan berkelanjutan. Alasannya karena perpustakaan android berubah dengan versi di sana mungkin beberapa pustaka ketergantungan hilang saat pengeksporan dilakukan tanpa menginstal versi SDK yang tepat. Tetapi pendekatan ini sebaliknya mengharuskan pengguna atau pengembang akhir untuk mengirimkan seluruh produk ke platform Android hanya demi pengujian yang menimbulkan overhead waktu .Pendekatan alternatif dapat dilakukan seperti membuat aplikasi untuk android yang menggunakan android studio sdk dan jdk pada perangkat untuk pengujian. Pengguna cukup menjalankan aplikasi yang terhubung dengan komputer dengan port kabel dan kemudian menjalankan game di editor godot itu sendiri dan melihat perubahan pada ponsel atau ponsel. Ponsel menggunakan SDK android komputer melalui portnya dan sejauh menyangkut Proposal1 ada sedikit overhead waktu dan juga hampir transparan, tidak diperlukan peretasan.
Karena ada pustaka tertentu dalam kode kernel android yang jika tidak diinstal akan menyebabkan runtime crash sebagian besar dengan java.lang.io.exceptions. Ada juga masalah yang harus diatasi bahwa jika Proposal 1 didahulukan maka itu berarti meretas menjadi terpisah versi android masing-masing memiliki lebih banyak ketergantungan daripada yang sebelumnya.Proposal 2 dapat dibuat hanya dengan menginstal android sdk di komputer dan menggunakan aplikasi android (yang akan dibangun) oleh pengembang untuk langsung memeriksa game mereka di ponsel; lebih seperti remote.Untuk membangun penuh aplikasi atau mengekspor pendekatan umum 2 dapat diambil.
Sejauh menyangkut template, template adaptif android8+ dapat digunakan. Selain itu, untuk mempersingkat waktu pembuatan aplikasi (dengan menggunakan SDK ) optimasi mesin untuk meningkatkan pengumpul sampah dan juga optimasi seperti pendekatan berbasis struct dapat dilakukan digunakan.
Ini sepenuhnya perspektif saya, jika tidak apa-apa maka saya memiliki beberapa rencana yang dibuat mengenai aplikasi (android) yang menggunakan SDK perangkat untuk membangun aplikasi game secara instan.

Google Play sekarang menerima aplikasi yang diunggah dalam format Android App Bundle (AAB) baru mereka.

Format ini memungkinkan Google Play menghasilkan APK secara dinamis untuk banyak jenis perangkat dan salah satu fitur yang secara langsung memengaruhi game yang dibuat di Godot adalah mengemas APK yang hanya berisi pustaka asli yang dibuat untuk arsitektur CPU tertentu.

Ini berarti bahwa ukuran unduhan dapat sangat ditingkatkan dengan memiliki APK yang diunduh oleh perangkat x86 hanya berisi pustaka x86, yang diunduh oleh arm64 hanya berisi pustaka arm64 dan seterusnya dan seterusnya.

Saya percaya pendekatan apa pun yang diambil Godot harus mendukung format pengemasan baru ini, tetapi saya tidak tahu betapa mudahnya "meretas" paket AAB berbeda dengan paket APK yang pada dasarnya adalah file ZIP.

Ini berarti bahwa ukuran unduhan dapat sangat ditingkatkan dengan memiliki APK yang diunduh oleh perangkat x86 hanya berisi pustaka x86, yang diunduh oleh arm64 hanya berisi pustaka arm64 dan seterusnya dan seterusnya.

Perhatikan bahwa ini sudah memungkinkan, tetapi memerlukan pekerjaan manual dengan membuat satu APK per arsitektur, lalu mengunggahnya ke Google Play menggunakan dukungan multi-APK-nya .

Ini diperbaiki oleh #27781, yang pada dasarnya mengimplementasikan campuran 1 dan 2. Sistem lama dipertahankan untuk penerapan satu klik, tetapi rilis sekarang akan dikirimkan dengan sumber template yang telah dikompilasi sebelumnya yang dapat dikompilasi ulang dalam APK baru dengan modul khusus /perubahan nyata/dll. menggunakan gradasi.