Default method called using invoke-static instead of invoke-interface with AGP 4.1 (r8 2.1.62) [171982443]

Verified

Bug

Status Update

No update yet.

Description

ne...@gmail.com

created issue #1

Oct 30, 2020 07:13AM

Example of bad code compilation:

BAD:

# compiler: R8
# compiler_version: 2.1.62
# min_api: 21
# pg_map_id: 0cf1471



    .line 48
    iget-object v0, p0, Lcom/company/package/subpackage1/KotlinClassThatCallsMethod;->driveButton:Lcom/company/package/subpackage2/CustomViewInterface;

    invoke-static {v0}, Lcom/company/package/subpackage2/BaseViewInterface$-CC;->a(Lcom/company/package/subpackage2/BaseViewInterface;)Lcom/company/package/core/Model;

GOOD code:

# compiler: R8
# compiler_version: 2.0.88
# min_api: 21
# pg_map_id: 543606b
# common_typos_disable


.line 48
    iget-object v0, p0, Lcom/company/package/subpackage1/KotlinClassThatCallsMethod;->driveButton:Lcom/company/package/subpackage2/CustomViewInterface;

    invoke-interface {v0}, Lcom/company/package/subpackage2/BaseViewInterface;->getModel()Lcom/company/package/core/Model;

Code structure: Java interface BaseViewInterface with:

@Deprecated
@NonNull
default Model<K> getModel() {
    throw new UnsupportedOperationException("getModel() is not supported on this ...");
}

Java interface CustomViewInterface extends BaseViewInterface.

Java class CustomViewInterfaceImpl implements CustomViewInterface with method

    @NonNull
    @Override
    public Model<...> getModel() {
        if (mModel == null) {
            setModel(...);
        }
        return mModel;
    }

KotlinClassThatCallsMethod

val view: CustomViewInterface = ....
view.model.someMethodOnModel(....) // uses property access

BaseViewInterface$-CC - class with static methods that were default in interface

Comments

mk...@google.com <mk...@google.com> #2Oct 30, 2020 07:22AM

Reassigned to mk...@google.com.

Hi, was this a regression after you upgrade your NDK or upgrade your Android Studio?

ne...@gmail.com <ne...@gmail.com> #3Oct 30, 2020 07:40AM

Neither of them. There were no change to AS (4.1-RC1) nor NDK versions.

I just changed my old scripts in build.gradle to the android recommended method i.e.

externalNativeBuild { ndkBuild { path file('jni/Android.mk') } }

If I reverted the change to my old script, everything is working again. The old scripts uses

ndk.dir=/opt/android/android-sdk/ndk-bundle

as defined in local.properties file

The source.properties files indicate the version as:

Pkg.Desc = Android NDK Pkg.Revision = 21.3.6528147

mk...@google.com <mk...@google.com> #4Oct 30, 2020 08:05AM

Hi, the problem is that when Android Gradle Plugin executes ndk-build, it is missing the '-C' + projectDir + '/jni' part in your custom task. Therefore, the current working directory is the module root (parent of the jni directory). Hence the error.

The fix is to add the following to your build.gradle

android {
    ...
    defaultConfig {
        ...
        externalNativeBuild {
            ndkBuild {
                arguments "-Cjni"
            }
        }
    }
}

Please reopen the bug if you have further issues. Thanks!

sg...@google.com <sg...@google.com> #5Oct 30, 2020 08:12AM

Please provide the full syntax for the externalNativeBuild scripts. gradle sync throws the following error message when I added the recommended argument statement to the script (or change to arguments('-Cjni'))

A problem occurred evaluating project ':aTalk'.

No signature of method: build_6xrerbyg3j4aatiomvrbavr6i.android() is applicable for argument types: (build_6xrerbyg3j4aatiomvrbavr6i$_run_closure4) values: [build_6xrerbyg3j4aatiomvrbavr6i$_run_closure4@497bb461]

externalNativeBuild {
    ndkBuild {
        path file('jni/Android.mk')
        arguments "-Cjni"
    }
}

pa...@tomtom.com <pa...@tomtom.com> #6Nov 18, 2020 08:46PM

There are actually two different types of exteranlNativeBuild blocks. The block in #4 needs to be put inside defaultConfig. So you would end up with something like

android {
    ...
    defaultConfig {
        ...
        externalNativeBuild {
            ndkBuild {
                arguments "-Cjni"
            }
        }
    }
    ...
    externalNativeBuild {
        ndkBuild {
            path file('jni/Android.mk')
        }
    }
}

pa...@tomtom.com <pa...@tomtom.com> #7Nov 19, 2020 06:51AM

Thanks for the clarification. It does resolve the last reported gradle sync problem and proceed to build and adb install.

But seeing the following errors not found in old method.
a. user now has to define what ABI to build for the adb debug; previously no such option and it is auto selected.
b. During run, it opens up a file (org_atalk_impl_neomedia_device_OpenSLESSystem.c) and indicates:
This file is not part of the project. Please include it in the appropriate build file (build.gradle, CMakeLists.txt or Android.mk etc.) and sync the project.

and the whole debug aborted with signel= SIGABRT (signal SIGABRT). and Note10 went black.

but the file already specified in the included file jni/opensles/Android.mk

# ========== OpenSLES (jnopensles.so library) ==================
### OpenSLES shared library build
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_LDLIBS := -lOpenSLES -llog
LOCAL_MODULE := jnopensles
LOCAL_SRC_FILES := \
org_atalk_impl_neomedia_device_OpenSLESSystem.c \
org_atalk_impl_neomedia_jmfext_media_protocol_opensles_DataSource.c \
org_atalk_impl_neomedia_jmfext_media_renderer_audio_OpenSLESRenderer.c
include $(BUILD_SHARED_LIBRARY)

However I realized that the new method perform the ndkBuild for every aTalk build variant (x4).
How do I make ndkBuild build only once for all the variants?

Moving the jni subDirectory into the ./src/main/jni does not seem to resolve the 4x build problem; but created other problems e.g.
a. Still proceed to build 4 times for the aTalk Build Variants.
b. Fail to perform adb install with the following error message (actual apk did contain the required ABI lib):

08/15 10:33:41: Launching 'aTalk' on samsung SM-N975F.
Installation did not succeed.
The application could not be installed: INSTALL_FAILED_NO_MATCHING_ABIS

List of apks:
[0] '/home/cmeng/workspace/android/atalk-android/aTalk/build/outputs/apk/playstore/debug/aTalk-playstore-debug.apk'
Installation failed due to: 'null'
Retry

mk...@google.com <mk...@google.com> #8Nov 19, 2020 07:19AM

Hi, you can filter ABIs with abiFilters.

Can you share the project with your changes on build.gradle?

Message last modified on Nov 19, 2020 07:22AM

pa...@tomtom.com <pa...@tomtom.com> #9Nov 20, 2020 08:29AM

You can download aTalk project sources from

https://github.com/cmeng-git/atalk-android as mentioned in the first comment. The source is the latest release but without the externalNativeBuild {} block. You can just add them in to see the problem.

ABIs with abiFilters is only for ABI variants; aTalk has already specified this in jni/Application.mk.
The shortfall in my earlier comment is externalNativeBuild{} will proceed to build the filtered ABI's for every aTalk built variants e.g. fdroid.release, fdroid.debug, playstore.release, playstore.release; 4 times when aTalk perform aTalk | Tasks | build | build selected from the Gradle ToolBar

Message last modified on Nov 20, 2020 08:56AM

ap...@google.com <ap...@google.com> #10Nov 20, 2020 09:29AM

It's a current limitation that native builds cannot be shared across different variants. We are aware of this and would like to improve the situation. For now you may be able to workaround the problem by moving the native code into a separate module with a single variant and make the main module depending on it.

Could you elaborate what you mean by "a. user now has to define what ABI to build for the adb debug; previously no such option and it is auto selected."? What was your workflow for debugging? After using externalNativeBuild, how exactly do you define the ABI to build?

Regarding app crash after deployment, do you have the same problem with the Android emulator?

mk...@google.com <mk...@google.com> #11Nov 20, 2020 09:14PM

In the "Build Variants", when externalNativeBuild{} is enabled, there is now an extra i.e 'Active ABI' column for user selection. In old aTalk jni build method, there is no such column option.

In old jni method, the ABI selection is automatically defined by AS pending on targeted device for debug.
Does this mean, using the externalNativeBuild{} method. user now has to decide which ABI to use pending on targeted device for debug.

Is there a need for such option, as the release build will have to include all the ABI's native libraries?

mk...@google.com <mk...@google.com> Nov 23, 2020 06:46AM

Marked as fixed.

pa...@tomtom.com <pa...@tomtom.com> #12Nov 23, 2020 05:26PM

This option is for the code editor (for example ABI-specific macro expansion). It won't affect deployment. When you deploy to a device, the right ABI would be built regardless of what you select in the "Build Variant" window. Is this not the behavior you have seen?

sg...@google.com <sg...@google.com> Dec 2, 2020 08:20AM

Verified by mk...@google.com.