Exploring ADB Commands: A Comprehensive Guide for Developers, Testers and Android Enthusiasts 

Exploring ADB Commands: A Comprehensive Guide for Developers, Testers and Android Enthusiasts 

ADB (Android Debug Bridge) is an invaluable tool for developers, testers and Android enthusiasts alike. It allows you to interact with your Android device from a computer, opening new possibilities for application development and usability improvement. Explore ADB commands for android device manipulation in this blog.  

Android enthusiasts, developers and testers find ADB to be of great utility. It provides several features essential for managing devices and developing apps. 

ADB uses a command-line interface (CLI) to function. This implies that instead of interacting with it through a graphical user interface (GUI), you do it by typing instructions into a terminal or command prompt. 

ADB establishes a connection between your Android smartphone and PC. You can use your computer to control your gadget using this connection and use ADB Commands for Android Device interaction. 

Below are few of the benefits of using the ADB commands for Android Device Control

  • The tool makes it possible to do a variety of interactions with your Android device, which can be useful for both everyday use, development and testing. 
  • By enabling fast access to a device from a development environment, ADB helps developers to build and testers to test applications more efficiently. 
  • By providing access to more complex system capabilities, ADB can assist users in personalizing their devices or troubleshooting problems. 
  • ADB allows you to install apps straight from your development environment onto the device, saving you the trouble of manually moving them there. With the ability to perform diagnostic commands and retrieve error logs, it also aids in troubleshooting applications. 
  • System logs (logcat), which are essential for debugging apps and comprehending system events, can be retrieved by ADB. 
  • When you need to remotely manage a device or perform automated testing, it can mimic human activities like key presses and touch events. 

We’ll go over the most crucial ADB commands in this tutorial, along with their advantages and uses and explore ADB command for Android Device.

But before you start using the ADB commands to manipulate the Android device, you’ll first need to set up your device and computer to enable communication. 
 
Please refer to the Step 7 of the blog by Ajay Salunkhe on How to configure Windows Desktop for Android App Automation using Appium? 

Explore Following ADB Commands to manipulate Android Device

ADB Commands as below

Device Connectivity

Getting comprehensive details on your connected device is one of the most basic things you can do with ADB. For developers and testers who must comprehend the context in which their apps are operating, this is essential which can be achieved by executing the subsequent ADB command: 

This command displays a list of every device that is either networked or USB-connected to your computer. It provides a list of device serial numbers and their status, which can be  

1. “unauthorized” (meaning the device is connected but not authorized for ADB communication),  

2. “offline” (meaning the device is connected but not ready for commands), or  

3. “device” (meaning the device is connected and ready for commands). Making sure your device is correctly connected and prepared to communicate with ADB starts with doing this. 

Device Information

It is critical to understand the characteristics of your Android device. The following is a straightforward shell command that provides detailed information about the currently connected device. 

This command provides a list of exclusive device properties, including the phone number in store memory, the handle number for GSM radio standard communications, the operating system version, the device model, hardware details, and even kernel panics, if necessary. You can think of it as an inside perspective, opening a revealing window that can help identify problems and combine them with public report papers on security bugs to quickly ensure compatibility. 

Battery Power

Battery management is a crucial part of the app development and testing process. You can simulate different battery conditions and examine how your program behaves in response by setting the battery level using adb shell dumpsys. 

This command sets the battery level to 100%, but you can alter it to any percentage you wish. This is quite handy for evaluating your app’s response to low battery conditions, power saving settings, and charging state.

Bluetooth Enable

Many applications rely on Bluetooth capability, particularly those involving IoT devices, wearables, and music streaming. Use the following command to see if Bluetooth is enabled: 

A ‘1’ in the terminal response indicates Bluetooth is enabled, whereas a ‘0’ indicates Bluetooth is turned off. 

To turn on Bluetooth, use 

To turn off Bluetooth: 

Using these commands involves significantly less hardware labor when testing the Bluetooth functionality of your own software.

WiFi Control

Many apps require a Wi-Fi connection. To control the Wi-Fi status on your device, enter the following information: 

– Enable Wi-Fi: 

– Disable Wi-Fi: 

This is particularly handy when evaluating how your app functions without internet connectivity and providing different network situation simulations. 

Airplane Mode

When in airplane mode, all wireless connections are cut off, including Bluetooth, cellular, and Wi-Fi. You can use this to test the offline functionality of your app. Use these commands to switch between Airplane mode ON and Off: 

To enable Airplane mode: 

To disable Airplane mode: 

These commands help you test your app’s behavior in various connectivity scenarios.

Installing an App

Deploying your app to a physical device is a crucial step in development. To install an APK file on your device, use: 

Replace the ‘path-to-apk-file’ with the location of your APK file. This command simplifies the installation process across multiple devices, ensuring consistency.

Putting an App in the Background

Testing how your app behaves when sent to the background and brought back to the foreground is essential for a smooth user experience. To put an app in the background, use: 

The first command simulates pressing the home button, sending the app to the background. The second command brings up the recent apps screen, allowing you to simulate app switching.

Relaunching an App

To relaunch an app, use the `monkey` tool, which sends random events to the system. This is useful for stress testing and ensuring your app can handle unexpected inputs: 

Replace ` app-package ` with your app’s package name. This command launches the specified app, helping you automate the process of starting your app from a clean state.

Uninstalling an App

To uninstall an app from your device, use: 

Replace ` app-package` with the package name of the app you want to uninstall. This command is useful for cleaning up after tests and ensuring no residual data remains on the device.

Making a Call

For apps that interact with the phone’s calling capabilities, being able to initiate calls programmatically is important. To initiate a call from your device, use: 

Replace `1231231234` with the phone number you want to call. This command is useful for testing call-related features and interactions.

Rebooting the Device

Sometimes, a fresh start is needed. To reboot your device, simply use: 

This command restarts your device, ensuring it is in a clean state before starting tests or after making significant changes. 

Conclusion

These ADB instructions are but a sample of what may be accomplished using ADB by developers and testers. They undoubtedly offer a great deal of assistance with your work, including a better way to manage and debug native applications on your device and steps toward automation. These commands can be used in conjunction with your development and testing workflow to improve efficiency and ensure that, for example, an app’s behavior at various signal strengths is tested instantly. This eliminates the need for hours-long testing, which is particularly useful when a developer wants to upgrade or downgrade firmware based on how it will affect performance over varying time periods. This tool couldn’t be more powerful!  

Whether you’re a seasoned developer, tester or just starting out, ADB is the only tool you need with its many helpful commands that can handle anything from making the screen as bright or obscure as you like to completely changing the way Android can be used.  

Gaining control of these ADB commands will benefit you in a variety of testing and development situations, allowing your app to provide a seamless and enjoyable user experience. Thus, give them a go! I hope that learning about these commands will add a little bit of fun to your Android development and testing experience!  

Click here to read more blogs like this and learn new tricks and techniques of software testing.

Automate TOTP 2-Factor Authentication (2FA) with Playwright

Automate TOTP 2-Factor Authentication (2FA) with Playwright

Understanding 2FA Authenticator Apps and Time-based One-Time Passwords (TOTP)

2FA Login using TOTP: In an era where cybersecurity is paramount, two-factor authentication (2FA) has become a cornerstone of online security. Authenticator apps and Time-based One-Time Passwords (TOTP) offer an additional layer of protection beyond traditional password-based security measures. This guide aims to elucidate the concept of 2FA authenticator apps, delve into the workings of TOTP, and provide insights into their importance in digital security. 

2FA Authentication Image

What are 2FA Authenticator Apps?

Authenticator apps generate time-based one-time passwords (TOTPs) on mobile devices for authentication. They serve as a secure means of implementing 2FA, requiring users to provide both something they know (their password) and something they have (their mobile device with the authenticator app installed). 

How Do 2FA Authenticator Apps Work? 

How 2FA Authentication works
  1. Initialization: When setting up 2FA for an online account, users typically scan a QR code or manually enter a secret key provided by the service into their authenticator app. 
  1. Code Generation: Once initialized, the authenticator app generates TOTPs based on a shared secret key and the current time. These TOTPs are typically six-digit codes that change every 30 seconds. 
  1. Authentication: During login, users enter the current TOTP from their authenticator app along with their password. The service verifies the entered TOTP against the expected value based on the shared secret key. 

Time-based One-Time Passwords (TOTP): 

TOTP generates short-lived authentication codes using a shared secret key and the current time. The algorithm combines the secret key with the current time interval to produce a unique, one-time password that is valid only for a brief period, typically 30 seconds. TOTP ensures that even if an attacker intercepts a generated code, it quickly becomes obsolete, enhancing security. 

Importance of Authenticator Apps and TOTP: 

  1. Enhanced Security: Authenticator apps provide an additional layer of security beyond passwords, significantly reducing the risk of unauthorized access to online accounts. 
  1. Protection Against Phishing: Because TOTP codes generate locally on your device and change with time, they resist phishing attacks that aim at stealing static passwords.
  1. Convenience: Authenticator apps offer a convenient and user-friendly method of implementing 2FA, eliminating the need to rely on SMS-based authentication methods that may be vulnerable to SIM swapping attacks. 

Authenticator apps and Time-based One-Time Passwords (TOTP) play a crucial role in safeguarding online accounts against unauthorized access and cyber threats. By incorporating 2FA with authenticator apps into their security protocols, individuals and organizations can significantly enhance their digital security posture in an increasingly interconnected world. 

Now we need to set up the Authenticator App: 

Setup 2FA authenticator app 

Use a phone app like 1Password, Authy, LastPass Authenticator, or Microsoft Authenticator, etc. to get 2FA codes when prompted during sign-in.

Scan the QR code. 

Use an authenticator app from your phone to scan. If you are unable to scan, enter this text code instead.

The displayed QR code encodes the following information: 

otpauth://totp/<DOMAIN>/issuer:<USERNAME>?secret=<SECRET>

This encoded URL includes: 

  • The protocol (otpauth) signals that an authenticator app should open this URL (DOMAIN).
  • the type (totp) 
  • a label (USERNAME) that is a colon-separated combination of issuer and username 
  • a secret (SECRET) 
  • the issuer 

The key element for logging in and automating the TOTP process is the supplied secret. 

However, what’s the utilization method for this secret? 

When you scan the QR code with an authenticator app, it combines the secret with the current time to create a unique password. The app then stores the second-factor secret, shows the issuer and username, and generates a new passcode every 30 seconds (though this time frame can be changed).That’s the gist of it! 

You can then employ the passcode as a secondary login factor, providing assurance to services that it is indeed you are accessing your account. 

Automating Login with Playwright for 2FA-Secured Websites

Automating the login process for websites secured with two-factor authentication (2FA) can streamline testing and administrative tasks. Playwright, a powerful automation library, provides the tools necessary to automate interactions with web pages, including those requiring 2FA. 

Prerequisites: 

  1. Install Node.js: Make sure Node.js is installed on your system. You can download it from nodejs.org
  1. Set Up Playwright: Install Playwright using npm, the Node.js package manager, by running the following command in your terminal: 

Steps to Automate Login with Playwright: 

  • Launch a Browser Instance:
  • Navigate to the Login Page:
  • Enter Username and Password:
  • Click on the Login Button:
  • Handle 2FA Authentication:

Playwright supports interacting with elements on the page to handle 2FA. You can wait for the 2FA input field to appear and then fill it with the code. 

The new OTPAuth.TOTP() syntax indicates that an instance of the TOTP class from the OTPAuth library is being created.  

This instance is configured with various parameters such as issuer, label, algorithm, digits, period, and secret, which are used to generate and validate one-time passwords for authentication purposes. 

In essence, new OTPAuth.TOTP() initializes a new TOTP (Time-based One-Time Password) object, allowing the application to generate OTPs for user authentication. 

  • Fill and Submit the 2FA code:

 totp.generate() is a method call on the totp object. This method is provided by the OTPAuth library and is used to generate a one-time password (OTP) based on the TOTP algorithm. 

The generate() method computes the current OTP value based on the TOTP parameters configured earlier, such as the secret key, time period, and algorithm. This OTP is typically used for user authentication purposes. 

Once token holds the generated OTP, it can be used in the subsequent lines of code for filling an authentication code input field and submitting it for authentication. 

Here’s the final code.

Conclusion:

Automating login for 2FA-secured websites using Playwright can enhance efficiency and productivity in various scenarios, from testing to administrative tasks. By following the steps outlined above, you can create robust automation scripts tailored to your specific requirements. 
https://github.com/apurvakolse/playwright-typescript-totp

Feel free to customize and expand upon these steps to suit your needs and the specific requirements of the website you’re working with. 

Disclaimer: Ensure that you have the necessary permissions to automate interactions with websites, and use this knowledge responsibly and ethically. 

Click Here to read more blogs for Software Testing Tips and Practices.

What are Reviews in Software Testing and why are they Important?

What are Reviews in Software Testing and why are they Important?

Static testing and dynamic testing are two essential approaches in software testing. While dynamic testing involves software execution, static testing examines work products, such as code or documentation, without execution. Static testing includes two methods: manual examination, where team members review work products to identify issues, and tool-driven evaluation, where specialized software tools perform static analysis.

Static testing is a critical technique as it can identify errors and defects in the software development lifecycle before software execution takes place. This can save time and resources by catching issues early, leading to improved software quality. Static testing also helps in improving the maintainability of the software and reducing the cost of testing by identifying issues early on. By detecting defects early, static testing can enhance the efficiency and effectiveness of the entire software development process.

What are Reviews in Software Testing:

In software testing, a review is a process of examining a software product or component by a group of individuals to detect defects, errors, or vulnerabilities. The primary goal of reviews is to identify and fix issues in the early stages of the software development life cycle to save time and cost.

Reviews play a crucial role in the software development process. It identifies and addresses errors and issues before they become problematic. Reviews can be informal or formal, depending on the level of rigor and structure involved.

Informal reviews are often less structured and involve team members informally reviewing code or other work products and discussing issues. On the other hand, formal reviews are more structured, involving documented procedures, and a diverse team with varied roles and perspectives, making them comprehensive.

Formal reviews typically produce documented results, including any issues identified and how they were resolved. This documentation is useful for tracking progress, ensuring accountability, and improving future reviews’ quality. Overall, reviews are essential to the software development process as they ensure the software is of high quality and meets the desired requirements.

Reasons why Reviews are Important:

  • First, they improve the quality of the software product or component by identifying and resolving defects early in the development process, preventing issues from reaching end-users, leading to enhanced customer satisfaction and reduced support requests.
  • Second, reviews reduce the overall cost and time of the software development project by catching defects early, saving time, and resources that would otherwise be needed to address issues in later stages of the development cycle.
  • Third, they provide an opportunity for knowledge sharing and collaboration among team members, promoting best practices and fostering improved teamwork and productivity.
  • Fourth, they ensure compliance with regulatory and industry standards by identifying issues that may be in violation of regulatory requirements or industry standards, allowing for corrective action to be taken before the product is released.

ISO/IEC 20246 is an internationally recognized standard that provides detailed guidelines for conducting reviews of work products during the software development process. The standard outlines team member roles and responsibilities and offers a range of review techniques to choose from, making the review process more efficient and effective.

The work product review process involves several main activities:

Planning :

During the planning phase, the following activities are performed:

  • Defining the scope
  • Estimating effort and timeframe
  • Identifying review characteristics
  • Selecting the people to participate in the review and allocating roles
  • Defining entry and exit criteria

Initiating the review:

During the initial review phase, the following activities are performed:

  • Distributing the work product and related material
  • Explaining the scope, objectives, process, roles, and work products to the participants
  • Answering any questions that participants may have about the review

Individual review:

During the individual review phase, participants perform the following activities:

  • Reviewing all or part of the work product
  • Noting potential defects, recommendations, and questions

Issue communication and analysis:

During the issue communication and analysis phase, the following activities are performed:

  • Communicating identified potential defects
  • Analyzing potential defects and assigning ownership and status to them
  • Evaluating and documenting quality characteristics
  • Evaluating the review findings against the exit criteria to make a review decision

 Fixing and reporting:

During the fixing and reporting phase, the following activities are performed:

  • Creating defect reports for findings that require changes to a work product
  • Fixing defects found in the work product reviewed
  • Communicating defects to the appropriate person or team and recording the updated status of defects
  • Gathering metrics
  • Checking those exit criteria are met
  • Accepting the work product when the exit criteria are reached

In a formal review, there are several roles and responsibilities that are typically assigned to participants.

Roles and Responsibilities:

  • Moderator/Chairperson: Responsible for conducting the review meeting. It ensures that the review is conducted according to the review process, and ensures that the review objectives are met.
  • Author: The person who wrote the work product being reviewed.
  • Reviewer: A person who is responsible for reading and analyzing the work product being reviewed and identifying any defects, issues, or potential improvements.
  • Recorder/Scribe: Responsible for recording the minutes of the review meeting and documenting the issues raised, the decisions made, and any action items assigned.
  • Manager: A person who is responsible for managing the review process and ensuring that the review is conducted effectively.
  • Quality Assurance Representative: Responsible for ensuring that the review process is in compliance with organizational quality standards and procedures.
  • Technical Expert: A person who has expertise in the subject matter being reviewed. Also, the person who can provide technical advice and guidance during the review process.

Each of these roles has specific responsibilities and tasks that are assigned to them during the review process. So to ensure a successful review, it is crucial to clearly communicate the roles, responsibilities, processes, and objectives to each participant. This will ensure everyone is aligned and comprehends their expected roles during the review.

Types of reviews include:

Additionally, there are several types of reviews that can be conducted during the software development lifecycle

  • Peer Review: A review of a work product involves one or more peers with comparable expertise and authority level.
  • Technical Review: A review that focuses on the technical aspects of a work product, such as design, code, or architecture.
  • Walkthrough: A review that involves the author of the work product presenting the work product to a group of reviewers, who ask questions and provide feedback.
  • Inspection: A highly formal and structured review that involves a team of reviewers examining a work product in detail to identify defects and potential improvements.
  • Audit: A review that focuses on ensuring compliance with standards, regulations, or policies.
  • Management Review: A review that is conducted by management to ensure that the project or work product is progressing as planned and to identify any potential issues or risks.

Review type choice depends on factors like work product nature, review goals, and available resources.

Conclusion:

Reviews are a critical component of the software development lifecycle. By tapping into the collective knowledge and expertise of team members, reviews enable the early identification of defects and potential improvements, leading to improved software quality and reduced costs and time. Furthermore, reviews facilitate communication and collaboration among team members, fostering a culture of continuous improvement and knowledge sharing.

In addition, reviews help organizations to comply with regulatory and industry standards, thereby mitigating risks and maintaining the trust of their stakeholders. Overall, reviews are a valuable tool for any software development team aiming to deliver high-quality software products efficiently and effectively.

Read more blogs here

How to Skip Authentication in test automation using Playwright

How to Skip Authentication in test automation using Playwright

Every software application identifies, recognizes, and authenticates the user trying to access the system using some type of credentials (i.e Username and password). And once the user is verified/authenticated, that user is granted permission to access authorized resources.

So, while testing the software application for every test case, the first step we perform is the login step.

If the test suite consists of 100+ test cases, then the step of logging in to the application will be performed for each test case. You can imagine the unnecessary time that will consume for logging in to the application each time for all those 100+ test cases.

Can we find a way to reduce the time required for logging in to the application for every test case? or can we skip logging in to the software application altogether?

This is where Playwright comes into the picture.

The playwright is an open-source test automation tool created by Microsoft. It is a cross-platform tool and has a set of features like Test Generator (codegen), Trace viewer, Inspector, etc, and the most important feature of Playwright which will help us to skip authentication in test automation is full isolation with browser context.

In addition, you can refer to the official document on playwright basic authentication.

First Off, we will have to login into the application via UI and reuse the authentication state in different and multiple scenarios using the browser context.

Let’s see how we can do it.

First, we are going to create a GenerateSession.java class where all of our own logical and automated login steps will be implemented,

Code:

import com.microsoft.playwright.*;
import java.nio.file.Paths;
public class GenerateSession {

        Playwright playwright = Playwright.create();
        Browser browser = playwright.chromium().launch(new      BrowserType.LaunchOptions().setHeadless(false));
        BrowserContext browserContext = browser.newContext();

        Page page = browserContext.newPage();
        page.navigate(BASE URL);
        page.fill("//*[@id=\"username\"]",USERNAME);
        page.fill("//*[@id=\"password\"]",PASSWORD);
        page.click("//*[@id=\"Login\"]");

So, what we did here is, launched the browser and created a new page.

In BrowserContext browserContext = browser.newContext();
we have created a browser context. This browserContext will store our authentication state i.e it will store the session, cookies, local storage, etc.

As you can see, we created the browser context browserContext, but the question here is, where will this authentication state (browserContex) will be stored?

The best way to store this browser context in a .json file.

The playwright provides a method called storageState() which will help us store the authentication state.

browserContext.storageState(new BrowserContext.StorageStateOptions().setPath(Paths.get("appLoginInfo.json")));

The above code snippet will store the authentication state, cookies, local storage, etc in json format in appLoginInfo.json file.

If the appLoginInfo.json file is not created then the playwright will create a new file with the provided name appLoginInfo.json at the provided location in setPath(Paths.get(“appLoginInfo.json”)));

If you have the appLoginInfo.json file already created, each time you execute the above snippet, a new authentication state with cookies and local storage will be overwritten in the appLoginInfo.json file.

Now, we are all set up with our authentication state, cookies, and local storage. Our next question is

How do we use that authentication state and skip login for each scenario?

We can use a Playwright to skip authentication scenarios. As we all know, Web applications use cookies and token-based authentications. These authentications are stored in the form of cookies or local storage. The playwright provides us with methods that can store these authentication state and then create a new browser context with the previously restored session, which in turn help us skip login/authentication for the scenarios.

Here, we will set the stored authentication state using the methods above to the new browser context created for each scenario we run.

The playwright provides us with a method newContext()  which will create a new browser context.

And by using NewContextOptions(), we can add/set the stored authentication state in the appLoginInfo.json file.

Let’s look at how we can do it in the code snippet below.

BrowserContext brContext = browser.newContext(new Browser.NewContextOptions().

setStorageStatePath(Paths.get("appLoginInfo.json")));

Here, setStorageStatePath(Paths.get(“appLoginInfo.json”))will set the authentication state stored in appLoginInfo.json to the new browser context created in the previous step.

So, every time we execute the above code snippet, the browser context that is stored in appLoginInfo.json file will be set to the new browser context and the previous session will be restored.

Please refer to the methods listed below. I used these methods to skip authentication scenarios for one of the Salesforce apps.

        @Test
        public void generateSessionCookies() throws InterruptedException {
        Playwright playwright = Playwright.create();
        Browser browser = playwright.chromium().launch(new BrowserType.LaunchOptions().setHeadless(false));
        BrowserContext browserContext = browser.newContext();
        Page page = browserContext.newPage();
        page.navigate("BASE URL");
        page.fill("//*[@id=\"username\"]", "USERNAME");
        page.fill("//*[@id=\"password\"]", "PASSWORD");
        page.click("//*[@id=\"Login\"]");
        page.click("//*[@id=\"save\"]");
        browserContext.storageState(new BrowserContext.StorageStateOptions().setPath(Paths.get("appLoginInfo.json")));
        page.close();
}
         @Test
         public void useSavedSessionCookies() throws InterruptedException {
         Playwright playwright = Playwright.create();
         Browser browser = playwright.chromium().launch(new BrowserType.LaunchOptions().setHeadless(false));
         BrowserContext browserContext = browser.newContext();
         Page page = browserContext.newPage();
         browserContext.storageState(new BrowserContext.StorageStateOptions().setPath(Paths.get("appLoginInfo.json")));
         page.close();
}

Conclusion:

In this way, Playwright helps us to store the authentication state, cookies, local storage, etc. And we can use this authentication state and set it to our new browser context and restore the previous session, which will in turn help us skip the login step for the n number of scenarios for a software application.

I hope this article has served you well. 

Read more blogs here