As the documentation says, you can combine both Espresso and Compose in an Android instrumentation test. In order to interact with Compose in an instrumentation test you need a ComposeTestRule.

Problem

Typically you would create a ComposeTestRule with createComposeRule() in a part of your app that is compose only, but that will create a blank ComponentActivity and launch it showing a blank screen.

@get:Rule
val composeTestRule = createComposeRule()

This is great if you are looking to just use composeTestRule.setContent { Text("Hi")} in your test, but if you are integrating with an existing Espresso test, this will not be the case.

You could use the createAndroidComposeRule<MyActivity>(), however that will also use an ActivityTestRule underneath the hood and launch the Activity, which will change the behavior of your existing test. 🤔

@get:Rule
val composeTestRule = createAndroidComposeRule<MyActivity>()

Solution

If all you want to do is keep the Espresso test the same way it is, but also interact with some compose elements, use createEmptyComposeRule() and it will all work! 🎉

@get:Rule
val composeTestRule = createEmptyComposeRule()

Conclusion

Now you can interact with compose elements along with view elements, exactly like the documentation says. 😃

composeTestRule.onNodeWithText("Something").assertIsDisplayed()

Kotlin companion objects allow you to add static data and methods associated with a class. This is similar to how Java has static fields and methods. The problem is that Java doesn’t really know what a companion object it, so trying to access one using standard Java reflection might make you go crazy. 🤪

package com.handstandsam

/** This is contrived example of a companion object */
class SpecialFeature {
  companion object {
    var enabled: Boolean = false
  }
}

The decompiled Java class (created by the Kotlin Compiler) results in this:

package com.handstandsam;

import kotlin.Metadata;
import kotlin.jvm.internal.DefaultConstructorMarker;
import org.jetbrains.annotations.NotNull;

public final class SpecialFeature {
   private static boolean enabled;

   @NotNull
   public static final Companion Companion = new Companion((DefaultConstructorMarker)null);

   public static final class Companion {
      public final boolean getEnabled() {
         return SpecialFeature.enabled;
      }

      public final void setEnabled(boolean var1) {
         SpecialFeature.enabled = var1;
      }

      private Companion() {
      }

      public Companion(DefaultConstructorMarker $constructor_marker) {
         this();
      }
   }
}

The Kotlin Standard Lib for Java has a really cool method called companionObjectInstance that allows you to grab an instance of the declared companion object from the KClass object.

Why is companionObjectInstance helpful?

When Kotlin is compiled to Java Class files, the companion object has a fully qualified class name of com.handstandsam.SpecialFeature$Companion.

Mapping Kotlin -> Java Byte Code can make your head hurt, so by using this companionObjectInstance helper method, we don’t have to figure out how to get an instance of the companion object, or figure out the fully qualified class name.

val companionObjectJavaClass = com.handstandsam.SpecialFeature::class.java

val companionObjectInstance = companionObjectJavaClass.kotlin
        .companionObjectInstance!!

Now that we have an instance of the companion object class, and know the Java class, we can use reflection to set the value of the enabled property on the companion object.

companionObjectInstance::class.java
    .methods
    .first { it.name == "setEnabled" }
    .invoke(companionObjectInstance, true)

Note: setEnabled is the name, and it is a method here. You might expect this to just be a property which is what I assumed, but when compiled to java byte code, it is marked private and has a getter and a setter.

Bonus: Accessing private properties using Java Reflection

You could alternatively use Java reflection to change the backing private static boolean enabled field directly if you choose.

If you wanted to set the private static field value itself, rather than calling the setter, you can grab the declared field, and set it to accessible which allows us to bypass the private visibility. This sort of thing is why the JVM can’t be considered secure as it can be modified at runtime.

val privateEnabledField = SpecialFeature::class.java.getDeclaredField("enabled")
privateEnabledField.isAccessible=true
privateEnabledField.set(companionObjectInstance, true)

Conclusion

Reflection is powerful, but confusing. I could have probably done this cleaner JUST using Kotlin Reflect and not Java Reflection, but in my case I wanted to use Java Reflection, but needed to interact with a Kotlin companion object. There is a lot of documentation on how to mix Kotlin + Reflection, so feel free to read up more there. Cheers!

With new behaviors for apps using targetSdk=33 (Android 13) regarding Intents, it may be necessary to dive in and figure out how to make things compatible.

In doing this myself, I needed to figure out what was in the Intent, so I could handle it appropriately.

I started with this StackOverflow post, but ended up adding more info and doing it cleanly in Kotlin.

fun Intent?.toDebugString(): String {
    val intent = this ?: return ""
    return StringBuilder().apply {
        appendLine("--- Intent ---")
        appendLine("type: ${intent.type}")
        appendLine("package: ${intent.`package`}")
        appendLine("scheme: ${intent.scheme}")
        appendLine("component: ${intent.component}")
        appendLine("flags: ${intent.flags}")
        appendLine("categories: ${intent.categories}")
        appendLine("selector: ${intent.selector}")
        appendLine("action: ${intent.action}")
        appendLine("dataString: ${intent.dataString}")
        intent.extras?.keySet()?.forEach { key ->
            appendLine("* extra: $key=${intent.extras!![key]}")
        }
    }.toString()
}

Use the extension function above with println(myIntent.toDebugString()).

You can then filter Logcat with “System.out” and see the results! I hope this helps someone figure out what’s inside your Intents!

Permission Awareness

Knowing what you ship to your users is key, and permissions are one part of it. If you just look at your src/main/AndroidManifest.xml file, and think that’s all the permissions you will be shipping to the Play Store, you may find your self surprised that it may not be true. Applications can declare permissions, but 3rd party libraries and modules can declare them as well. Only the final, AndroidManifest.xml that has been generated via the manifest merging process is the source of truth.

In this article I share how the merged manifest is created, where you can find it, and a small Python script I created to parse the file and print out a list of permissions.

What is the “manifest merge” process?

There is a “manifest merge” process which takes all libraries and modules that your application relies on which ends up generating the final AndroidManifest.xml file. Merging the manifest is important because dependencies you rely on can bring in extra permissions you don’t define in your application yourself.

Where do I get my merged AndroidManifest.xml file?

Option 1: Grab the merged manifest from the build directory.

• Build your APK via Android Studio or the command line.
  • Example ./gradlew app:assembleRelease
• Locate your merged AndroidManifest.xml in the build directory: app/build/intermediates/merged_manifests/release/AndroidManifest.xml

Option 2: (You only have the APK, but didn’t build it yourself)

• Copy/paste the APK you have into Android Studio. Then open it, and view the AndroidManifest.xml. At that point, you can view it there, or copy out the contents to use with the script.
• Alternatively you can use something like apktool if you don’t have Android Studio.

How do I view all the permissions?

If you are looking to just see if a single permission has been declared, just search through the large AndroidManifest.xml file.

How do I create a permission report?

Sometimes it is nice to know what all your permissions are in a nice clean way. There are thousands of ways you could do this, but I created a python script that creates a clean alphabetized list of all your permissions.

Example Output

android.permission.ACCESS_NETWORK_STATE
android.permission.ACCESS_WIFI_STATE
android.permission.CAMERA
android.permission.FOREGROUND_SERVICE
android.permission.INTERNET
android.permission.VIBRATE

Instructions

• Download print_permissions_from_androidmanifest.py and place it in a directory.
• Open your APK in Andorid Studio (by double clicking on it in your build folder)
• Copy the contents of AndroidManifest.xml to the clipboard, and save it to a file named AndroidManifest.xml in the same directory as print_permissions_from_androidmanifest.py.
• Run python print_permissions_from_androidmanifest.py

Conclusion

It’s nice to cleanly see what permissions you are requesting when you send your app. There are probably better ways to do something like this, and if you know of some, I’ll be happy to link them in this post!

There isn’t a Kotlin Extension (KTX) library for Google Play’s InstallReferrer Library, so I wanted to share how I wrapped the API in a very Kotlin friendly way.

The Install Referrer API allows you to securely retrieve referral content from Google Play.  This can help you understand how you are acquiring new users in your app, and help you provide customized experiences tailored to where a user came from. For instance, if someone downloaded the app on a “New York” section of your website, you could open the “New York” section of the app on first app launch.

I hope this wrapper helps you!

https://gist.github.com/handstandsam/686a1bb551d0426b51dd612890f64986