ms-intune-app-sdk-android icon indicating copy to clipboard operation
ms-intune-app-sdk-android copied to clipboard

Dynamic feature module's AppCompatActivity crashes due to unwanted transform exclusion caused by 'superclass androidx.core.app.ComponentActivity will not be processed'

Open JCreswellENVRMNT opened this issue 3 years ago • 8 comments

Describe the bug: I'm trying to add a dynamic feature module to an application that uses Intune, and every time I launch an AppCompatActivity subclass from the dynamic feature module I get the following crash:

2022-01-25 19:25:27.476 14431-14431/com.example.intunedynamicfeaturebug E/AndroidRuntime: FATAL EXCEPTION: main
    Process: com.example.intunedynamicfeaturebug, PID: 14431
    java.lang.LinkageError: Method void com.example.dynamicfeature.DynamicMainActivity.onCreate(android.os.Bundle) overrides final method in class Lcom/microsoft/intune/mam/client/app/MAMActivity; (declaration of 'com.example.dynamicfeature.DynamicMainActivity' appears in /data/data/com.example.intunedynamicfeaturebug/code_cache/.overlay/split_dynamicfeature.apk/classes3.dex)
        at java.lang.VMClassLoader.findLoadedClass(Native Method)
        at java.lang.ClassLoader.findLoadedClass(ClassLoader.java:738)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:363)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:312)
        at android.app.AppComponentFactory.instantiateActivity(AppComponentFactory.java:95)
        at androidx.core.app.CoreComponentFactory.instantiateActivity(CoreComponentFactory.java:45)
        at android.app.Instrumentation.newActivity(Instrumentation.java:1253)
        at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3671)
        at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3968)
        at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:85)
        at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135)
        at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95)
        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2307)
        at android.os.Handler.dispatchMessage(Handler.java:106)
        at android.os.Looper.loop(Looper.java:246)
        at android.app.ActivityThread.main(ActivityThread.java:8506)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:602)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1130)

Applying the Intune plugin also to the dynamic feature module itself gives me some insight in the form of the following build logs:

> Task :dynamicfeature:transformClassesWithMamifyTransformForDebug
Excluding com.example.dynamicfeature.DynamicMainActivity because superclass androidx.core.app.ComponentActivity will not be processed

Essentially it appears that Intune Mamify transform is failing because it refuses to process androidx.core.app.ComponentActivity, which is in the ancestry of AppCompatActivity, within a dynamic feature module. Mamify transform is able to transform AppCompatActivities without issue in application and library modules, and changing my dynamic feature Activity to subclass android.app.Activity also avoids the problem (but I need AppCompatActivity functionality, so this isn't a viable workaround).

To Reproduce Steps to reproduce the behavior:

  1. Create a new project and add Intune per the SDK integration docs https://docs.microsoft.com/en-us/mem/intune/developer/app-sdk-android
  2. Add a dynamic feature module to the project
  3. Request the dynamic feature at runtime and launch an AppCompatActivity subclass from it
  4. Observe Logcat for the error stack trace given above

A demo project reproducing this issue can be found at https://github.com/JCreswellENVRMNT/IntuneDynamicFeatureBug Uncomment the Intune references in dynamicfeature module's build.gradle (tagged with "todo: uncomment me to see unwanted transform exclusion caused by 'superclass androidx.core.app.ComponentActivity will not be processed'") to see the MamifyTransform task build log clue mentioned above.

Expected behavior: Intune should be able to transform AppCompatActivities regardless of the module type they reside in.

Smartphone (please complete the following information):

  • Device: Samsung Galaxy S20 Ultra 5G SM-G988U
  • OS: Android 11

Intune App SDK for Android (please complete the following information):

  • What version of the Intune SDK are you using? Are you using the latest version?
    • Intune SDK release 8.3.0, yes latest
  • What platform is your app based in (Java, Xamarin based, Cordova, etc)?
    • Kotlin, Java, C++ (native Android app SDK framework)
  • For errors during build, does the app build without Intune SDK integration?
    • N/A
  • For errors post build, does the app launch without being Intune SDK integrated?
    • Yes
  • Who is the customer?
    • N/A
  • Do you see a trend with it only being reproduced on a specific device?
    • No, same problem across several devices

JCreswellENVRMNT avatar Jan 26 '22 00:01 JCreswellENVRMNT

Curiously, I hit the same transformation failure when I use the CLI tool on a trivial AppCompatActivity subclass as follows:

C:\Users\jeffcreature\scrap_heap\mamification>BuildTool\bin\BuildToolCLI.bat --input source\classes.jar --output transformed\classes.jar --classpath BuildTool\mam_sdk_classes.jar;%ANDROID_SDK_ROOT%\platforms\android-31\android.jar;classpath\androidx_appcompat_classes.jar;classpath\androidx_fragment_classes.jar;classpath\androidx_activity_classes.jar;classpath\androidx_core_classes.jar --report transformed
Adding classpath C:\Users\jeffcreature\scrap_heap\mamification\classpath\androidx_fragment_classes.jar
Adding classpath C:\Users\jeffcreature\scrap_heap\mamification\BuildTool\mam_sdk_classes.jar
Adding classpath C:\Users\jeffcreature\scrap_heap\mamification\classpath\androidx_activity_classes.jar
Adding classpath C:\Users\jeffcreature\AppData\Local\Android\Sdk\platforms\android-31\android.jar
Adding classpath C:\Users\jeffcreature\scrap_heap\mamification\classpath\androidx_appcompat_classes.jar
Adding classpath C:\Users\jeffcreature\scrap_heap\mamification\classpath\androidx_core_classes.jar
Processing com.example.sandboxlib.BuildConfig
Processing com.example.sandboxlib.SandboxLibMainActivity
Excluding com.example.sandboxlib.SandboxLibMainActivity because superclass androidx.core.app.ComponentActivity will not be processed
Writing report.
Writing outputs
skipping non class file META-INF/sandboxlib_debug.kotlin_module
MAM transformation completed successfully.

So for some reason both dynamic feature module and CLI transforms run against AppCompatActivity seem to demonstrate this issue.

JCreswellENVRMNT avatar Jan 27 '22 02:01 JCreswellENVRMNT

Thank you for the detailed report. The demo project should allow us to reproduce this and investigate. We'll get back to you as soon as possible.

joakley-msft avatar Jan 27 '22 15:01 joakley-msft

Tracking internally as 13158133

joakley-msft avatar Jan 31 '22 23:01 joakley-msft

Hello, just checking in -- how's the investigation going?

JCreswellENVRMNT avatar Mar 02 '22 02:03 JCreswellENVRMNT

Hi, we have no updates to share at the moment, but we are still working towards a solution here.

bannus avatar Mar 04 '22 21:03 bannus

Checking in again; we're still blocked from using dynamic features by this issue

JCreswellENVRMNT avatar May 09 '22 17:05 JCreswellENVRMNT

Sorry, still no timeline to share currently.

bannus avatar May 11 '22 21:05 bannus

In looking for workaround to this problem, I was considering applying Intune to my library module directly so that the dynamic feature module variable would be removed from the equation; unfortunately, this led to the build error message "Transforms with scopes '[EXTERNAL_LIBRARIES, SUB_PROJECTS]' cannot be applied to library projects". Is there a way to apply Intune to a library module directly (no application module involved)?

We need to build the library module explicitly so that we get an output aar file from our Jenkins build job which can then be published to our maven repo; if we insert a dummy application module to get Intune applied correctly we wind up with just an output apk containing the raw dex files from the library module rather than a neatly packaged aar we can then publish. Technically we might be able to extract those dex files and manually repackage as an aar for publishing, but it would be much nicer if we could simply apply Intune to the library module build.

JCreswellENVRMNT avatar May 23 '22 17:05 JCreswellENVRMNT