Currently we have target types for Android of "apk" and "aab". These (other than legacy APK mode) generate a structure that works for the Android Gradle Plug-in (also used by Android Studio) and then use Gradle to build the release apk or aab file.
However it would be trivial to add a new target "AndroidStudio" that could be used to omit the Gradle stage but generate the folder that can then be used directly with Android Studio. Users can then open up the folder in Android Studio and do builds, debugging etc from there.
As a secondary note .. this could be a first step towards then having a process that monitors the original location of the SWF file for any changes, and if there are changes then it could update a Android handset that's currently connected via FDB in order to provide a much quicker way to reload the app. No need for packaging or re-installing, we could just have the runtime pick up the new SWF and restart itself..
raresn
commented
2 years ago
Currently we have target types for Android of "apk" and "aab". These (other than legacy APK mode) generate a structure that works for the Android Gradle Plug-in (also used by Android Studio) and then use Gradle to build the release apk or aab file.
However it would be trivial to add a new target "AndroidStudio" that could be used to omit the Gradle stage but generate the folder that can then be used directly with Android Studio. Users can then open up the folder in Android Studio and do builds, debugging etc from there.
As a secondary note .. this could be a first step towards then having a process that monitors the original location of the SWF file for any changes, and if there are changes then it could update a Android handset that's currently connected via FDB in order to provide a much quicker way to reload the app. No need for packaging or re-installing, we could just have the runtime pick up the new SWF and restart itself..