Tag: android gradle build system

Problems with the new GPS Automatic License Notice Generator

Following up on my previous post, here’s a screenshot of the OSS license item for the popular Glide library as generated by version 11.2.2 of the new GPS OSS tools. There are two distinct OSS licenses for the Glide library and the GPS OSS tools finds both of them. But it concatenates the two URLs without a space or line break in between. They’re just stuck together:

To fix that, I added a gradle hack which runs after the app’s preBuild gradle task. The code block, placed at the bottom of build.gradle, carries out a specific edit within third_party_licenses (a text file generated by the OSS gradle plugin):

preBuild.doLast({
    String thirdPartyLicenseFilePath = 'app/src/main/res/raw/third_party_licenses'
    File thirdPartyLicenses = new File(thirdPartyLicenseFilePath)
    if (thirdPartyLicenses.exists()) {
        String contents = thirdPartyLicenses.getText('UTF-8')
        contents = contents.replace("licensehttp://", "license http://")
        thirdPartyLicenses.setText(contents, 'UTF-8')
    } else {
        println "cannot find " + thirdPartyLicenseFilePath
    }
})

Sure enough, the hack adds a space between the two urls:

But there’s a new problem: the ‘t’ at the very end of the second url is no longer present. (Look closely. The url points to a ‘.tx’ file instead of a ‘.txt’ file).

On one of my android devices, it appears that there’s a 92 character length limit on that string. Or something. I have yet to discover where that limit is set.

Comment

Quick Notes On Dockter’s 2015 BABBQ Talk on the Android Gradle Build System

Hans Dockter gave a talk about the Android Gradle build system at Big Android BBQ 2015(No bbq for me … saw it on youtube … woo hoo) 

Dockter addresses the issue of Android build performance in the last half of the talk. A few of my takeaways, for what they’re worth:

  • Android developers should try an upgrade to Gradle 2.8
  • Build times are slow mostly because of dexing and pre-dexing. There’s nothing Gradle can do to improve dexing time, per se.
  • Right now, a clean build deletes your pre-dexed libraries. So, they must be re pre-dexed each time. But, in the future, there will be an optimization where pre-dexed versions of libraries necessary to your project are cached resiliently. So, even if you clean your project, their dexed versions persist.
  • Future improvements in the Android toolchain or Gradle for Android will include incremental dexing and concurrent dexing.

Dockter also mentioned the possibility of caching pre-dexed libraries on a CI Server so they’d be available to all developers in the organization. (Or something like that.)

I wonder if teams that use a third party, CI server in the cloud will also be able to take advantage of this sort of optimization. 

Comment