Android Oculus VR fails to build with No signature of method: (...) is applicable

Gaming and Visualization Technologies XR – VR/AR/MR CloudXR (VR and AR Streaming)
1

image

I’m trying to build the oculus VR client using the above configuration. Gradle plugin is set to 3.6.4 and gradle version 7.3

Build file ‘C:\OculusVR\app\build.gradle’ line: 8

A problem occurred evaluating project ‘:app’.

No signature of method: build_5sydjdpldan2vnmbrwryc8z1h.android() is applicable for argument types: (build_5sydjdpldan2vnmbrwryc8z1h$_run_closure2) values: [build_5sydjdpldan2vnmbrwryc8z1h$_run_closure2@3370bd85]

Which points to this line in the build.gradle.

android {
    signingConfigs {
        release {
            storeFile file('./dummy.jks')
            storePassword 'nvidia'
            keyAlias 'nvidia'
            keyPassword 'nvidia'
        }
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            buildConfigField "boolean", "ENABLE_DEBUG", "false"
            signingConfig signingConfigs.release
        }

        debug {
            buildConfigField "boolean", "ENABLE_DEBUG", "true"
        }
    }


    buildToolsVersion '28.0.3'
    ndkVersion '21.4.7075529'
    compileSdk 25// current LTS atm

    defaultConfig {
        applicationId "com.nvidia.cloudxr.ovr"
        minSdkVersion 25
        targetSdkVersion 28
        versionCode 1
        versionName "1.0"
        ndk {
            abiFilters "arm64-v8a"
        }
    }


    lintOptions {
        abortOnError false
    }
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_6
        targetCompatibility JavaVersion.VERSION_1_6
    }
}

Anyone know how I can solve this?

2

This problem disappeared when I changed to Java version 8

3

thanks for replying. that was EXACTLY what I was going to call out.

the java version and keys recently bit me as well. we were building on a cloud machine with multiple installed JREs, and some other build had generated the user-default debug key. Assumedly with 1.7, not 1.8. So it was invalid. Duplicating the release block above to a debug block solved the issue by just using our internal fake key.

At some point, developers should generate their own signing keys as they work towards an actual application. but for basic experimentation, the fake keys are fine.