Android Studio: How to find the Package Name from APK

If you’ve been given an APK file but don’t know the ApplicationId/Package name, you can use the ‘aapt’ (Android Asset Packaging Tool) to obtain this value. What you’ll need:

  • Your Android SDK install directory path
    • Mac: /Users/yourusername/Library/Android/sdk
    • Win: C:\Program Files\Android\SDK
  • Your APK file (example here)

You’ll have to navigate beyond the SDK folder to the ‘build-tools’ and then your version number (see below) to find the ‘aapt’ tool. From that directory, you can run:

aapt dump badging <path to your apk>

This will dump the details of your app manifest, the first line of which is your package name (a.k.a. the ApplicationId in a build.gradle file).

Additionally, you can get a complete listing of the manifest by using:

aapt list -a <path to your apk>

Why Do I need the the Application ID / Package Name?

For various reasons, this identifier is important. For instance, debugging with the ADB command tools or launching an existing app requires this ID.

In my case, I needed to know what to add to a Perfecto test for the Espresso Execute test step:

I have to add the “.test” suffix to the package name coming from aapt because I need to tell the Perfecto Espresso executor to run tests.


Why Espresso: Unit vs. UI testing

This article differentiates unit tests, such as those written for jUnit, from UI tests in Espresso through both purpose and technical value.

What is Espresso?

Espresso is an automated UI testing framework for Android apps. They are scripts written in Java that simulate interactions with the app while it is running, either in an emulated environment or on a physical device.

Espresso tests are “instrumented”, which means that internal workings (context) about the app such as object names, runtime variables, and other symbolic information is made available to the tests. Using Android Debug Bridge (ADB) to provide runtime feedback between tools like Android Studio and the app as test activities are executed on the target device.

How is Espresso different than Unit Testing?

Unit tests focus on small portions of code (i.e. class-level methods) and provide basic validation that code is working as expected. Espresso tests provide basic validation that the UI is working as expected.

Early feedback from lots of tiny unit tests on each build help developers know when they just “broke” something by changing some other portion of code. Early means often, and often means that speed and reliability of these tests are crucial.

To that end, unit tests typically are hermetic and rely on stubs/mocks to stand in for dependencies. Antithetically, Espresso UI tests work through platform API which requires a runtime and device capabilities that are not faked. This provides more realistic feedback on code that might work at the unit level, but fails when chained together or during basic usability validations.

When should we write Unit Tests?

Always. You can figure out for yourself what total percent of lines of code are covered by unit tests, but this is a battle against low-level technical debt. How often do you want to be surprised when a change that seemingly had nothing to do with one piece of code breaks because expectations over what that code does weren’t spelled out in a way that could be exercised regularly?

That’s really what validation testing boils down to: are we communicating basic expectations about the things we’re about to ship? Unit is just at a very low level, but the same applies at the UI workflow level too.

When should we write UI tests?

Whenever you have a UI…that’s pretty obvious, right? People use an app, they don’t call your class methods in isolation with static data on emulators. Eventually you have to get real: simulate clicks, drags, gestures, network conditions, and platform upgrades because that’s how real people are using your user interface (a.k.a. your app).

How much UI testing you do is up to you, but it boils down to time cost. UI tests are often more complicated to write, though as we see with Espresso, a developer-focused syntax and fast execution speed goes a long way to reducing cultural friction to writing UI tests as part of “development complete”.

Sideline: API teams, you don’t get off so easily either. Your developer experience is your UI, the patterns by which your users call your endpoints, designed or otherwise, are equivalent to workflows. Equivalent to UI testing for app developers, holistic API tests that simulate known trends and expectations on your API will help you isolate breaking changes earlier and faster in your build cycles, it’s that simple.