Android Studio - Javadoc task

 Gradle task to generate Javadoc

    The task definition shouldn't be within the Android block and in this case, its used in an application project. For a library project, just replace android.applicationVariants to android.libraryVariants. The task refers to the source code and the Android's SDK jar and excludes build generated source files.

android {
    compileSdkVersion 19
    buildToolsVersion '19.1.0'

    defaultConfig {
        minSdkVersion 19
        targetSdkVersion 19
        versionCode 1
        versionName "1.0"
    }
    buildTypes {
        release {
            runProguard false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'
        }
    }

}

android.applicationVariants.all { variant ->

     task("generate${variant.name}Javadoc", type: Javadoc) {
        title = "$name $version API"
        description "Generates Javadoc for $variant.name."
        source = variant.javaCompile.source
        ext.androidJar = "${android.sdkDirectory}/platforms/${android.compileSdkVersion}/android.jar"
        classpath = files(variant.javaCompile.classpath.files) + files(ext.androidJar)
        exclude '**/BuildConfig.java'
        exclude '**/R.java'
    }

 }

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
}

     Once defined and synced, the task should appear in the Gradle tasks section. Clicking on either the debug or release version should save the javadocs in build/docs/javadoc under the application directory and the actual javadoc options is saved in build/tmp/generatedebugJavadoc under a file named javadoc.options.


Comments

Anonymous said…
Doesn't work anymore
January 16, 2015 at 4:58 PM
. said…
Doesn't work as in? I used in this Studio 1.0
February 4, 2015 at 7:13 PM
Post a Comment

Popular posts from this blog

Android Shared User ID and android:process

      Android's shared user id (android:sharedUserId) is a way for different applications to share the same user id for permissions, which lets them access their data and host their components in other process space. By declaring a new sharedUserId in the manifest, a new user id is creating during installation and is ready to be used by other applications provided they are signed with the same certificate and one such use is to update android:process of an application component to host it in other process space.    However, if the applications don't share a user id and aren't signed with the same certificate, a new process is launched with the same name as in android:process and this new process automatically shares userId with the requested application.    If the applications share user id and and aren't signed by the same certificate, the installation of the apk would fail.     If the applications share user id and are signed by the ...
Read more

Android's Watchdog daemon

    Android framework's Watchdog (Java implementation) is meant to handle cases when the framework ends up in an unresponsive state. However, this doesn't help handle kernel or other OEM specific driver issues. Chip vendors usually provide a hardware watchdog to hard reset the system to handle software failures. The hardware watchdog just waits to be reset by software within a specific duration and force resets the system if otherwise. The hardware watchdog is just handled by a vendor specific watchdog driver and it exposes IOCTL APIs for user space to set timeout interval, reset the watchdog etc. So does Android provide any support?     Its supported by a daemon process (/sbin/watchdogd) and OEMs could use this to fine tune timeout intervals or even completely disable it. watchdogd is really a symbolic link to init process.     lrwxrwxrwx root     root              1969-12-31 19:00 watchdogd -> ../init ...
Read more

Android : Watchdog is killing system server

Here goes my first fix in Android. Watchdog of the android framework is implemented to make sure the framework is rebooted in case of non-recoverable errors like deadlocks etc. Usually, i have seen frameworks where in the entire phone is rebooted upon such errors. Android is smart in the sense that its efficient by offering the framework reboot within seconds [Technically, it is just spawning of a linux process, system_server]. Monkey is a tool available to feed in random key events for stress testing and we happened to see a lot of scenarios where in the watchdog would kill the system server, causing android framework reboot. It seemed as if the root cause was within the framework and moreover it was random key events passed to the framework over many hours. The pattern to reproduce was not known but yet happened quite often. Like all bugs, it turned out to be 100% reproducible just that it took time to figure out the pattern. Monkey has an activitycontroller to report ANRs an...
Read more