Done, and I also added a way to set the version from project.xml:
<android gradle-version="2.14-rc-1" />
Whatever string you specify is inserted into build.gradle and gradle-wrapper.properties. It can be any value listed here, and it defaults to 2.10.
Looking at that list… why are we using 2.10 instead of 2.13?
There is no exact reason. I just put value already existed in gradle-wrapper.properties.
Actually for android development there is no big profit to always use latest version.
But if you think that we should use 2.13 - it’s ok.
I tried to rewrite ant configs to gradle configs, and found one problem with extensions - every existing extension for OpenFL use ant, but future extensions should also use gradle.
To add dependency on gradle project, settings.gradle should be used, but to add dependency on ant project, different approach should be used, http://stackoverflow.com/a/31471212 for example.
So we need somehow generate one code for gradle extensions, and different code for ant extensions.
What if we insert a build.gradle file into the Ant project? (I think this is possible.) Then we could import everything via settings.gradle.
Thanks for offering to write build.gradle. If you can handle that, I’ll be happy to restructure the project. First, I’d just like to make sure we’re on the same page.
Based on the above link, here’s what I’m planning:
Export/android/bin
├─ dependency0
│ ├─ build.gradle
│ └─ ...
├─ dependency1
│ ├─ build.gradle
│ ├─ build.xml
│ └─ ...
├─ app
│ ├─ libs
│ ├─ src
│ │ └─ main
│ │ ├─ java
│ │ │ ├─ com/project/path
│ │ │ └─ org/haxe/lime
│ │ ├─ res
│ │ ├─ assets
│ │ └─ AndroidManifest.xml
│ └─ build.gradle
├─ build.gradle
└─ settings.gradle
The names “dependency0,” “dependency1,” and “com/project/path” are placeholders. Other than that, those are the exact names I’m planning to use.
I removed a few files/folders (notably androidTest); let me know if I should add them back. Otherwise, does that look good?
That’s good. If build.gradle already exists, than it was new extension, and we should do nothing, otherwise it is old extension, and we can put build.gradle with following contents:
ant.importBuild 'build.xml'
task wrapper(type: Wrapper) {
gradleVersion = '::ANDROID_GRADLE_VERSION::'
}
About folder structure - looks good.
I also create “mix” from several real-world projects:
Export/android/bin
├─ app/
│ ├─ libs/
│ └─ src/
│ └─ main/
│ ├─ assets/
│ ├─ java/
│ │ ├─ com/project/path/
│ │ └─ org/haxe/lime/
│ ├─ jniLibs/
│ ├─ res/
│ │ ├─ mipmap-hdpi/
│ │ ├─ mipmap-mdpi/
│ │ ├─ mipmap-xhdpi/
│ │ ├─ mipmap-xxhdpi/
│ │ └─ mipmap-xxxhdpi/
│ └─ AndroidManifest.xml
├─ deps/
│ ├─ dependency0/
│ │ ├─ build.gradle
│ │ └─ ...
│ └─ dependency1/
│ ├─ build.gradle
│ ├─ build.xml
│ └─ ...
├─ gradle/
│ └─ wrapper/
│ ├─ gradle-wrapper.jar
│ └─ gradle-wrapper.properties
├─ build.gradle
├─ gradle.properties
├─ gradlew
├─ gradlew.bat
├─ local.properties
└─ settings.gradle
gradle.properties - not sure if it is good for generated project, but probably we can put here version codes, build tools versions and etc. Obliviously, we can put it directly to build.gradle (because this file will be generated), but at my point of view, it will be more cool to keep settings in special file.local.properties - things like sdk.dir and ndk.dir should go here.settings.gradle - to include dependencies.deps/ - we can leave dependencies in separate folder (like current).app/src/main/jniLibs/ - while app/libs is for .jar, jniLibs is for .so files. I’m not sure why libs/ is just inside app/, but jniLibs/ is inside app/src/main/ - I just take everything from various real-world projects. It need more investigation.File structure updated. I haven’t updated build.gradle, so it won’t compile yet.
Agreed.
Note: build.gradle will be generated by default, but users have the option to override it. To avoid surprises, the generated project should be set up exactly like a normal Android project.
Oddly, the current setup doesn’t use this, and I’m pretty sure it’s relevant to Ant as well as Gradle. We might want to ask Joshua about it.
Convenient! I left that exactly as-is.
I created a sample project in Android Studio, and it put the libs folder there. And this screenshot shows it in the same place. I didn’t find any explanations as to why, but no one seemed to question it, so I’ll go with it.
(Also, this confirms that jniLibs should be under src/main.)
Everything looks good 
Currently there is
<property name="sdk.dir" value="${env.ANDROID_SDK}"/>
in build.xml, where ANDROID_SDK is added to environment variables somewhere in build process (and it’s taken from .hxcpp_config.xml)
Ok, I think I got everything: the top-level build.gradle, the app build.gradle, settings.gradle, local.properties, a new extension template, and build.gradle for extensions made with the old template.
However, almost none of this is tested. I’ll try to get to that tomorrow.
What about moving sdk versions and version name / code into gradle.properties?
Also we need add signing config:
Additionally we can give ability to configure build tools version.
It seems that extension folder structure don’t respect gradle folder structure.
Probably you should either make a different folder structure, or add sourceSets to build.gradle:
sourceSets {
main {
manifest.srcFile 'AndroidManifest.xml'
java.srcDirs = ['src']
res.srcDirs = ['res']
}
}
or new folder structure:
dependencyname
|- src
| |- main
| |- java
| | |- org/haxe/extension/
| |- AndroidManifest.xml
|- build.gradle
and following build.gradle:
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.android.tools.build:gradle:0.11.1'
}
}
apply plugin: 'android-library'
android {
compileSdkVersion Integer.parseInt(project.ANDROID_BUILD_SDK_VERSION)
// buildToolsVersion project.ANDROID_BUILD_TOOLS_VERSION
}
Notice, if we move sdk version into gradle.properties, we can use it inside dependent libraries
Done, thanks!
For the signing process, I decided to allow both options. You can use the <certificate /> tag, signing.properties, or neither. I just hope Gradle can handle null values, because my code doesn’t even check.
By the way, I changed this line. Let me know if I should change it back.
Looks good. Probably it’s time to test it
I will try it in a week or two.
I tested some sample projects, in both Next and Legacy. Results:
AddingAnimation: success!
AddingText: success!
BunnyMark: crashes in Next mode, fails to compile in Legacy. However, this happens with or without Gradle.
DisplayingABitmap: success!
HandlingMouseEvents: success!
NyanCat: success!
PiratePig: success!
PlayingSound: success!
My own project, including templates and Ant library projects: success!
Where I can get this version? I would like to try it with my project, I’m using many libraries and it would be a good test.
It’s currently only available on my GitHub page. I haven’t yet submitted a pull request because I wasn’t able to test it with the latest changes. The error seems unrelated, so hopefully they’ll fix it.
You might want to check out this version, since the latest isn’t compatible with OpenFL 3.6.1. Also, run tools.hxml and copy the ndll folder from Lime 2.9.1.
Pull request submitted!
Thank you!
That is quite the big pull request, but I know this is something that’s been needed! I will try to go through this week. Thanks again
So what’s the status on this?
If you need an explanation/justification for something, just ask! I’d like to see this added, and I’m happy to help however I can.
Hi, I’m just getting started with openfl so apologies for an ignorant question. IIUC lime currently builds to Android in two steps: first compiling .cpp to .so by explicity running gcc from the ndk, and second using ant to generate a .apk from the .so and java code. Does your change switch both steps or only the second to use gradle?
I ask because this would presumably make the first step less dependent on the ndk version. Using r12b I had to copy a folder from 4.9.x to 4.9 to get it working.
This only affects the second step.
