Android NDK support for nativeBinaries

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Android NDK support for nativeBinaries

Michael Putters
Hello,

With the new Android NDK bringing support for 64-bit ARM CPUs, I thought
it would be a good time to add Android NDK support to Gradle's cpp
subproject (with iOS following a bit further down the line). However
before diving in, I have some questions regarding - among other things -
the DSL and how the nice folks at Gradleware (especially Daz) want
things done:

1. Toolchain

1.a. The Android NDK provides gcc and clang toolchains (for multiple
architectures), so it makes sense to re-use the existing gcc code. While
I worked a bit on the VisualCppToolchain detection code, I'm not quite
sure how the gcc detection works at this point, but would it be ok to
have a simple mechanism checking if the ANDROID_NDK environment variable
is present and use that as a basis to detect available toolchains?

1.b. If the ANDROID_NDK variable is not available, the following could
be used:

model {
   toolChains {
     gcc(Gcc) {
       target('android') {
         path
'C:/android/ndk/r10/toolchains/aarch64-linux-4.9/prebuilt/windows-x86_64/bin'
       }
     }
   }
   platform {
     android {
       architecture 'aarch64'
       operatingSystem 'android'
     }
   }
}

1.c. The Android NDK toolchains have multiple packages, one for each
target architecture. The compiler and its version can be detected from
the toolchain's directory (eg: aarch64-linux-android-clang3.4 is clang
3.4 for the 64-bit ARM architecture), but does it mean I should a single
toolchain (or at least one for gcc and one for clang) and an
addPlatformConfiguration per supported architecture? Would that be an
issue if we want to be able to do linux and android builds side by side?

2. Manifest

2.a. Android applications have an AndroidManifest.xml file that declares
various information about the application, including its version and
minimum/target operating system requirements. I'm assuming we should
look for this file in /src/main/AndroidManifest.xml like they expect for
the Android plugin?

2.b. It would be nice to be able to inject the minimum/target SDK level
and the application version in the AndroidManifest.xml file before
building, by copying the manifest to a temporary location modifying it
there. But what would be the best way to specify the SDK level in the
DSL? The Android plugin uses an android { } block, but I was thinking
with the current DSL the easiest would be something like
(pseudo-ish-code):

platforms {
   android {}
}

binaries.all {
   if (platform == targetPlatforms.android) {
     manifest.minSdkVersion = 9
     manifest.targetSdkVersion = 18
   }
}

The manifest DSL object could also be used for Windows applications to
embed a manifest in the resources.

I guess the (global and less complex?) alternative would be adding it to
the platform itself...

3. Resources

3.a. Should resources go in /src/main/res as the Android plugin expects,
or in /src/main/rc like the windows resource plugin expects? At the
moment I'm using /src/main/rc for both windows and linux (using objcopy
on linux to do something similar to what rc.exe does). Technically, the
Windows-ish /src/main/rc is closer to Android's assets (which are just
abstract binary files) and Android's resources (which are images/xml/etc
in directories with a particular naming convention).


That's about it for now, this should be enough to get me started...

BR,


Michael

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Android NDK support for nativeBinaries

Xavier Ducrohet
Hi Michael

We are actually already working on a new NDK integration using the new c/cpp gradle plugin. It's a work in progress, but there's already code in our tree.




On Wed, Aug 13, 2014 at 5:53 AM, Michael Putters <[hidden email]> wrote:
Hello,

With the new Android NDK bringing support for 64-bit ARM CPUs, I thought it would be a good time to add Android NDK support to Gradle's cpp subproject (with iOS following a bit further down the line). However before diving in, I have some questions regarding - among other things - the DSL and how the nice folks at Gradleware (especially Daz) want things done:

1. Toolchain

1.a. The Android NDK provides gcc and clang toolchains (for multiple architectures), so it makes sense to re-use the existing gcc code. While I worked a bit on the VisualCppToolchain detection code, I'm not quite sure how the gcc detection works at this point, but would it be ok to have a simple mechanism checking if the ANDROID_NDK environment variable is present and use that as a basis to detect available toolchains?

1.b. If the ANDROID_NDK variable is not available, the following could be used:

model {
  toolChains {
    gcc(Gcc) {
      target('android') {
        path 'C:/android/ndk/r10/toolchains/aarch64-linux-4.9/prebuilt/windows-x86_64/bin'
      }
    }
  }
  platform {
    android {
      architecture 'aarch64'
      operatingSystem 'android'
    }
  }
}

1.c. The Android NDK toolchains have multiple packages, one for each target architecture. The compiler and its version can be detected from the toolchain's directory (eg: aarch64-linux-android-clang3.4 is clang 3.4 for the 64-bit ARM architecture), but does it mean I should a single toolchain (or at least one for gcc and one for clang) and an addPlatformConfiguration per supported architecture? Would that be an issue if we want to be able to do linux and android builds side by side?

2. Manifest

2.a. Android applications have an AndroidManifest.xml file that declares various information about the application, including its version and minimum/target operating system requirements. I'm assuming we should look for this file in /src/main/AndroidManifest.xml like they expect for the Android plugin?

2.b. It would be nice to be able to inject the minimum/target SDK level and the application version in the AndroidManifest.xml file before building, by copying the manifest to a temporary location modifying it there. But what would be the best way to specify the SDK level in the DSL? The Android plugin uses an android { } block, but I was thinking with the current DSL the easiest would be something like (pseudo-ish-code):

platforms {
  android {}
}

binaries.all {
  if (platform == targetPlatforms.android) {
    manifest.minSdkVersion = 9
    manifest.targetSdkVersion = 18
  }
}

The manifest DSL object could also be used for Windows applications to embed a manifest in the resources.

I guess the (global and less complex?) alternative would be adding it to the platform itself...

3. Resources

3.a. Should resources go in /src/main/res as the Android plugin expects, or in /src/main/rc like the windows resource plugin expects? At the moment I'm using /src/main/rc for both windows and linux (using objcopy on linux to do something similar to what rc.exe does). Technically, the Windows-ish /src/main/rc is closer to Android's assets (which are just abstract binary files) and Android's resources (which are images/xml/etc in directories with a particular naming convention).


That's about it for now, this should be enough to get me started...

BR,


Michael

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

RE: Android NDK support for nativeBinaries

Michael Putters

Hello Xavier,

 

You mean as part of the Android plugin?

 

From: Xavier Ducrohet [mailto:[hidden email]]
Sent: Wednesday, August 13, 2014 7:56 PM
To: [hidden email]
Subject: Re: [gradle-dev] Android NDK support for nativeBinaries

 

Hi Michael

 

We are actually already working on a new NDK integration using the new c/cpp gradle plugin. It's a work in progress, but there's already code in our tree.

 

 

 

On Wed, Aug 13, 2014 at 5:53 AM, Michael Putters <[hidden email]> wrote:

Hello,

With the new Android NDK bringing support for 64-bit ARM CPUs, I thought it would be a good time to add Android NDK support to Gradle's cpp subproject (with iOS following a bit further down the line). However before diving in, I have some questions regarding - among other things - the DSL and how the nice folks at Gradleware (especially Daz) want things done:

1. Toolchain

1.a. The Android NDK provides gcc and clang toolchains (for multiple architectures), so it makes sense to re-use the existing gcc code. While I worked a bit on the VisualCppToolchain detection code, I'm not quite sure how the gcc detection works at this point, but would it be ok to have a simple mechanism checking if the ANDROID_NDK environment variable is present and use that as a basis to detect available toolchains?

1.b. If the ANDROID_NDK variable is not available, the following could be used:

model {
  toolChains {
    gcc(Gcc) {
      target('android') {
        path 'C:/android/ndk/r10/toolchains/aarch64-linux-4.9/prebuilt/windows-x86_64/bin'
      }
    }
  }
  platform {
    android {
      architecture 'aarch64'
      operatingSystem 'android'
    }
  }
}

1.c. The Android NDK toolchains have multiple packages, one for each target architecture. The compiler and its version can be detected from the toolchain's directory (eg: aarch64-linux-android-clang3.4 is clang 3.4 for the 64-bit ARM architecture), but does it mean I should a single toolchain (or at least one for gcc and one for clang) and an addPlatformConfiguration per supported architecture? Would that be an issue if we want to be able to do linux and android builds side by side?

2. Manifest

2.a. Android applications have an AndroidManifest.xml file that declares various information about the application, including its version and minimum/target operating system requirements. I'm assuming we should look for this file in /src/main/AndroidManifest.xml like they expect for the Android plugin?

2.b. It would be nice to be able to inject the minimum/target SDK level and the application version in the AndroidManifest.xml file before building, by copying the manifest to a temporary location modifying it there. But what would be the best way to specify the SDK level in the DSL? The Android plugin uses an android { } block, but I was thinking with the current DSL the easiest would be something like (pseudo-ish-code):

platforms {
  android {}
}

binaries.all {
  if (platform == targetPlatforms.android) {
    manifest.minSdkVersion = 9
    manifest.targetSdkVersion = 18
  }
}

The manifest DSL object could also be used for Windows applications to embed a manifest in the resources.

I guess the (global and less complex?) alternative would be adding it to the platform itself...

3. Resources

3.a. Should resources go in /src/main/res as the Android plugin expects, or in /src/main/rc like the windows resource plugin expects? At the moment I'm using /src/main/rc for both windows and linux (using objcopy on linux to do something similar to what rc.exe does). Technically, the Windows-ish /src/main/rc is closer to Android's assets (which are just abstract binary files) and Android's resources (which are images/xml/etc in directories with a particular naming convention).


That's about it for now, this should be enough to get me started...

BR,


Michael

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

 

Reply | Threaded
Open this post in threaded view
|

Re: Android NDK support for nativeBinaries

Xavier Ducrohet
It'll be a separate plugin but it'll work with our normal plugin as well.

This will allow us to support either building only a native library for android, or building one as part of an hybrid app.


On Wed, Aug 13, 2014 at 11:52 AM, Michael Putters <[hidden email]> wrote:

Hello Xavier,

 

You mean as part of the Android plugin?

 

From: Xavier Ducrohet [mailto:[hidden email]]
Sent: Wednesday, August 13, 2014 7:56 PM
To: [hidden email]
Subject: Re: [gradle-dev] Android NDK support for nativeBinaries

 

Hi Michael

 

We are actually already working on a new NDK integration using the new c/cpp gradle plugin. It's a work in progress, but there's already code in our tree.

 

 

 

On Wed, Aug 13, 2014 at 5:53 AM, Michael Putters <[hidden email]> wrote:

Hello,

With the new Android NDK bringing support for 64-bit ARM CPUs, I thought it would be a good time to add Android NDK support to Gradle's cpp subproject (with iOS following a bit further down the line). However before diving in, I have some questions regarding - among other things - the DSL and how the nice folks at Gradleware (especially Daz) want things done:

1. Toolchain

1.a. The Android NDK provides gcc and clang toolchains (for multiple architectures), so it makes sense to re-use the existing gcc code. While I worked a bit on the VisualCppToolchain detection code, I'm not quite sure how the gcc detection works at this point, but would it be ok to have a simple mechanism checking if the ANDROID_NDK environment variable is present and use that as a basis to detect available toolchains?

1.b. If the ANDROID_NDK variable is not available, the following could be used:

model {
  toolChains {
    gcc(Gcc) {
      target('android') {
        path 'C:/android/ndk/r10/toolchains/aarch64-linux-4.9/prebuilt/windows-x86_64/bin'
      }
    }
  }
  platform {
    android {
      architecture 'aarch64'
      operatingSystem 'android'
    }
  }
}

1.c. The Android NDK toolchains have multiple packages, one for each target architecture. The compiler and its version can be detected from the toolchain's directory (eg: aarch64-linux-android-clang3.4 is clang 3.4 for the 64-bit ARM architecture), but does it mean I should a single toolchain (or at least one for gcc and one for clang) and an addPlatformConfiguration per supported architecture? Would that be an issue if we want to be able to do linux and android builds side by side?

2. Manifest

2.a. Android applications have an AndroidManifest.xml file that declares various information about the application, including its version and minimum/target operating system requirements. I'm assuming we should look for this file in /src/main/AndroidManifest.xml like they expect for the Android plugin?

2.b. It would be nice to be able to inject the minimum/target SDK level and the application version in the AndroidManifest.xml file before building, by copying the manifest to a temporary location modifying it there. But what would be the best way to specify the SDK level in the DSL? The Android plugin uses an android { } block, but I was thinking with the current DSL the easiest would be something like (pseudo-ish-code):

platforms {
  android {}
}

binaries.all {
  if (platform == targetPlatforms.android) {
    manifest.minSdkVersion = 9
    manifest.targetSdkVersion = 18
  }
}

The manifest DSL object could also be used for Windows applications to embed a manifest in the resources.

I guess the (global and less complex?) alternative would be adding it to the platform itself...

3. Resources

3.a. Should resources go in /src/main/res as the Android plugin expects, or in /src/main/rc like the windows resource plugin expects? At the moment I'm using /src/main/rc for both windows and linux (using objcopy on linux to do something similar to what rc.exe does). Technically, the Windows-ish /src/main/rc is closer to Android's assets (which are just abstract binary files) and Android's resources (which are images/xml/etc in directories with a particular naming convention).


That's about it for now, this should be enough to get me started...

BR,


Michael

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

 


Reply | Threaded
Open this post in threaded view
|

RE: Android NDK support for nativeBinaries

Michael Putters

Nice, maybe my pull request will only rename armv8 to aarch64 then ;-)

Looking forward to testing that new plugin.

 

From: Xavier Ducrohet [mailto:[hidden email]]
Sent: Wednesday, August 13, 2014 8:56 PM
To: [hidden email]
Subject: Re: [gradle-dev] Android NDK support for nativeBinaries

 

It'll be a separate plugin but it'll work with our normal plugin as well.

 

This will allow us to support either building only a native library for android, or building one as part of an hybrid app.

 

On Wed, Aug 13, 2014 at 11:52 AM, Michael Putters <[hidden email]> wrote:

Hello Xavier,

 

You mean as part of the Android plugin?

 

From: Xavier Ducrohet [mailto:[hidden email]]
Sent: Wednesday, August 13, 2014 7:56 PM
To: [hidden email]
Subject: Re: [gradle-dev] Android NDK support for nativeBinaries

 

Hi Michael

 

We are actually already working on a new NDK integration using the new c/cpp gradle plugin. It's a work in progress, but there's already code in our tree.

 

 

 

On Wed, Aug 13, 2014 at 5:53 AM, Michael Putters <[hidden email]> wrote:

Hello,

With the new Android NDK bringing support for 64-bit ARM CPUs, I thought it would be a good time to add Android NDK support to Gradle's cpp subproject (with iOS following a bit further down the line). However before diving in, I have some questions regarding - among other things - the DSL and how the nice folks at Gradleware (especially Daz) want things done:

1. Toolchain

1.a. The Android NDK provides gcc and clang toolchains (for multiple architectures), so it makes sense to re-use the existing gcc code. While I worked a bit on the VisualCppToolchain detection code, I'm not quite sure how the gcc detection works at this point, but would it be ok to have a simple mechanism checking if the ANDROID_NDK environment variable is present and use that as a basis to detect available toolchains?

1.b. If the ANDROID_NDK variable is not available, the following could be used:

model {
  toolChains {
    gcc(Gcc) {
      target('android') {
        path 'C:/android/ndk/r10/toolchains/aarch64-linux-4.9/prebuilt/windows-x86_64/bin'
      }
    }
  }
  platform {
    android {
      architecture 'aarch64'
      operatingSystem 'android'
    }
  }
}

1.c. The Android NDK toolchains have multiple packages, one for each target architecture. The compiler and its version can be detected from the toolchain's directory (eg: aarch64-linux-android-clang3.4 is clang 3.4 for the 64-bit ARM architecture), but does it mean I should a single toolchain (or at least one for gcc and one for clang) and an addPlatformConfiguration per supported architecture? Would that be an issue if we want to be able to do linux and android builds side by side?

2. Manifest

2.a. Android applications have an AndroidManifest.xml file that declares various information about the application, including its version and minimum/target operating system requirements. I'm assuming we should look for this file in /src/main/AndroidManifest.xml like they expect for the Android plugin?

2.b. It would be nice to be able to inject the minimum/target SDK level and the application version in the AndroidManifest.xml file before building, by copying the manifest to a temporary location modifying it there. But what would be the best way to specify the SDK level in the DSL? The Android plugin uses an android { } block, but I was thinking with the current DSL the easiest would be something like (pseudo-ish-code):

platforms {
  android {}
}

binaries.all {
  if (platform == targetPlatforms.android) {
    manifest.minSdkVersion = 9
    manifest.targetSdkVersion = 18
  }
}

The manifest DSL object could also be used for Windows applications to embed a manifest in the resources.

I guess the (global and less complex?) alternative would be adding it to the platform itself...

3. Resources

3.a. Should resources go in /src/main/res as the Android plugin expects, or in /src/main/rc like the windows resource plugin expects? At the moment I'm using /src/main/rc for both windows and linux (using objcopy on linux to do something similar to what rc.exe does). Technically, the Windows-ish /src/main/rc is closer to Android's assets (which are just abstract binary files) and Android's resources (which are images/xml/etc in directories with a particular naming convention).


That's about it for now, this should be enough to get me started...

BR,


Michael

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email