java.lang.ClassNotFoundException: android.app.Application$ActivityLifecycleCallbacks$-CC

[EliteTK]

I've been struggling with this since yesterday.

I've been putting together an incremental redo based build system for a couple of weeks and have hit upon this error which appears to happen with the bare-bones res-androidx and src-kt setup.

I am using:

• javac --version: javac 17.0.5
• kotlinc -version: info: kotlinc-jvm 1.7.0 (JRE 17.0.5+7-void-r2)
• platform-33-ext5_r01.zip
• build-tools_r33.0.2-linux.zip

The only changes to the template outside of that are shown below:

diff -u /home/tk/src/tiny-android-template/includes.sh ./includes.sh
--- /home/tk/src/tiny-android-template/includes.sh  2023-04-12 17:33:03.831575803 +0100
+++ ./includes.sh   2023-04-20 10:52:49.850113866 +0100
@@ -3,19 +3,19 @@

 HOST_OS="linux-x86_64"
 API_LEVEL="30"
-ANDROID_VERSION="11"
+ANDROID_VERSION="13"
 NDK_VERSION="r23-beta4"
 TARGET_ARCHES=( "arm64-v8a" )
 SDK_DIR="../Sdk"
-KOTLIN_LIB_DIR="/usr/share/kotlin/lib"
+KOTLIN_LIB_DIR="/usr/share/kotlin-bin/lib"

 REPO="https://dl.google.com/dl/android/maven2"

-KEYSTORE="keystore.jks"
-KS_PASS="123456"
+KEYSTORE="/home/tk/.android/debug.keystore"
+KS_PASS="android"

 TOOLS_DIR="$SDK_DIR/android-$ANDROID_VERSION"
-PLATFORM_DIR="$SDK_DIR/android-$ANDROID_VERSION"
+PLATFORM_DIR="$SDK_DIR/android-33-ext5"

 NDK_DIR="$SDK_DIR/android-ndk-$NDK_VERSION"
 NDK_BIN_DIR="$NDK_DIR/toolchains/llvm/prebuilt/$HOST_OS/bin"
@@ -41,5 +41,5 @@
 CMD_JAVAC="javac"
 CMD_KOTLINC="kotlinc"

-CMD_ADB="$SDK_DIR/platform-tools/adb"
+CMD_ADB="adb"
 CMD_D8="$CMD_JAVA -Xmx1024M -Xss1m -cp $TOOLS_DIR/lib/d8.jar com.android.tools.r8.D8"

I ran the scripts in this order:

• kotlin-pre.sh
• get-packages.sh pkg-list.txt
• export-libs.pl
• link.pl
• make.sh
• run.sh

The "$-CC" bit seems to be dex related, but there's so little information on this that I feel kind of lost.

I noticed that this template doesn't use R8 but I am unsure if that's now required.

Is it possibly the android version or build-tools version which is the problem? If so, is there any known good build tools version which I should specifically use?

Any help is appreciated.

I also understand that this might not be an issue with this particular template and might instead be something on my end, but again, any help would be appreciated.

[EliteTK]

Okay, so after some more looking around, I have deduced a few things:

This issue appears with platform-29 and above, and appears to relate to https://developer.android.com/sdk/api_diff/29/changes/android.app.Application.ActivityLifecycleCallbacks and also affects both the kotlin and java versions of this template when using androidx. Specifically it is caused by having the main activity inherit from ComponentActivity.

Still not really sure what's causing this but have been able to successfully work around by using platform-28 for now.

[jbendtsen]

Yeah, I seem to remember it had something to do with that interface being filled with "default" methods which weren't being compiled properly for some reason. I think if you implement those methods with stubs it should work.

[jbendtsen]

Taking another look, there were a bunch of methods added to this interface in API 29. I believe that's what the diff shows. What's likely happening is that the compiled AndroidX classes that are listed in pkg-list.txt and subsequently downloaded by get-packages.sh are out of date, and are compiled against an older version of the Android API. This would mean ComponentActivity only implements a subset of ActivityLifecycleCallbacks, specifically the subset that used to be the complete set in the older API. The fix here would be updating pkg-list.txt to contain the latest versions of AndroidX packages, and add any dependencies that have since been inducted into AndroidX. Here's a list of the latest AndroidX package versions: https://developer.android.com/jetpack/androidx/versions

[jbendtsen]

Turns out that wasn't the issue. Taking a look at the latest AndroidX activity launcher, specifically the part which triggers this issue, it appears that it's trying to invoke the method onActivityPreStarted which is marked as "default" on the original interface. This should be fine in theory, since default methods are simply methods that don't need to be overridden since they are specified to do nothing by default. However, this may be causing issues in the D8 linker. CC is the suffix given to default methods, as mentioned here.