Previously I wrote, . You can solve the problem radically, do not use an emulator, but test it directly on a mobile device running Android. I have an excellent HTC, and I set it up for it. So, in order to run applications on a physical device you need:

1. Enable USB debugging on your phone. You can do this by going to Settings -> Applications -> Development and checking the “USB Debugging” box.
2. Wait for the driver to install
3. Disconnect and reconnect your phone to your computer.

To check that the phone is visible to the computer, you need to do the following:

If this is the case for you, then you can use a special program: PdaNet. () It is usually used to use the Internet from a phone from a computer, but it just so happens that it contains a huge number of drivers for phones. During installation, I was asked for the device model, and then a beautiful red balloon popped up with a warning that the driver had not been tested, and everything could end badly, but no, everything was fine, it was installed. After that, I ran the check again (command above) and my phone appeared in the list of devices.

How to work from Eclipse? In fact, everything has already been done - we just launch the project and it opens on the phone.

Sandbox

Server God September 18, 2011 at 15:55

Overview of tools for launching and debugging applications on Android

• Lumber room *

While developing my first Android application, I encountered the problem of launching the application for testing and debugging. This article should help a novice user choose an emulation tool.

Android Virtual Device (AVD)

Installation:
This emulation tool is built into the Android SDK.

Setting:
(using an example of use in Eclipse)
Window > Android SDK and AVD Manager > New
We enter the name of the virtual device, platform, memory card size, display type...
Click Create AVD.

Launch:
The first launch of the emulator takes a very long time, especially on weak devices. For example, I couldn’t wait for the first launch on my netbook, and when I launched it for the first time on my computer, I was sure that the emulator had gone into an eternal loop.
Subsequent launches of the emulator will be a little faster.
The time between pressing the “Run” button and the appearance of the main activity of the test application on the emulator takes an average of 11 seconds. The measurements were carried out on a fairly powerful computer.

Advantages and disadvantages:
+ the ability to test the application on different versions Android OS, on devices with different types display...
+ various settings necessary for testing, for example, changing the screen orientation
+ SD card emulation
- a long period of time between pressing the “Run” button and launching the application on the emulator
- the emulator works very slowly, for example, what the phone processed in 1-2 seconds, the emulator did in 8-10 seconds

VirtualBox+Android x86

Installation and configuration:

1. Download and install VirtualBox.
2. Download the image.
3. “We create a Linux 2.6/Other Linux virtual machine, 512 Mb RAM, Bridged Network, HD 2 Gb, Disable Mouse Integration. Connecting ISO file and boot into one of the LiveCD options (there is an HDPI and MDPI option)” or follow these instructions.
4. Press Alt-F1 to exit to the console and type netcfg and remember the IP address of the emulator. To return to the GUI, press Alt-F7.
5. adb connect

Launch:
I didn’t record the time between pressing the “Run” button and the appearance of the main activity of the test application on the emulator, but, according to subjective feelings, this happens almost instantly.

Advantages and disadvantages:
+ a short period of time between pressing the “Run” button and launching the application on the emulator
+ quick work in places
- rather lengthy and sometimes problematic installation
- the emulator is slow in some places, there are problems with the image (especially on MDPI)
- problems with SD card emulation, changing screen orientation,...
- only two (three) versions of Android OS available and only two display types available

Android phone connected via USB

Installation and configuration:

1. We turn on debugging mode on the phone. (Settings > Applications > Development > USB Debugging).
2. Download the driver for your phone.
3. We connect the phone to the PC.
4. Installing drivers. The ADB Interface section should appear in Device Manager.
5. adb devices. If your phone does not appear in the list, then reinstall the ADB driver.

Launch:
About 5 seconds pass between pressing the “Run” button and the main activity of the test application appearing on the phone.

Advantages and disadvantages:
+ the ability to see the application as the user will see it (very important point, especially when creating the interface and design of the application)
+ multitouch (if your phone has it)
+ change screen orientation, accelerometer (if your phone has it)
- only one OS version and one display type
- another object will appear on the physical desktop

Conclusions:

I tried working with each of these emulation tools and settled on this option:
1. writing and testing an application using a phone;
2. testing the application on numerous Android Virtual Devices with various combinations OS version and display type.
I hope that the reader has chosen an emulator or learned something new for himself.
Good luck with your testing!

Decompilation and debugging of Android applications

Alexander Antipov

This article will show you how to attach a debugger to an Android application and step through the methods being called using the information obtained after decompiling the application.

This article will show you how to attach a debugger to an Android application and step through the methods being called using the information obtained after decompiling the application. The good news is that debugging does not require superuser privileges. The techniques described can be very useful during pentests. mobile applications, because we can "infiltrate" the code while the program is running, obtain and record information that we would not normally have access to. For example, you can intercept traffic before encryption and obtain keys, passwords and any other valuable information on the fly. The article will be useful to pentesters and mobile application developers who want to gain more in-depth knowledge about possible attacks on the Android platform.

Test environment requirements:

• Operating system: Windows / Mac OS X / Linux
• Java (version 1.7 recommended)
• IDE (Eclipse, IntelliJ IDEA, Android Studio)
• Android SDK (https://developer.android.com/sdk/index.html?hl=i)
• APKTool (https://code.google.com/p/android-apktool/)/APK Studio (http://apkstudio.codeplex.com)
• Android device/emulator

The following configuration will be used in this article: Windows 8, Android Studio and IntelliJ IDEA. Device: Nexus 4 with Android versions 4.4.4. I recommend adding all utilities to the PATH environment variable to make accessing these tools easier and faster.

The Android application package (APK) used in this article can be downloaded from here: com.netspi.egruber.test.apk .

Device setup

The instructions below will help you prepare the device for experiments.

Activating the Developer Options section

To begin with, USB debugging must be enabled on your Android device (USB debugging option), which will allow you to “communicate” with the device using tools from Android dial SDK. However, before this you need to activate the Developer options section. On your device, go to the Settings > About Phone section and click on the Build Number item several times, after which a message should appear stating that the Developer options section is activated.

Figure 1: In order to activate the Developer options section, you need to click on Build number several times

Enable USB Debugging

To enable debugging via the USB port, go to Settings > Developer options and check the box next to USB debugging.

Figure 2: Enabling the USB debugging option

Connecting the device and launching ADB

After connecting the device to the computer via a USB port, the message “USB debugging connected on the device” should appear. You should also check if you can connect to your device using the Android Debug Bridge (ADB) app included in the Android SDK (Android SDK Platform-tools). At the command prompt, enter the following command:

The device should appear in the list.

Figure 3: List of connected devices

If the device does not appear in the list, then the most likely reason is incorrect installed drivers(on Windows). Depending on the device, the driver can be found either in the Android SDK or on the manufacturer's website.

Checking the application for debugging

Before debugging Android applications, you first need to check if this is possible. The check can be performed in several ways.

The first way is to run Android Device Monitor, included in the Android SDK (in the tools folder). IN Windows file called monitor.bat. When you open Android Device Monitor, the device will appear in the Devices section.

Figure 4: Android Device Monitor Application

If any application on the device can be debugged, that application will also appear in the list. I created a test program, but the list is empty because the program cannot be debugged.

The second way to check if an application is debugable is to examine the AndroidManifest.xml file from the application package (APK, Android application package). The APK is a zip archive containing all the information needed to run the application on your Android device.

Whenever an application is loaded from Google Play Store, the application package is also downloaded. All downloaded APK files are usually stored on the device in the /data/app folder. If you do not have superuser rights, you will not be able to list files from the /data/app directory. Although, if you know the name of the APK file, you can copy it using the utility adb. To find out the name of the APK file, enter the following command:

will appear command line devices. Then enter the following command:

pm list packages -f

A list of all packages on the device is displayed.

Figure 5: List of packages on the device

Looking at the list, we find a test application.

Figure 6: Created test application package (highlighted in white)

Now you need to copy the package file. Open the shell and enter the following command:

adb pull /data/app/[.apk file]

Figure 7: Copying the APK file from the device to the system

Now you need to open the package file and examine the contents of AndroidManifest.xml. Unfortunately, we cannot simply extract the archive because the APK file is encoded in binary format. The utility most often used for decoding is apktool although I use APK Studio, since this application has a friendly graphical interface. The rest of the article will talk about APK Studio.

In APK Studio, click on the small green icon, name the project and specify the path to the APK file. Then specify let to save the project.

Figure 8: Creating a new project in APK Studio

After opening the APK, select the AndroidManifest.xml file and look at the application tag settings. If the android:debuggable flag is missing (or present but set to false), then the application cannot be debugged.

Figure 9: Contents of the AndroidManifest.xml file

Modifying the AndroidManifest.xml file

Using the apktool utility or APK Studio, we can modify the files and pack the contents back into the package. We will now modify the AndroidManifest.xml file so that the application can be debugged. Add the line android:debuggable="true" inside the application tag.

Figure 10: Changing the contents of the application tag

After adding the flag, click on the “hammer” icon and reassemble the package. The rebuilt package will be located in the build/apk directory.

Figure 11: Rebuilding the package completed successfully

After rebuilding, the package is signed and can be reinstalled on the device (all Android applications must be signed). Most applications do not verify the certificate used to sign. Otherwise, you need to change the code that performs this check.

Now you need to install the rebuilt package. First, delete the old application using the following command:

adb pm uninstall

Then install the new package:

adb install [.apk file]

You can also remove and install the package with one command:

adb install -r [.apk file]

Figure 12: Installing the rebuilt package

Check that the reinstalled application launches correctly on the device. If everything works, go back to Android Device Monitor, where the test application should appear.

Figure 13: The rebuilt application can now be debugged

Setting up the development environment (IDE)

Now you can attach a debugger to the rebuilt application, but first you need to create a project in the development environment (the article uses IntelliJ IDEA). Let's create a new project. In the Application name field, enter a custom name. In the Package name field, specify a name that exactly matches the folder hierarchy of the rebuilt package.

Figure 14: Creating a new project in IntelliJ IDEA

Typically the APK file name will match the folder structure, although if you are unsure, check the directory hierarchy in APK Studio down to the folder where the application files are located. In my case, the name and folder structure are exactly the same (com.netspi.egruber.test).

Figure 15: Test application directory hierarchy

Uncheck "Create Hello World Activity" and finish creating the project (all other options remain default). The new project should look something like this:

Figure 16: Hierarchy of folders and files of the new project

After creating the project you need to add source from the APK file so that the debugger “knows” the names of symbols, methods, variables, etc. The good news is that Android applications can be decompiled with virtually no loss of quality (the source code will be the same as the original). After decompilation, the source code is imported into the development environment (IDE).

Retrieving Sources from an Application Package

First, you need to convert the APK to a jar file. Then, using a java decompiler, we will obtain the source code of the application. We will do the conversion to jar using the utility dex2jar. dex2jar has a d2j-dex2jar.bat file which is used to convert APK to jar. The command syntax is quite simple:

d2j-dex2jar.bat [.apk file]

Figure 17: Converting APK to jar

Then open or drag the resulting file into the JD-GUI (this is a java decompiler).

Figure 18: Jar file structure

The jar file should appear as a hierarchical structure containing java files with readable source code. Go to File > Save All Sources to pack all the sources into a zip archive.

Figure 19: Saving the source texts of the decompiled file

After saving the source texts, unpack the archive into a separate directory.

Figure 20: Unpacked archive

Now you need to import both directories into the previously created project in the IDE. In IntelliJ, go to the src folder and copy the contents of the unpacked archive there (two directories).

Figure 21: Both folders are copied to the src directory

Returning to Intellij, we see the updated project.

Figure 22: Source texts appeared in the project

If we click on any element from the list, we will see the source text. As you can see in the screenshot below (source text of the LoginActivity class), the source code is obfuscated using ProGuard.

Figure 23: Obfuscated source text of the LoginActivity class

Connecting a debugger

Now that the project has source code, we can start setting breakpoints on methods and variables. When breakpoints are reached, the application will stop. As an example, I set a breakpoint on a method (right in the obfuscated code) responsible for processing information entered into a text field.

Figure 24: A breakpoint is set on an obfuscated method.

As soon as the breakpoint appears, connect the debugger to the process on the device by clicking on the screen icon in the upper right corner (the icon may differ on your IDE).

Figure 25: Connecting the debugger to the process

Figure 26: List of processes for connecting a debugger

After selecting the process, the debugger will connect to the device.

Figure 27: Debugger attached to a process running on the device

I will enter the number 42 into the text field (if you remember, there is a breakpoint on the corresponding method).

Figure 28: Enter the number 42 in the text field

After pressing the Enter Code button, the application will break at the breakpoint because the debugger is aware of which method is being called on the device. A compiled Android application contains debugging information (such as variable names) that is available to any Java Debug Wire Protocol (JDWP) compliant debugger. If your application has debugging enabled, a JDWP-compatible debugger (most debuggers included with Java development environments falls into this category) will be able to connect to virtual machine Android applications and then read and execute debugging commands.

Figure 29: Breakpoint hit

The screenshot below shows the number that we previously entered in the text field.

Figure 30: List of variables of the current class instance

Conclusion

We can not only read data in the application, but also insert our own. This can be useful if, for example, we want to interrupt the flow of code execution and bypass some parts of the algorithm. Using a debugger, we can better understand the logic of the application and analyze what is inaccessible to the average user. For example, viewing the encryption functions used and dynamic keys can be very useful. Also, sometimes when debugging it is useful to know how functions interact with file system or a database to understand what information is stored by the application. Similar manipulations are available on any Android device without superuser privileges.

At creating Android Most application developers use various emulators. This is convenient because you don’t need to store a bunch of different devices in desk drawers, there is no headache with connecting devices to the computer, and there are no heaps of wires on the desk. We click the mouse and see the work of our program on the computer screen. Simple and elegant. However, an emulator is not a phone. He is limited in his capabilities. If your application uses any specific hardware functions, such as those related to the camera, Bluetooth, or USB connection, work during reception phone call, with a high degree of probability we can say that you cannot do without debugging on a real device. Luckily, Eclipse contains everything you need to accomplish this task.

Connecting the phone and launching the program

Before you connect your phone to your computer using USB cable data transfer, several preparatory steps must be performed. The fact is that Eclipse is configured to work with an emulator by default, and we need to adjust the debug mode configuration. It's simple. Select the menu item Run > Debug Configuration, and then DroidDebug. On the Target tab, in the Deployment Target Selection Mode section, you need to set the switch to Manual and click Apply. Thus included manual mode choosing a platform. Now, when you launch the application, a dialog box will appear where you can select the emulator or one of the connected phones.

In order for the phone to work in debug mode, it also needs to be configured accordingly. While on home screen, you need to click on the Menu button and find the “Settings” application. In this application, open the “Applications” section, and then the “Development” item. In the screen that opens, you need to check the box next to “USB Debugging” (USD Debgging). This sequence of actions works on most phones, but it is quite possible that on your device the UBS debugging mode is enabled somewhere else.

Connect your phone to your computer and click the Debug button in Eclipse. In the dialog box that appears, you will see two lists: “Choose a running Android device” and “Launch a new Android Virtual Device”. The first of them lists phones connected to the computer, the second - emulators. Select your phone from the first list. Eclipse will install the application you are debugging on your phone and launch it. You can debug your program.

Phone status monitoring DDMS (Dalvik Debug Monitor Service)

All information about the phone's status is available through a special tool called the DDMS (Dalvik Debug Monitor Service) monitoring service. To launch it, click the android button in the top right corner of Eclipse.

The DDMS window consists of several panels. The Devices panel displays a list of available emulators and connected phones. Here is a list of those running in this moment processes. Each process runs in its own virtual machine. Threads are displayed on a separate Threads tab. The File Explorer tab is designed to work with the phone's file system. With it, you can copy files from your computer to your phone and back. Using the Screen Capture button, you can take a screenshot of your phone screen. The green bug button allows you to attach a debugger to the selected process. To use this feature, you must have the process open source.

Also worth noting is the LogCat logging utility and its corresponding panel, which can be very useful when searching for errors. Working with the log is carried out through a special class android.util.Log. The most commonly used methods are:

Log.e() - for logging errors,
Log.w() - for logging warnings,
Log.i() - for logging information messages,
Log.d() - for debug logging,
Log.v() - for logging detailed records,

These methods must be passed two strings as parameters. The first is a tag, which can then be used for searching and filtering in LogCat. The second is the actual information that is entered into the journal.

Last update: 03/09/2017

The standard project that was created in the previous topic already contains some functionality. True, this functionality does almost nothing, it just displays the string “Hello world!” on the screen.

Studio should have the activity_main.xml file open by default, which contains the application's GUI definition.

If the file is opened in designer mode, and the application design is displayed in the Android Studio center, then we need to switch the file view to text. To switch the mode - from text to graphic and back again, there are two buttons at the bottom, Design and Text.

Now let's change the application code so that it displays the string "Hello Android" on the screen. To do this, let's change the code in the activity_main.xml file, which now looks something like this:

Let's change the definition of the TextView element in this file, which is responsible for displaying text information on the screen of a mobile device. The output text itself is specified using the android:text attribute. Therefore, let's change all the code in the activity_main.xml file as follows:

After saving the file, we can switch to the graphical view and see that the graphical designer will automatically update and display the line we just defined.

Developer mode on the phone

We can use emulators or real devices to run and test the application. But ideally it is better to test on real devices.

For use mobile device To test, you need to install the driver on a working machine. If your smartphone is from Google - Nexus 5/6/5x/6P or Google Pixel, then to support it you need to install the Google Usb Driver package through SDK Manager. If the device manufacturer is another vendor, then you need to install the USB driver that is supplied by this vendor. If the OS is Windows 10, then, as a rule, the system itself can find the driver through the update center and install it.

By default, developer options on smartphones are hidden. To make them available, you need to go to Settings > About phone and press seven times Build Number.

Go back to the previous screen and there you will see an available option Developer options (For developer).

Let's move on to point For developers and enable USB debugging:

Launching the application

Let's connect a device with Android OS (if we are testing on a real device) and launch the project by clicking on the green arrow on the toolbar.

Then the construction of the project will begin. This process may take some time, after which a dialog box will be displayed to select a device to start. Here we can select a gadget connected to the computer or an emulator:

Select the device and click on the OK button. And after launch we will see our application on the device screen.