In mobile test automation, Appium is a widely used tool for testing Android and iOS applications. It helps testers automate actions on various devices and environments. A key part of setting up Appium tests is correctly identifying the package and activity names of the Android app you want to test. These names serve as unique identifiers, helping Appium locate and launch the application on the device. Without this information, Appium can’t access the app, making the automation setup incomplete.

This is where the Android Debug Bridge, or ADB, comes in as a powerful tool in mobile automation. ADB allows testers to communicate directly with Android devices, enabling essential actions like retrieving package and activity details, monitoring system logs, and more. By using ADB commands, we can easily extract the exact package and activity names needed for Appium automation, simplifying the setup process and enhancing testing accuracy.

📌Understanding Package and Activity Names

When working with Android applications, especially in the context of automation, understanding package and activity names is crucial. These two elements act as the key identifiers for any Android app, guiding tools like Appium to locate, launch, and interact with specific app components.

What is a Package Name?

The package name serves as a unique identifier for every Android application. It’s assigned when the app is created, usually following a reverse domain name format (e.g., com.example.myapp). This identifier differentiates one app from another, much like a unique address.

For example:

• In the Facebook app, the package name could be com.facebook.katana.
• For WhatsApp, it’s com.whatsapp.

The package name is essential because:

1. It uniquely identifies an app on a device.
2. It’s used by the Google Play Store to manage listings, permissions, and updates.
3. It allows automation tools like Appium to target the correct app during testing.

What is an Activity Name?

An activity in Android is a screen or a component that allows user interaction. Each screen within an app is represented by an activity, and the activity name indicates which specific screen Appium should start with.

For instance, in a social media app, MainActivity might represent the home screen, while LoginActivity could be the login screen.

Activity names help Appium:

• Identify which screen to begin automation on.
• Bypass certain screens to start tests exactly where required.
• Simplify navigation and improve testing efficiency.

Example of Package and Activity Names in Appium

If we’re automating the login screen of a banking app with package com.bank.app and activity LoginActivity, we configure Appium like this:

Example code:

DesiredCapabilities capabilities = new DesiredCapabilities();

capabilities.SetCapability("appPackage", "com.bank.app");

capabilities.SetCapability("appActivity", "LoginActivity");

Here:

• appPackage tells Appium which app to open.
• appActivity directs Appium to start on the specified screen, optimizing the testing process.

How Package and Activity Names Help in Launching and Automating Apps Using Appium

In Appium, automation of Android apps requires specific “capabilities” to communicate with the app. Two of the most essential capabilities are the package name and activity name.

Importance of Package and Activity Names in Appium Automation

When automating an Android app, Appium requires information about the app’s location (package) and starting point (activity). Here’s how they help in launching and automating apps:

1. Launching the App: Appium uses the package name and activity name to launch the app. These names are passed as capabilities in the Appium Desired Capabilities configuration, which guides Appium on which app to open and where to begin interacting. For example, if we want Appium to open the main screen of an app, we would specify the package name of the app along with the main activity name. Without these, Appium wouldn’t know which app or screen to interact with.
2. Directing Appium to Specific Activities: Some apps require automation to begin on a different screen other than the main one, especially in cases like login screens or deep-linked pages. By specifying the package and a specific activity name, testers can guide Appium to launch right on that screen without needing to navigate through the entire app manually.
3. Simplifying and Speeding Up Testing: Since Appium can start testing from a specified activity, testers save time by bypassing unnecessary screens. For example, if an app has an onboarding flow but the tests require only the dashboard screen, specifying the activity name of the dashboard as the starting point helps to skip onboarding, making tests more efficient and faster.
4. Switching Between Activities: Some advanced automation flows require switching between different screens or sections of the app (activities). By configuring the package name and activity name, Appium can open new activities dynamically, allowing the tests to simulate real user journeys that go across multiple screens.

Prerequisites

To unlock the full capabilities of Appium , it’s essential to establish a well-configured test environment. Here’s a step-by-step guide to help you set it up effectively. 

For detailed instructions on Appium and Android Studio installation, refer to our blog on Appium Setup: A Step-by-Step Guide For Beginner

• Verify ADB Installation:
  • Open a Git Bash or CMDTerminal file and type:
    • adb version
  • If ADB is correctly installed, you should see its version number and details printed on the screen.

•  Verify Emulator Connection:
  • Run the adb devices command in your Git Bash file.
  • The emulator should appear in the list, identified as emulator-5554 or similar, with the status device.

Finding the Package Name Using ADB Commands

The package name is an essential identifier for Android applications. It uniquely identifies an app within the system, allowing Appium to locate, launch, and automate it. Using ADB (Android Debug Bridge) commands, testers can easily find the package name of any app installed on an Android device. This is particularly helpful for automating scenarios where the app must be launched directly or for setting up Appium’s Desired Capabilities.

Example Use Case: If you want to automate testing for the Google Chrome app on an Android device, you need to know its package name (com.android.chrome). Using ADB commands helps to identify this.

Commands to List Installed Packages on an Android Device

ADB provides a way to interact with a connected Android device, including listing all the installed applications. The following command will return a list of all packages installed on the device:

• adb shell pm list package

When you run this command, ADB connects to the device and lists each installed package in a format like this:

Each entry represents an app’s package name on the device. This command is useful when you don’t know the exact package name of an app you want to test.

Filtering Specific App Package Names

If you have many apps installed, the output of adb shell pm list packages can be overwhelming. To narrow down the results, you can use the | grep command to filter package names related to a specific keyword. This is especially useful when looking for a particular app without scrolling through a long list.

Example Commands and Outputs

Here are practical examples of using ADB commands:

Let’s say we want to find the package name for the saucelabs app. You can use these commands to filter it: either `adb shell pm list packages | findstr {appName}` or `adb shell pm list packages | grep saucelabs`.

Filtering by Keyword

To find a package with “saucelabs” in its name:

Finding the Main Activity Name Using ADB Commands

When automating mobile apps with tools like Appium, knowing the main activity name of the app is crucial. This activity serves as the app’s entry point and is required for launching it during testing. Below is a detailed guide on how to find the main activity name using ADB commands in CMD (Windows Command Prompt) or Bash (Linux/Mac).

1. Commands to Identify the Main Activity of an Android App

Steps to find Main Activity:

1. Launch the app manually on the device: Open the app you want to inspect on your device.
2. Find the currently active activity: Use the adb shell dumpsys activity activities command to retrieve activity information. This command outputs detailed information about the current state of activities on the device.
3. Hit this command  adb shell dumpsys activity activities in the Bash.

Once the app is launched on your device, use the following commands to retrieve the current package and activity:

You can use either CMD or Git Bash to execute the command. In CMD you have to use “adb shell dumpsys window | find “mCurrentFocus” and  in the GitBash You have to use “adb shell dumpsys window | grep “mCurrentFocus” command.

Output Example:

• Package Name: com.example.myapp
• Activity Name: com.example.myapp.MainActivity

Here’s the difference between grep and find:
The difference between grep and find lies in their functionality, platforms, and usage contexts. Here’s a detailed comparison:

1. Functionality

grep:

• Stands for Global Regular Expression Print.
• A powerful tool used to search for patterns within text files or output streams.
• Allows pattern matching using regular expressions.
• Commonly used in Unix/Linux environments, including Git Bash.

This searches for the string mCurrentFocus in the output stream from the adb shell dumpsys window command.

find:

• A simpler string-matching tool for searching text.
• Available by default in Windows CMD.
• Does not support advanced regular expressions, but it can locate exact matches in plain text or command output.

This searches for the string mCurrentFocus in the output stream of the adb shell dumpsys window command.

2. Platforms

Tool	Platform	Default Availability
grep	Unix/Linux, Git Bash	Available by default.
find	Windows CMD	Built into Windows CMD.

3. Key Differences

Feature	grep	find
Pattern Matching	Supports advanced patterns with regex.	Matches exact text only.
Case Sensitivity	Case-sensitive by default, but can be made case-insensitive using -i.	Case-insensitive by default in CMD.
Platform	Native to Linux/Unix; available in Git Bash.	Native to Windows CMD.
Speed	Faster with larger datasets due to optimized algorithms.	Suitable for simpler, smaller tasks.

Both tools serve a similar purpose but are adapted to their respective operating environments, making them effective in their own domains.

Combining Package and Activity Names for Appium Desired Capabilities

When automating Android apps with Appium, you must provide the package name and activity name in the desired capabilities configuration. These values are crucial for Appium to locate and launch the correct app and screen on the device.

1. Structuring the Information for Appium’s Desired Capabilities

Desired Capabilities in Appium are key-value pairs that define the automation session’s parameters. The two critical fields for Android app automation are:

• appPackage: Specifies the unique package name of the app.
• appActivity: Specifies the main activity or any activity to start the app.

You can combine the retrieved package and activity names into the desired capabilities to tell Appium which app and activity to automate.

Steps to Structure Information:

• Retrieve the package name using adb shell pm list packages or the mCurrentFocus command.
• Retrieve the main activity using adb shell dumpsys package or adb shell dumpsys window.
• Combine the appPackage and appActivity fields in your desired capabilities configuration.

  2. Example Configuration with Code Snippet

Here’s an example of combining the package and activity names in Appium’s configuration:

import io.appium.java_client.android.AndroidDriver;
import io.appium.java_client.remote.MobileCapabilityType;
import org.openqa.selenium.remote.DesiredCapabilities;

import java.net.URL;

public class AppiumTest {
    public static void main(String[] args) {
        try {
            // Set Desired Capabilities
            DesiredCapabilities capabilities = new DesiredCapabilities();
            capabilities .setCapability(MobileCapabilityType.PLATFORM_NAME, "Android");
            capabilities .setCapability(MobileCapabilityType.DEVICE_NAME, "emulator-5554"); // Or your device ID
            capabilities .setCapability("appPackage", "com.example.myapp");
            capabilities .setCapability("appActivity", "com.example.myapp.MainActivity");
            
            // Create Appium Driver
            AndroidDriver driver = new AndroidDriver(new URL("http://127.0.0.1:4723/wd/hub"), capabilities);
            
            // Perform actions on the app
            System.out.println("App launched successfully!");
            
            // Quit driver
            driver.quit();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

Here’s an explanation of the code:

• AndroidDriver: A specialized driver for Android-specific automation.
• MobileCapabilityType: Contains predefined constants for desired capabilities (e.g., platform name, device name).
• DesiredCapabilities: Used to specify the configuration for the automation session.
• URL: Used to define the Appium server’s address.
• The class AppiumTest defines the test logic.
• The main method is the program’s entry point, where execution begins.
• DesiredCapabilities is used to configure the automation session.

• PLATFORM_NAME: Specifies the platform (e.g., Android).
• DEVICE_NAME: Identifies the device (e.g., emulator-5554 for a default Android Emulator). For real devices, use their unique device name or ID.
• appPackage: The unique identifier of the app (e.g., com.example.myapp).
• appActivity: The activity to launch (e.g., com.example.myapp.MainActivity).

• Creates an AndroidDriver instance to establish a connection with the Appium server.
• The URL “http://127.0.0.1:4723/wd/hub” specifies the Appium server running on your local machine at port 4723.
• A message is printed to confirm that the app was launched successfully. In a real test, this is where you would add steps to interact with the app.
• driver.quit();, Terminates the Appium session and releases resources.
•  catch (Exception e) { e.printStackTrace();, if Any errors (e.g., invalid capabilities, connection issues) are caught and printed, helping in debugging.

Troubleshooting Common Issues

1. Issues with ADB Not Detecting Devices

When using ADB, one of the most common problems is the device not being detected. This can happen for several reasons, including driver issues, improper connections, or misconfigured settings.

Causes and Solutions

• USB Debugging Not Enabled:
  • Ensure “USB Debugging” is enabled on the Android device.
  • Navigate to Settings > About Phone > Tap Build Number 7 times to enable Developer Options, then go to Developer Options > Enable USB Debugging.
• Improper USB Connection:
  • Ensure the USB cable is properly connected and supports data transfer (not just charging).
  • Try a different USB port or cable to rule out hardware issues.
• ADB Drivers Not Installed (Windows):
  • If using Windows, ensure the appropriate USB drivers are installed for your device.
  • For universal support, install Google USB Drivers via the Android SDK Manager or download the drivers provided by your device manufacturer.
• ADB Daemon Not Running:
  • Restart the ADB server using below commands:
  • adb kill-server
  • adb start-server
  • adb devices
• Incorrect Device Authorization:
  • When you first connect a device, it prompts for authorization. If you missed it, reconnect the device and check the screen for an “Allow USB debugging?” dialog.

Validation:

• Run the command: adb devices

• If the device is listed with “unauthorized,” reauthorize it by unplugging and reconnecting the device and approving the prompt.
• If no device appears, ensure the above steps are followed.

2. Permissions and Access Errors When Finding Package or Activity Names

When using adb shell dumpsys commands, you may encounter errors due to insufficient permissions or app states.

Causes and Solutions

• App Not in Foreground:
  • Ensure the app you want to inspect is open and running in the foreground. The dumpsys window | grep mCurrentFocus command only retrieves information for the active app.
• Permission Denied Errors:
  • If you encounter “Permission Denied,” ensure the device is unlocked and not in a restricted state.
  • For devices with stricter permissions (e.g., some Samsung devices), ensure you have enabled all developer options and allowed USB debugging.
• ADB Command Fails:
  • Check the command syntax. For CMD, use find, and for Git Bash or Linux/macOS, use grep.
  • Example for CMD: adb shell dumpsys window | find “mCurrentFocus”
  • Example for Git Bash : adb shell dumpsys window | grep “mCurrentFocus”
• No Matching Output:
  • If no output is returned, it may mean the app isn’t running, or you used the wrong command. Retry after ensuring the app is active.

3. Steps to Resolve Common Issues

• Restart ADB:
  • Restart the ADB server to reset connections:
    adb kill-server
  • adb start-server
  • adb devices
• Reconnect the Device:
  • Unplug and reconnect the device. Ensure USB debugging is enabled.
• Update ADB:
  • Ensure you are using the latest version of ADB by updating the Android SDK tools.
• Reauthorize USB Debugging:
  • Revoke all previous USB debugging authorizations:
  • Navigate to Developer Options > Revoke USB Debugging Authorizations.
  • Reconnect the device and approve the new debugging prompt.
  • Use Correct Syntax:
    • Verify the correct command is being used based on the terminal (CMD vs. Git Bash).
• Enable Logs for Debugging:
  • Use verbose logging to identify issues:
    adb logcat
• Verify System PATH:
  • Ensure ADB is accessible globally by checking the system PATH variable. If ADB commands aren’t recognized, add its path to the environment variables.
• Restart the Device:
  • If all else fails, restart both the Android device and the system to resolve potential conflicts.

Best Practices

1. Regularly Updating ADB and SDK Tools

Keeping your ADB and SDK tools updated is crucial for maintaining compatibility with the latest Android versions, devices, and features. New updates often include bug fixes, performance improvements, and enhanced command functionality.

Benefits of Regular Updates:

• Improved Compatibility: Ensures ADB works seamlessly with the latest Android OS versions and devices.
• Access to New Features: Gain functionality that simplifies or enhances workflows, such as new debugging commands or faster file transfers.
• Stability and Security: Reduces the risk of encountering bugs, crashes, or vulnerabilities in older versions.

How to Update:

• Via Android Studio:
  • Open Android Studio and go to SDK Manager.
  • Update the SDK Platform Tools (which include ADB).
• Manually:
  • Download the latest version of Platform Tools from the official Android developer site.
  • Replace the old files with the new ones in the SDK directory.

2. Using Consistent Command-Line Tools Across Teams

Standardizing the command-line tools used by your team helps maintain consistency, avoids confusion, and reduces errors in scripts or workflows.

Why Standardization Matters:

• Uniform Commands: Different shells (e.g., CMD vs. Git Bash) may require slight syntax variations, which can lead to errors if not documented properly.
  • CMD: Use find instead of grep.
  • Git Bash/Linux/Mac: Use grep for similar functionality.
• Streamlined Onboarding: New team members can quickly adapt if everyone uses the same tools and configurations.
• Easier Debugging: A consistent environment reduces variability, making troubleshooting more efficient.

Recommendation:

• Choose a tool (CMD, Git Bash, or another shell) based on your team’s preferences and operating systems.
• If using multiple tools, document command variations explicitly in team guidelines

3. Documenting Discovered Package and Activity Names for Future Use

Maintaining a record of frequently used package and activity names simplifies future automation and reduces repetitive tasks. This practice is particularly valuable for teams managing multiple apps or switching between projects.

Benefits of Documentation:

• Reusability: Saves time when setting up new automation scripts.
• Error Reduction: Avoids inconsistencies caused by rediscovering or misrecording package and activity names.
• Team Collaboration: Ensures all team members have access to verified package and activity details.

How to Document:

Manual Repository:

• Maintain a shared spreadsheet or document containing:
  • App name
  • Package name
  • Main activity
  • Other relevant activities

Automated Approach:

• Use shell scripts or tools to extract and save the information directly into a file:
• adb shell dumpsys window | grep “mCurrentFocus” >> package_activity_log.txt

Best Practices for Documentation:

• Use a consistent format for recording data.
• Store the information in a shared repository (e.g., version control systems like Git or cloud platforms like Google Drive).
• Update the documentation whenever app versions or configurations change.

Conclusion

Identifying package and activity names is an essential aspect of automating Android applications using Appium. These unique identifiers enable Appium to precisely locate and interact with the target app and its specific screens, ensuring the reliability of test execution. Tools like ADB provide a straightforward method for extracting these details, making the setup process faster and more efficient for testers.

By integrating this information into Appium’s desired capabilities, testers can optimize their automation workflows, reduce setup complexities, and achieve greater accuracy in testing. Whether configuring tests or diagnosing issues, understanding and utilizing these techniques ensures a seamless and productive automation process, ultimately contributing to time and resource efficiency in mobile app testing.

Witness how our meticulous approach and cutting-edge solutions elevated quality and performance to new heights. Begin your journey into the world of software testing excellence. To know more refer to Tools & Technologies & QA Services.

If you would like to learn more about the awesome services we provide,  be sure to reach out.

Happy Testing 🙂