If someone sends me an APK and says, “I think this app is malicious,” I would not install it on my phone to find out.
That sounds obvious, but it is an easy mistake to make when you are learning Android malware analysis. An APK is more than an application icon and a few screens. It contains code, configuration, permissions, resources, certificates, libraries and sometimes clues about where the application communicates.
A proper investigation starts with the APK as evidence and gradually builds an understanding of what the application is capable of doing and what it actually does.
This is the workflow I would follow.
Preserve the APK Before Opening It
The first thing I want is an untouched copy of the APK. I record where it came from, its filename, size and SHA-256 hash.
The reason is simple: once analysis begins, I want to be able to prove exactly which file I examined.
I also avoid running an unknown APK on my personal device. For practical analysis, an isolated Android emulator or dedicated test environment is much safer. OWASP also describes the Android Emulator as a useful environment for experimentation and dynamic analysis.
The Manifest Usually Gives Me the First Clues
My next stop is AndroidManifest.xml.
It is one of the most useful places to start because the manifest describes application components, permissions and important configuration. Android's documentation confirms that activities, services, broadcast receivers and content providers are declared there, along with permissions the application requires.
I don't simply count permissions and call an APK malicious.
Instead, I ask whether the requested access makes sense.
For example, a calculator asking for SMS, contacts, microphone and location would make me investigate further. But the permissions alone are not proof of malicious behaviour.
I also check exported components, debuggable settings, network configuration and SDK information. OWASP specifically identifies these as useful areas when examining an Android manifest.
Then I Open the APK
An APK is essentially a ZIP-based package, but simply unzipping it is not enough for serious analysis because important Android structures such as the binary manifest need decoding.
Tools such as Apktool are useful for decoding resources and examining Smali code. JADX can reconstruct Java-like code from DEX files, although its output is not guaranteed to reproduce the original source perfectly. OWASP recommends these tools as part of Android application analysis.
At this stage, I look through:
• classes.dex
• AndroidManifest.xml
• assets/
• res/
• lib/
• embedded strings
• certificates and package metadata
I pay particular attention to URLs, domains, suspicious API calls, hardcoded configuration and code that handles sensitive information.
Obfuscation can make this much harder. Meaningless class and method names do not necessarily indicate malware, but they can make manual analysis considerably more difficult.
Static Analysis Is Only Half the Story
At this point I have an idea of what the APK contains and what it appears capable of doing.
But there is an important difference between capability and behaviour.
That is where dynamic analysis comes in.
I run the application inside an isolated test environment and observe what happens. Depending on the investigation, this can include application logs, filesystem changes, processes, permissions requested during execution and network communication.
OWASP describes dynamic analysis as executing the application and examining its runtime behaviour.
One thing I have learned from this kind of analysis is that absence of suspicious behaviour during one test does not prove that nothing suspicious exists. Some functionality may depend on particular inputs, server responses or execution conditions.
Finally, Correlate the Evidence
This is where the investigation becomes much more interesting.
Suppose the manifest requests a sensitive permission. Static analysis finds code that accesses the corresponding Android API. During execution, the application contacts an unexpected domain and sends related data.
Those findings together tell a much stronger story than any one observation by itself.
That is how I prefer to approach APK investigations: don't hunt for one magical indicator. Build the explanation from several pieces of evidence.
The final report should clearly separate what was observed from what was inferred. Record the APK hash, tools used, important artifacts, screenshots or logs, network observations and the reasoning behind the final assessment.
A suspicious APK does not become malicious because it looks strange. The useful conclusion comes from showing what is inside it, what it can do, what it actually did, and how those findings connect.
