Post cover image

May 13, 2026

Setting Up My Mobile Application Testing Lab: What Worked, What Failed, and What I Learned

When I first started learning mobile application security testing, I honestly thought installing a few tools would be enough. I quickly…

Sumitdhavale

6 min read

When I first started learning mobile application security testing, I honestly thought installing a few tools would be enough. I quickly realized that mobile testing is much more than simply running APKs or intercepting requests. Building a proper testing lab itself became a learning journey.

In this blog, I'll explain how I set up my own mobile application testing lab, the mistakes I made, the difficulties I faced, why I moved from emulator-based testing to a rooted physical device, and the tools that helped me during the process.

This is not a "perfect setup" guide. It's a real experience-based walkthrough from someone learning mobile security practically.

Why I Started Building a Mobile Testing Lab

As I started exploring cybersecurity deeply — especially penetration testing and ethical hacking — I realized mobile applications are everywhere.

Banking apps, social media apps, e-commerce platforms, healthcare apps… almost everything today depends on mobile applications. That automatically makes them a huge target for attackers.

I wanted to learn:

  • APK analysis
  • Traffic interception
  • SSL pinning bypass
  • Runtime manipulation
  • Reverse engineering
  • API testing
  • Authentication testing

To do all this safely, I needed my own testing environment.

My Initial Setup

Initially, I started with:

  • A laptop with limited RAM
  • Parrot Security OS
  • VirtualBox
  • Android Emulator
  • Basic Android SDK tools

At first, I thought using an emulator would be the easiest option.

I was wrong.

My First Attempt: Android Emulator Setup

I installed:

  • Android Studio
  • Android SDK
  • Android Emulator
  • A virtual Android device

The setup itself was simple, but the real problem started when I tried running the emulator.

My laptop configuration wasn't strong enough.

The emulator became extremely slow:

  • Boot time was huge
  • Burp interception lagged
  • Dynamic analysis tools froze
  • CPU usage went very high
  • RAM consumption became insane

Sometimes the emulator crashed completely while running tools like:

  • Burp Suite
  • MobSF
  • Frida

That's when I realized many tutorials online assume everyone has high-end hardware. I didn't. So I had to find another approach.

What I Learned From Emulator Testing

Even though my emulator setup failed practically, I still learned important concepts.If your system supports virtualization properly, emulator testing is actually very useful.

How to Set Up an Android Emulator Properly

Step 1 — Install Android Studio

Android Studio Official Website

Install:

  • Android SDK
  • Platform Tools
  • Emulator packages

Step 2 — Enable Virtualization

This step is extremely important.

You need to enable:

  • Intel VT-x
  • AMD-V

from BIOS settings.

Without virtualization support, Android emulators become painfully slow.

Step 3 — Create Virtual Device

Inside Android Studio:

  1. Open Device Manager
  2. Create Virtual Device
  3. Select Pixel Device
  4. Choose Android Image
  5. Start Emulator

Recommended:

  • Android 11 image
  • x86 architecture for better speed

Step 4 — Root the Emulator

Most advanced testing requires root access.

One common method:

  • Use rooted emulator images
  • Or patch images manually using Magisk

Some people also use:

  • Genymotion
  • RootAVD
  • Magisk patched boot images

Why I Switched to a Real Device

After struggling with the emulator for days, I decided to use a physical Android phone.

I used a Realme smartphone device. Honestly, this decision made my learning much smoother.

A real device gave:

  • Better performance
  • Stable testing
  • More realistic behavior
  • Easier network interception

But rooting a real device came with its own headaches.

Rooting My Realme Device

Before rooting:

  • I backed up all data
  • Enabled Developer Options
  • Enabled OEM Unlocking
  • Enabled USB Debugging

Unlocking Bootloader

This part was stressful because different brands have different restrictions.

For Realme devices:

  1. Install Deep Testing application (if supported)
  2. Request bootloader unlock
  3. Reboot into Fastboot mode

Command used:

fastboot flashing unlock

This step mostly wipes device data.

That part scared me initially because one wrong step could soft-brick the phone.

Installing Magisk for Root Access

I used Magisk because it's one of the most widely used Android rooting tools.

Basic process:

  1. Extract boot.img from stock firmware
  2. Patch boot.img using Magisk app
  3. Transfer the patched file to the PC
  4. Flash patched image

Commands:

fastboot flash boot magisk_patched.img

Then reboot:

fastboot reboot

After rebooting, Magisk showed successful root access.

Honestly, seeing root access work for the first time felt satisfying after all the failed emulator attempts.

Problems I Faced While Rooting

I faced several issues:

  • Bootloop fear
  • Driver issues
  • Fastboot detection problems
  • Wrong firmware confusion
  • USB cable issues
  • SafetyNet detection
  • Root detection inside apps

Some apps instantly detected root access and refused to work.

That's where I started learning:

  • Root hiding
  • Zygisk
  • DenyList
  • Runtime hooking

This pushed me deeper into Android internals.

Setting Up Traffic Interception

Once my rooted device was ready, I configured traffic interception.

Tools used:

  • Burp Suite
  • Wi-Fi proxy configuration
  • Burp CA Certificate

Installing Burp Certificate

This step confused me initially. Modern Android versions don't trust user-installed certificates easily.

I had to:

  1. Export Burp certificate
  2. Install the certificate manually
  3. Move certificate into system store (root required)
  4. Restart device

Only then did HTTPS interception work properly.

SSL Pinning: The Biggest Roadblock

Almost every serious mobile application today uses SSL pinning.

Initially, I thought installing the Burp certificate was enough. It wasn't. Applications still refused interception.

That's when I learned about:

  • Frida
  • Objection

These tools became game changers.

Installing Frida Properly

One mistake I made initially was assuming Frida would work immediately after installation.

It didn't.

I kept getting:

  • version mismatch errors
  • device detection failures
  • architecture issues
  • server connection problems

After multiple failed attempts, I finally understood that both:

  • Frida tools on PC
  • Frida server on Android

must match properly.

Step 1 — Install Frida Tools on Linux

I installed Frida tools using pip:

pip install frida-tools

Verify installation:

frida --version

Step 2 — Download Frida Server

Frida Releases Page

This part is important. You must download the correct Frida server according to:

  • device architecture
  • Frida version

For example:

  • arm64
  • armeabi
  • x86
  • x86_64

My Realme device uses the arm64 architecture.

Step 3 — Push Frida Server to Android Device

Rename downloaded file:

mv frida-server-* frida-server

Push to device:

adb push frida-server /data/local/tmp/

Step 4 — Give Execution Permission

adb shell
su
chmod +x /data/local/tmp/frida-server

Step 5 — Start Frida Server

/data/local/tmp/frida-server &

Step 6 — Verify Connection

frida-ps -U

If everything works correctly, you'll see running applications from the device.

Honestly, this moment felt satisfying because I spent hours fixing version mismatch problems before finally getting Frida to connect properly.

Installing Objection

After learning basic Frida commands, I discovered Objection.

Objection made mobile testing much easier because it automates many Frida-based operations.

Installation was simple:

pip install objection

Verify installation:

objection --version

Using Objection for the First Time

To attach an objection to an application:

objection -g com.example.app explore

This opened an interactive shell where I could:

  • disable SSL pinning
  • inspect files
  • dump memory
  • bypass root detection
  • interact with app runtime

Some useful commands I experimented with:

android sslpinning disable
android root disable

At first, many commands failed because:

  • Frida wasn't stable
  • SELinux restrictions existed
  • The app architecture differed
  • Some apps had advanced protections

But slowly, I understood how mobile runtime instrumentation actually works internally.

That learning process was honestly more valuable than simply running automated commands.

Automated Tools That Helped Me

MobSF

MobSF

MobSF GitHub Repository

This tool honestly saved a lot of manual effort. MobSF helped me with:

  • Static analysis
  • APK permission review
  • Malware indicators
  • API extraction
  • Hardcoded secrets
  • Dynamic analysis

I used Docker installation:

git clone https://github.com/MobSF/Mobile-Security-Framework-MobSF.git
cd Mobile-Security-Framework-MobSF
docker compose up

Then opened:

http://localhost:8000

For beginners, MobSF is one of the best starting points.

Other Tools I Used

JADX

JADX

Used for:

  • Decompiled source code
  • Finding API endpoints
  • Understanding app logic

APKTool

APKTool

Used for:

  • APK decoding
  • Manifest analysis
  • Resource extraction

Wireshark

Wireshark

Useful during:

  • DNS analysis
  • Packet capture
  • Network troubleshooting

Biggest Lesson I Learned

One thing I learned during this journey:

Most cybersecurity learning looks smooth in tutorials but becomes messy in real environments.

Things break constantly.

Drivers fail. ADB stops working. Certificates don't install. Frida crashes. Emulators freeze. Apps detect root. SSL pinning blocks traffic.

But honestly, those problems taught me more than the successful steps.

My Advice for Beginners

If your laptop is powerful:

  • Start with emulator testing

If your system struggles:

  • Use a physical Android device carefully

And most importantly:

  • Don't get discouraged by failures

Mobile application testing requires patience because the setup itself is part of the learning process.

Final Thoughts

Building my mobile application testing lab was not a one-day task. It involved trial and error, failed attempts, debugging sessions, and many hours of searching documentation and forums.

But eventually, everything started making sense.

Today, I can:

  • Intercept application traffic
  • Perform APK analysis
  • Analyze runtime behavior
  • Test Android applications more confidently

And honestly, the failed emulator setup was probably the reason I learned Android internals much more deeply.

Sometimes failures teach more than successful installations ever could.

This blog was mainly about setting up my Mobile Application Testing Lab and explaining the real-world difficulties I faced while building it.

I wanted this to be realistic instead of pretending everything worked perfectly on the first try.

In my next blog, I'll start testing intentionally vulnerable Android applications like:

  • Damn Vulnerable Android App
  • InsecureBankv2

I'll cover:

  • APK analysis
  • Traffic interception
  • SSL pinning bypass
  • Runtime testing
  • Vulnerability discovery
  • API testing
  • Reverse engineering basics

The goal is to help both myself and readers gradually dive deeper into Mobile Application Security step by step, instead of getting overwhelmed at the beginning.

This setup was only the starting point.