Static analysis studies an app without running it on a device during the test session. It reads decoded code and resources and the manifest and native libraries in a project folder. Dynamic analysis studies an app while it runs on a test device with live input and live data. It watches network traffic and file writes and logs and screen flow during a session. Each method answers different questions about an app for a security reviewer. Static analysis finds code that a live test might never reach during a normal run. Dynamic analysis finds behaviour that static code reading might miss due to complexity. Strong security work uses both methods together in a planned order for a question. For a static tool that starts this work see decompiling APK files with APKTool.
Choosing between static and dynamic work starts with the question that needs an answer during review. A question about a permission needs a manifest review first in static work. A question about a network leak needs a proxy log first in dynamic work. A question about a hidden feature needs both methods in sequence for a full answer. Static work points to places worth testing live on a test device. Dynamic work confirms or corrects the static guess with real behaviour. That loop between methods is the core of good security analysis for Android apps. Analysts should plan that loop before opening any tool for a new project.
Strengths Of Static Analysis
Static analysis covers an entire app package in one pass without needing a test device for the work. It can read every class and every method in a decoded app folder during a session. It can find dead code that no live test would ever trigger during normal use. It can find hard coded secrets that appear as strings in code or in resources. It can find permission requests that have no matching feature in the visible app. Those findings are valuable even when a live test cannot reproduce them easily. Static analysis also produces a record that a peer can review without running the app. That record makes findings easy to share with a developer in a report.
Static analysis scales well to large apps and to version comparison work for a team. A tool can scan a large app folder in minutes and list findings by severity for review. A team can compare static findings across versions to see what changed in an update. That comparison reveals new permissions and new network hosts and new code paths fast. Static analysis also works when a test device is unavailable for a particular app version. That independence makes it a good first step for most security reviews of Android apps. It should not be the only step when a finding needs live confirmation for accuracy.
Limits Of Static Analysis
Static analysis has limits that reviewers must understand before trusting a finding fully. Obfuscated code can hide intent behind renamed classes and encrypted strings during reading. Native code can hide logic that Java analysis cannot see without native tools for study. Dynamic code loading can bring new code at run time that static files never contain. Reflection can call methods by name at run time in ways that static graphs miss. Those limits mean a static finding may be incomplete or misleading in some cases. Analysts should verify important static findings with a live test when possible during review. A finding without live confirmation should be labelled as static only in a report.
Static analysis also produces false positives that waste time when a reviewer trusts every tool output. A tool may flag a risky call that never runs with harmful input during real use. A tool may flag a permission that a feature needs in a rare case during normal use. A tool may flag a string that looks like a secret but is actually a test value. Reviewers should read the code around each flagged finding before reporting it to a developer. That context check separates real issues from tool noise in a large app. It also builds trust with developers who receive fewer false alarms from a reviewer.
Strengths Of Dynamic Analysis
Dynamic analysis reveals real behaviour on a real device during a live session with input. It shows network hosts that an app actually contacts when a feature runs for a user. It shows files that an app actually writes to storage during a session on a device. It shows data that an app actually sends in a request body before encryption happens. Those live facts are hard to dispute when they appear in a clear log with a timestamp. Dynamic analysis also reveals runtime values that static code cannot know without execution. A decrypted string appears only at run time in many protected apps during a session. A dynamic value chosen by a server appears only at run time as well. Those values matter for privacy and security judgements about an app.
Dynamic analysis also tests the app as a user experiences it during normal daily use. It can reveal a feature that only appears after a specific sequence of taps on screens. It can reveal a background task that runs when the app is closed by the user. It can reveal a crash that happens only with a specific input value during a test. Those experience based findings complement static code findings in a review. Together they give a fuller picture of app behaviour than either method alone. That fuller picture helps a developer fix real issues that affect real users.
Limits Of Dynamic Analysis
Dynamic analysis covers only the paths that a tester actually triggers during a session on a device. A feature that needs a rare input may never run during a short test session for review. A code path behind a server flag may stay hidden when the flag is off during testing. A background task that runs at night may not run during a daytime test session. Those coverage gaps mean dynamic work alone can miss important code in an app. Analysts should combine dynamic work with static code reading to find untested paths. A static map of features helps a tester design inputs that trigger hidden paths during a session. That planning improves coverage without requiring endless manual testing time.
Dynamic analysis also needs a test device and a test setup that can affect results during a session. A rooted test device may trigger security controls that block a feature for a tester. An emulator may fail a device check that a real phone would pass during normal use. A proxy certificate may change network behaviour for an app that pins certificates. Analysts should record the test setup with every dynamic finding in a report. That record helps a developer understand why a finding appeared on a test device. It also helps a peer repeat the test with the same setup for confirmation.
apktool d sample.apk -o sample-out
jadx -d jadx-out sample.apk
frida-ps -U
adb logcat -d | head -n 100A Combined Workflow
A combined workflow starts with static work to build a map of an app for the review question. The analyst decodes the app and lists permissions and components and network hosts in notes. The analyst then designs dynamic tests for the most important items on that map. The analyst runs those tests on a spare device with a proxy and a log capture tool. The analyst compares live results with static expectations and notes any difference in the report. A difference may reveal a hidden path or a false static guess during the review. That loop continues until the question has a clear answer with evidence from both methods. For a dynamic tool in that loop see Frida dynamic code injection.
Documentation for a combined workflow should separate static findings from dynamic findings clearly. A static finding should state the file and the code location that supports it in the report. A dynamic finding should state the test input and the log line that supports it in the report. A combined finding should state both types of evidence for the same claim in the report. That separation helps a developer trust the finding and act on it fast. It also helps a peer review the finding without repeating the whole workflow from scratch. Good documentation is part of good security analysis for any app review.
Choosing A Method For A New Question
Choosing a method for a new question starts with writing the question in plain words for the review. A question about data sent by an app points to dynamic work with a proxy tool first. A question about code structure points to static work with a decompiler first. A question about a hidden feature points to both methods in sequence for a full answer. Write the question and the chosen method in project notes before opening a tool. That pairing keeps the work focused and makes the result easy to explain to a developer later.
Method choice also depends on the time available for a review of an app in a project. Static work can scan a large app in a short session with tool support for findings. Dynamic work needs a test device and manual interaction time for each feature under study. A short review may rely more on static work for coverage of the whole app package. A longer review can add dynamic tests for the most important features found statically. Balance time against coverage rather than choosing one method for every question in a project.
Method choice should also consider the skills of the reviewer for a particular app type. A reviewer strong in code reading may start statically and add dynamic tests later in the workflow. A reviewer strong in testing may start dynamically and add static reading for findings that need code context. Both starting points can reach a good result when the other method follows for confirmation. The key is to use both methods before finalising a finding for a developer report. That discipline prevents a single method bias from shaping the whole review result.
Document the method choice for each finding in a report so a developer can judge its strength. A static only finding should be labelled as static only with its file location for reference. A dynamic only finding should be labelled as dynamic only with its test input for reference. A combined finding should list both types of evidence for the same claim in the report. That labelling helps a developer prioritise fixes based on evidence strength for each issue. It also helps a peer repeat the work with the same method for confirmation.
Readers who want a related topic can explore inspecting mobile app network traffic next in this series.
Conclusion
Static and dynamic analysis answer different questions about an Android app during security review. Static work covers code and resources without running the app on a device at all. Dynamic work reveals live behaviour and values that static reading cannot know alone. Each method has strengths and limits that a reviewer must understand before judging a finding. Strong work combines both methods in a loop with a clear question at the start. That combined method gives developers evidence they can trust and act on fast. It also gives users stronger protection through better tested apps in the long run.
The steps above follow the approach described in the official developer documentation for Android applications and in widely used testing guidance for mobile software.
