arXiv CSopen access

From Signals to Behaviors: Evidence-Based Android Malware Detection

From Signals to Behaviors: Evidence-Based Android Malware Detection Shiwen Song∗ , Yiheng Xiong∗∗ , Sen Chen† , Xiaofei Xie∗ ∗ Singapore Management University, Singapore

arXiv:2607.23272v1 [cs.CR] 25 Jul 2026

[email protected], [email protected], [email protected] † Nankai University, China [email protected]

Abstract—Android malware remains a persistent threat, and detecting it accurately is a long-standing open problem. Whether an app is malicious depends on what it actually does and the context in which it does it, not on the surface signals it happens to exhibit. Existing detectors instead reason about proxies for behavior, such as learned features or local code slices, and flag whatever deviates from these proxies as malicious. But deviation is not maliciousness: benign apps that merely look unusual are over-flagged, evolving malware that looks ordinary slips through. We argue that detection should be behavior-oriented: recover an app’s potentially malicious behaviors and judge which are truly malicious. To realize this, we present P RAXIS, which structures detection as a hypothesize–confirm–judge pipeline: it hypothesizes candidate behaviors from coarse static signals, confirms each by grounding it in code evidence verified with program analysis, and judges the confirmed behaviors in context: the user’s awareness, the app’s functional context, and how they compose into an attack. For a malicious app, P RAXIS returns a verdict and the supported behaviors. We evaluate P RAXIS against seven baselines across three challenging settings. It achieves the best overall detection performance (87.4% F1), outperforming the baselines by 18.6–34.8 percentage points. On high-permission benign apps, it reduces the false-positive rate to 13.0%, a reduction of 41.1–67.0 percentage points compared with the baselines. Beyond binary detection, P RAXIS recovers fine-grained malicious behaviors at 87.3% F1, outperforming prior behavior-level approaches by 56.5–73.4 percentage points. Ablation studies show that each stage of the pipeline contributes to the final performance.

I. I NTRODUCTION Android runs on the majority of the world’s mobile devices and mediates much of users’ financial and personal activity, which makes it the prime target of malicious software. Despite app-store vetting and on-device protection, Android malware remains a persistent threat: more than 2.67 million mobile attacks were blocked in the first quarter of 2026 alone [1], and the apps that slip past these defenses inflict real privacy and financial harm. Detecting them accurately is therefore a long-standing and still-open security problem. At its core, what makes an app malicious is not the signals it exhibits, such as its permissions, API calls, or code features, but what the app does and the context in which it does it. The same operation can be legitimate or malicious depending on the situation in which it runs: sending an SMS message ∗ Corresponding author.

is benign when the user knowingly triggers it, but malicious when an app silently sends premium-rate messages behind the user’s back; and even an operation the user never sees can be legitimate, as when a cloud-backup app silently uploads files in the background in line with its advertised function, while that same silent upload is spyware in an app that offers no such function. Maliciousness is thus a property of a behavior judged in context: whether the user is aware the behavior runs, and whether it falls within the app’s functional context. An effective detector should reason at this level: identify the behaviors an app actually performs, and judge each against its context. By this standard, existing detectors fall short because they reason about proxies for behavior rather than behavior itself. Learning-based detectors classify an app from features such as permissions, sensitive-API usage, or API-call graphs [2], [3], [4], [5]; these features only approximate behavior, so featurerich benign apps that legitimately request broad permissions are over-flagged [6], while malware that reimplements its logic around the monitored features slips through, and the model emits an opaque label that drifts as malware evolves [7] and explains nothing. Even approaches that explicitly consider context, such as AppContext [8], encode it as hand-crafted features for a classifier rather than judging recovered behaviors, and so inherit the same proxy limitation. More recent LLM-based methods [9], [10] begin to recover behavioral content and natural-language explanations: LAMD [9] summarizes backward slices taken around sensitive APIs, and ForeDroid [10] flags sensitive-API call chains that deviate from a benign reference distribution. Yet slices and call chains are only partial, local views: neither assembles them into a complete, code-grounded behavior, and neither judges that behavior in the app’s actual context. Across all three categories, then, no detector recovers what an app does, the very basis on which maliciousness is defined. We therefore argue that detection should be behaviororiented: instead of recognizing how an app looks, reconstruct what it does and judge those behaviors in context, much as a human analyst would. This is compelling for three reasons. It is explainable: each verdict is backed by concrete behaviors and the code evidence that realizes them, not an opaque score. It is faithful to how maliciousness is actually defined: it judges

behavior against user awareness and functional context, the same criteria an analyst applies. And it is robust: a malicious app can drop conspicuous permissions, obfuscate its APIs, and mimic a benign one [11], [12], [13], but it cannot drop the harmful behavior itself insofar as that behavior is realized in its code, so a behavior-level detector resists the feature drift and evasion that erode signal-based detectors. Realizing behavior-oriented detection, however, is hard. In principle it is straightforward (enumerate every behavior an app performs and judge each in its context), but carrying this out is infeasible, for three reasons. (C1) Malicious behavior is sparse in a large behavior space. A single app performs a wide range of functionalities, the overwhelming majority of them benign, while malicious behavior, when present, is only a sparse few buried among them [14]. Recovering all the behaviors an app performs and then pinpointing the malicious ones is therefore hard: the space to search is large, and the malicious target within it is rare [15]. (C2) There is a gap between semantic behaviors and code evidence. A behavior describes what an app does at the semantic level, but proving that it is actually implemented requires concrete code evidence. Bridging this gap is difficult because a behavior rarely maps to a single code location; instead, its implementation may be scattered across multiple functions and execution paths. (C3) A behavior’s context is hard to recover. Even once a behavior is established, judging it requires context the app never states (whether the user is aware the behavior runs and whether it fits the app’s functional context) and, beyond any single behavior, how several behaviors combine into a coherent attack. Recovering this implicit context for each behavior, and reasoning over the behaviors jointly, is itself difficult. To address these challenges, we introduce P RAXIS, a behavior-oriented Android malware detector built around a hypothesize–confirm–judge pipeline. P RAXIS first hypothesizes: it extracts heterogeneous coarse signals (manifest permissions and components, intent actions and sensitive-API call sites from code, and native function names) and uses an LLM as an open-world generator to propose a bounded set of candidate behaviors. It then confirms each candidate by locating the functions that could implement it, and using program analysis together with the LLM to verify that they connect into an evidence chain that actually realizes the behavior, discarding any candidate it cannot ground. Finally, it judges each confirmed behavior against the user’s awareness of its trigger and the app’s functional context, flagging the app only when the surviving behaviors compose into a coherent attack pattern. P RAXIS outputs a malicious/benign verdict and, for a malicious app, the behavior records behind it. We evaluate P RAXIS against six learning- and LLM-based baselines across three deployment-stress settings. P RAXIS achieves the best overall detection performance with 87.4% F1, outperforming the baselines by 18.6–34.8 percentage points, while reducing the false-positive rate on privileged benign apps by 41.1–67.0 percentage points. For fine-grained malicious behavior recovery, P RAXIS achieves 87.3% F1, outperforming ProMal and ForeDroid by 56.5 and 73.4 per-

centage points, respectively. Ablation and cross-model studies further show that each stage of P RAXIS contributes substantially to its performance and that the framework remains effective across different LLMs. In summary, this paper makes the following contributions: We cast Android malware detection as behavior-oriented, context-aware analysis: establishing maliciousness by recovering the behaviors an app performs and judging them in context, rather than classifying surface signals, improving both detection accuracy and explainability. • We present P RAXIS , a hypothesize–confirm–judge pipeline that proposes candidate behaviors with an LLM, keeps only those that program analysis can ground in code as entry → source → effect evidence chains, and judges the grounded behaviors against user awareness, functional context, and attack composition. • We show that P RAXIS achieves state-of-the-art malware detection across three deployment-stress settings and identifies fine-grained malicious behaviors beyond the reach of prior detectors, with an ablation isolating the contribution of each stage. •

II. BACKGROUND A. Problem Definition Our goal is twofold: to decide whether an APK is malicious and, if so, to recover the behaviors behind that decision. A behavior is a security-relevant action an app performs, described semantically, what the app does, such as “capture incoming SMS messages and forward them to a remote server.” A behavior is a semantic notion, independent of any particular implementation. To decide whether a behavior is actually present, and to make that decision auditable, the behavior must be grounded in code. We call the code that realizes a behavior its evidence: the functions that carry the behavior out and the execution paths connecting them. A behavior with no such evidence in an APK is not performed by it. A behavior, even when grounded, is not malicious or benign on its own; that depends on its context, the circumstances under which it runs. We consider two aspects: whether the user is aware the behavior runs, that is, whether it is triggered and disclosed through the interface rather than executed silently in the background; and whether the behavior is consistent with the app’s functional context, the functionality it openly offers. The same behavior flips between benign and malicious as this context changes. We bundle these into a behavior record u = ⟨b, π, c⟩: a behavior b, its code evidence π, and its context c. A malicious app’s behaviors rarely act alone; they compose into an overall attack pattern that the detector should surface together with the behaviors realizing it. Malware detection is then to recover an APK’s behavior records and judge them jointly.

Definition 1. Given an APK a, recover its grounded behavior records R(a) = {u1 , . . . , un }, with each ui = ⟨bi , πi , ci ⟩, and apply a judgment function M (R(a)) = ⟨Y, P, R+ ⟩, where Y ∈ {malicious, benign} is the APK-level verdict, P is the attack pattern the app realizes (defined only when Y = malicious), and R+ ⊆ R(a) is the subset of behavior records that compose into P . B. Motivating Example Figure 1 (a) shows an Android malware sample [16] disguised as a mobile banking app. It presents a fake login screen so the user takes it for a genuine bank. Once installed and granted its permissions, however, it silently monitors incoming SMS in the background, extracts their contents, and forwards them over HTTP to a remote server, carrying out SMS exfiltration. What makes this malicious is not the SMS access itself (a messaging app reads SMS too) but that the access runs without the user’s awareness and outside the app’s banking purpose, and that reading and exfiltration compose into a single attack: precisely the behavior-judged-in-context on which maliciousness turns. Limitations of state-of-the-art approaches. Both learningbased and LLM-based detectors [2], [3], [4], [5], [9], [10] miss this malware, for reasons that differ by approach. First, the learning-based detectors (Drebin, MalScan, MsDroid, MaskDroid) do not reason about what the app does. They learn a feature distribution from past malware and judge an app by how its features fit that distribution, taking a statistical pattern as a stand-in for malice. Yet a feature pattern only correlates with maliciousness, and concept drift breaks that correlation as malware evolves: this sample’s SMS- and network-related features are each common in benign apps, and their malicious combination is under-represented in the training data, so its features look ordinary and the detectors clear it. Second, the LLM-based detectors (LAMD, ForeDroid) attempt to reason about the app’s behavior, but still fail to recover this attack behavior. LAMD summarizes the app bottomup, one sensitive API at a time, then judges the whole APK from these summaries. Each sensitive API is reached through many call paths, so its per-API summary overlooks the single malicious path and reports a benign intent. The final judgment then weighs all these summaries together, where too many individually benign APIs bury the attack. ForeDroid breaks the app into entry-to-sensitive-API chains and judges each on its own, keeping only the chains whose embedding departs from a benign distribution and discarding the rest as benign (Figure 1(b)). Here the SMS-reception and HTTP-transmission chains each look benign in isolation, so ForeDroid discards both and never sees that together they form SMS exfiltration. In short, none of them recovers the complete behavior the app implements, which is what makes it malicious. Our approach. P RAXIS understands malware at the level of behaviors, what the app actually does. It starts from a candi-

Fig. 1: Our motivating example.

date behavior the app might perform, grounds that behavior in the code that realizes it, and judges whether it is malicious in context. Figure 1(c) traces this on the sample. From the APK’s signals, P RAXIS hypothesizes the behavior “capture incoming SMS and exfiltrate them to an attacker’s server” and confirms it in the implementation as a reachable entry→source→effect chain: the SMS RECEIVED receiver, the PDU parsing that reads the message, and the HttpURLConnection write that sends it out. It then judges this grounded behavior in context: it is triggered by a background broadcast, so it runs without the user’s awareness, and it falls outside the banking functionality the app advertises; the SMS read and the exfiltration thus compose into an SMS-exfiltration attack. P RAXIS labels the APK malicious and outputs behavior records behind it—an account an analyst can audit, which the proxy- and fragmentbased detectors cannot provide. III. M ETHODOLOGY Figure 2 shows the workflow of P RAXIS, which detects malware in three stages: it hypothesizes the malicious behaviors an app may perform, confirms each against the code, and judges the confirmed behaviors in context, answering challenges C1– C3 in turn. To address C1, rather than enumerate every behavior in the code, P RAXIS hypothesizes (§III-A): it starts from signals that malicious behavior commonly leaves behind and lets an LLM, drawing on its knowledge of Android and malware, propose the behaviors these signals suggest. To address C2, P RAXIS confirms each hypothesis by grounding it in code (§III-B). Following prior Android behavior modeling [17], [8], [18], it casts the behavior as an entry→source→effect skeleton (the function that initiates the behavior, the one that accesses or operates on the source, and the one that carries out the effect), searches the app’s functions for each role, and looks for a reachable chain through the three roles whose code realizes

Fig. 2: Overview of P RAXIS.

the behavior. The behavior is kept only if such a chain exists, and that chain is its code evidence. To address C3, P RAXIS judges the confirmed behaviors in the context (§III-C): for each behavior it recovers two kinds of context (whether the user is aware the behavior runs and whether it fits the app’s functional context), and then assesses the behaviors together with their evidence and context, deciding whether the app is malicious and, if so, returning the behaviors behind that verdict. A. Malicious Behavior Hypothesis Generation Given an APK, P RAXIS generates the behavior hypothesis that the rest of the pipeline confirms and judges. Because the space of possible behaviors is large and a malicious one may surface anywhere in the code [12], [11], [13], P RAXIS infers them from broad evidence: it reads complementary static signals from the APK and uses an LLM, with its knowledge of Android APIs and malware tactics, to propose the behaviors these signals jointly suggest. Each proposal is a hypothesis, paired with the signals that support it, that the next stage then confirms against the code. Specifically, P RAXIS extracts five signals from three sources, shown in Figure 3. From the AndroidManifest.xml, it takes the requested permissions, the capabilities the APK may use, and the declared components, the points where it can be entered. From the bytecode, which it analyzes in Soot’s IR [19] because many behaviors are never declared in the manifest, it takes implicit intent actions, the APK’s interactions with system services, and sensitive API calls, identified with the MalScan list [3], the security-relevant operations it performs. From the native libraries, it uses Ghidra [20] to extract native function names, since malware often hides securityrelevant logic in native code [21], [22], [23]. Figure 4(a) illustrates these signals on the motivating example. P RAXIS prompts the LLM to read these signals from an attacker’s perspective and name the attack intents they suggest (Figure 3). It asks for high-level goals, such as SMS interception, leaving the implementing techniques to the later stages. The prompt balances coverage against speculation: it pushes the LLM to propose intents broadly, including non-obvious ones, while requiring each to be backed by one or more of

Hypothesis Generation [Task] Given an APK’s declared capabilities, generate plausible attack-intent hypotheses from the attacker’s perspective. [Input] Five categories of APK signals: (i) declared permissions, (ii) components with their intent-filters, (iii) sensitive APIs, (iv) implicit intent actions, and (v) native function names. [Instructions] 1.Generate high-level attack intents rather than low-level implementation details. 2. Consider both single-signal hypotheses and multi-signal combinations. 3. Be comprehensive: prefer including a plausible intent over leaving it out. 4. Each hypothesis must be a distinct attack intent, with a name, a description, and the specific signals that support it.

Fig. 3: The prompt for behavior hypothesis generation.

the observed signals. The signals only seed this proposal: although some are drawn from fixed lists, such as the MalScan sensitive-API set, the LLM may hypothesize behaviors beyond any predefined catalog, so coverage is not bounded by a fixed rule set as in catalog-based detectors. The output is a set of hypotheses, each an attack intent with a short description and its supporting signals. For example, Figure 4(b) shows one hypothesis generated for the motivating example, “SMS Theft for OTP Interception”: the RECEIVE SMS, READ SMS, and INTERNET permissions together grant the capability to capture and exfiltrate messages, the exported broadcast receiver listening on SMS RECEIVED provides an entry point that fires automatically on every message arrival, and the sensitive API SmsMessage.createFromPdu, reachable from this receiver, enables PDU parsing of the captured messages. B. Evidence-grounded Behavior Confirmation A hypothesis is only a natural-language guess; this stage confirms it by finding the code that realizes it, and keeps the behavior only if such code exists. This is challenging for two reasons. First, the hypothesis is only a natural-language description, with no pointer to the code that realizes it: most of its signals give no code anchor, since a requested permission or declared component names a capability without showing where the app exercises it. Second, even searching the

[Permissions] RECEIVE SMS, READ SMS, INTERNET, . . . [Components] io.flutter.plugins.Receiver (BroadcastReceiver, exported), . . . [Implicit Intent Actions] io.flutter.plugins.Receiver → android.provider.Telephony.SMS RECEIVED, . . . [Sensitive APIs] android.telephony.SmsMessage.createFromPdu, android.provider.Settings$Secure.getString, . . . [Native function names] (none) (a) Signals extracted from the APK. Attack Intent: SMS Theft for OTP Interception Description: Capture incoming SMS (especially bank/2FA OTPs) and exfiltrate them to an attacker to bypass authentication or confirm fraudulent transactions. The app can directly receive SMS broadcasts and read message contents. Supporting Signals: 1. Permissions: RECEIVE SMS, READ SMS, INTERNET 2. Exported receiver listening to android.provider.Telephony.SMS RECEIVED (io.flutter.plugins.Receiver) 3. Sensitive API SmsMessage.createFromPdu reachable from the SMS broadcast receiver enables PDU parsing of incoming messages (b) Hypothesis generated by the LLM.

Fig. 4: A hypothesis from the motivating example.

code with the behavior hypothesis is too coarse, because the hypothesis describes a complete behavior, whereas the code implements it through multiple functions, each corresponding to only one semantic role. P RAXIS recovers it guided by an entry→source→effect skeleton of the behavior: the entry that triggers it, the source of sensitive data or state it acts on, and the effect it produces. We call the entry, source, and effect the three roles of the skeleton: the parts the implementing code must fill, in that order. In Algorithm 1, P RAXIS first derives this skeleton from the hypothesis with the LLM (Skeleton, Line 1): from the attack intent, description, and supporting signals, it specifies for each role what the implementing code should do, anchoring a role in the hypothesis’s signals wherever they pin it down. In Figure 4(b), for instance, the entry is the callback of the exported SMS RECEIVED receiver, the source parses the incoming message via SmsMessage.createFromPdu, and the effect sends the message out over the network. Guided by this skeleton, P RAXIS (i) searches the app’s functions for candidates for each role (Retrieve, Line 2; §III-B1); (ii) keeps the candidate triples whose entry, source, and effect are wired into a reachable entry→source→effect chain (Reach, Lines 3– 5; §III-B2); and (iii) asks an LLM to confirm from their code which chains realize the behavior, keeping the confirmed chains as the behavior’s evidence π and assigning it a support label ℓ (SemanticConfirmation, Line 7; §III-B3). A hypothesis whose roles admit no reachable chain is discarded (Line 6); the rest pass on with their evidence.

Algorithm 1: Evidence-grounded behavior confirmation Input : Hypothesis h = (intent, description, signals); function corpus C. Output: Evidence π and support label ℓ. 1 (e, s, f ) ← Skeleton(h) 2 Fe ← Retrieve(e, C); Fs ← Retrieve(s, C); Ff ← Retrieve(f, C) T ←∅ foreach (fe , fs , ff ) ∈ Fe × Fs × Ff do 5 if Reach(fe , fs ) ∧ Reach(fs , ff ) then T ← T ∪ {(fe , fs , ff )}

3 4

6

if T = ∅ then return ⊥

7

(π, ℓ) ← SemanticConfirmation(h, T ) return (π, ℓ)

8

1) Candidate Function Retrieval: Given a hypothesis, this step retrieves the candidate functions that may fill each role of its skeleton, which the later steps then check. Because the behavior is realized across its entry, source, and effect, P RAXIS searches for the three roles separately, so that none goes unsearched. For each APK, P RAXIS builds a retrieval corpus that represents every function in two ways. For each app-specific function, P RAXIS uses an LLM to generate a concise behavioral summary that preserves Android-specific cues (e.g., framework APIs and component types), and stores the summary with the function’s decompiled code. TPL functions, identified by LibRadar [24], are kept as decompiled code only, since summarizing the many generic library functions would add cost and retrieval noise. To search the corpus, P RAXIS prompts an LLM to build two complementary queries for each role, one against each representation. A semantic query, derived from the role’s specification, describes how a function filling that role would behave and is matched against the summaries. A lexical query lists that role’s concrete anchors, such as API names, class or method names, and intent actions, and is matched against the decompiled code. For example, in Figure 4(b), the source role’s semantic query reads “function that parses SMS PDU and reads message body and sender,” while its lexical query lists SmsMessage.createFromPdu. P RAXIS scores each candidate function f for a role r by combining semantic and lexical similarity: score(f, r) = α · simsem (f, r) + β · simlex (f, r). Here, simsem is the cosine similarity between SBERT [25] embeddings of the role query and the function summary, while simlex is the BM25 [26] score between the lexical anchors and the decompiled code. P RAXIS keeps the top-k functions for each role as its candidate set Fr (Retrieve in Algorithm 1). The weights favor semantic similarity, with lexical anchors serving as complementary cues; k trades coverage against the

cost of checking candidate chains. We report α, β, and k in our experimental setup. 2) Reachable Chain Construction: Retrieval ranks candidates for each role by similarity alone, so not every candidate belongs to the behavior. P RAXIS keeps only those that fit together into a chain: the functions realizing one behavior must connect from entry through source to effect, so a triple whose functions cannot reach one another in that order is spurious. P RAXIS therefore keeps the candidate triples whose functions form a reachable chain,  T = (fe , fs , ff ) ∈ Fe × Fs × Ff Reach(fe , fs ) ∧ Reach(fs , ff ) , where Reach(f, f ′ ) holds when f ′ is reachable from f (Reach in Algorithm 1). Because Android control and data flow propagate through more than direct calls, P RAXIS decides reachability through three channels: Reach(f, f ′ ) ⇐⇒ Rcall (f, f ′ ) ∨ Ricc (f, f ′ ) ∨ Rstate (f, f ′ ) ∨ f = f ′ . Call reachability Rcall holds when one function reaches the other through call edges. ICC reachability Ricc holds when the two lie in different components joined by an inter-component communication transition [27]. State reachability Rstate holds when one writes and the other reads a shared object, such as a class field, a SharedPreferences key, or a ContentProvider URI; we check these high-confidence shared objects directly rather than running def-use analysis over the whole APK, which reduces cost and noise. The final disjunct f = f ′ covers a single function that fills both roles. A hypothesis with no reachable chain (T = ∅) is discarded; the rest pass to semantic confirmation. 3) Semantic Confirmation: A connection by a program relation does not guarantee semantic relevance: two functions can be wired together yet have nothing to do with the hypothesized behavior. P RAXIS therefore confirms each candidate chain in two steps. First, for each adjacent pair on the chain, it reads the two endpoints’ decompiled code and asks whether they carry out that step of the behavior, dropping any pair whose implementation does not hold up. Second, it asks whether the surviving chain realizes the behavior as a whole, exhibiting each part, such as the data accessed and the APIs invoked, and connecting them into one coherent realization. P RAXIS then labels each chain supported, partial, or not-supported, discards the not-supported ones, and carries the rest, with their label, to the maliciousness judgment. C. Context-Aware Maliciousness Judgment This stage judges the confirmed behaviors in the context the APK leaves implicit, deciding whether it is malicious and identifying the behaviors behind that decision. A confirmed behavior says only what the APK does, not whether it is malicious: as in the motivating example (Fig. 1), reading incoming SMS is benign in a messaging app the user opens, but malicious when an app does it silently and forwards

the messages to a remote server. Moreover, one behavior alone rarely settles maliciousness; malware is marked by several behaviors combining into an attack [28], [29]. P RAXIS therefore recovers, for each behavior, two kinds of context the APK leaves implicit: whether the user is aware the behavior runs (§III-C1) and whether it fits the app’s functional context (§III-C2). It then judges the behaviors together with their evidence and context (§III-C3). Rather than discard a behavior the moment it looks justified, P RAXIS attaches its context and weighs all behaviors jointly, so that a behavior innocuous on its own is still considered as part of a possible attack. 1) User-Awareness Context Extraction: Malware works by hiding its harmful behaviors from the user, so whether the user is aware a behavior runs is a strong contextual cue; P RAXIS recovers this awareness as context for the judgment. P RAXIS first recovers how the behavior is triggered, tracing backward from its evidence π to the Android entry points in the enhanced call graph [30]. A behavior reached only through background events, such as a system broadcast, a scheduled task, or a longrunning service, starts without the user and is labeled nonaware. A behavior whose entry points cannot be recovered is labeled unknown. A behavior the user starts through the UI is examined further to see whether the interface discloses what it does. For such a UI-triggered behavior, P RAXIS builds a semantic context for the triggering UI: it summarizes the Activity with an LLM to capture the screen’s purpose and, for a widget-triggered behavior, adds the widget’s visible text. This combines screen-level and widget-level cues, a finer basis than the widget labels or isolated UI strings used in prior work [31], [10], [32]. P RAXIS then determines whether this context discloses the behavior, that is, whether the behavior falls within what the UI leads the user to expect; if so, the behavior is labeled aware, otherwise non-aware. Each behavior thus carries an awareness label (aware, non-aware, or unknown) into the final judgment, rather than being filtered out here. 2) Functional Context Extraction: P RAXIS also recovers whether each behavior is consistent with the app’s functional context, what the app openly does for its users, as a second kind of context. It infers this context chiefly from the screenlevel UI summaries of the app’s user-visible Activities, supplemented by the app’s label, store category, and main-package class names. Whether a behavior fits this context, and how far it departs from it, is attached to the behavior as functional context for the final judgment (§III-C3). 3) Maliciousness Decision: The two contexts above bear on each behavior in isolation; what remains is how the behaviors relate to one another. Reading incoming SMS, for instance, could be legitimate, but once the app also uploads those messages to a remote server, the two together are a clear SMSexfiltration attack. P RAXIS therefore makes the final decision over all behaviors jointly. P RAXIS gives the LLM all the confirmed behaviors at once, each with its evidence π, function summaries, awareness and functional context (§III-C1, §III-C2), and hypothesized intent.

Maliciousness Decision [Task] Given the risky behaviors, decide whether they compose a recognized Android malware attack pattern. [Input] For each risky behavior: the evidence with per-function summaries, the trigger context, the attack intent, and the description. [Instructions] 1. Integration over tallying: reason about how the behaviors compose into a coherent attack lifecycle, not by counting verdicts. 2. Key behavior over completeness: report the risky behaviors that best characterize the resulting attack pattern, rather than listing every recovered behavior. 3. Evidence over hypothesis: when the recovered evidence narrows, refines, or contradicts the intent or description, anchor the characterization in the evidence rather than the original hypothesis.

Fig. 5: The prompt for maliciousness decision. Attack Pattern: SMS-based OTP Interception and Exfiltration Key Behaviors: 1. Silent SMS interception via a background broadcast receiver (io.flutter.plugins.Receiver.onReceive) listening on android.provider.Telephony.SMS RECEIVED (intent-filter priority 999), triggered automatically by the Android framework without user interaction. 2. PDU parsing of incoming messages to extract body, sender, and service-center address (SmsMessage.createFromPdu, getMessageBody, getOriginatingAddress). 3. Device fingerprinting via Android ID lookup (Receiver.c, Settings$Secure.getString), packaged alongside the captured SMS payload. 4. Background exfiltration of the captured data through a Kotlin coroutine and lambda (Receiver.b, s3.a.a, Receiver$a.a) terminating in an HttpURLConnection write to a remote endpoint, traversed entirely without UI involvement. 5. Bank Mellat impersonation as a deception layer: app label “Hamrah Bank” (Persian for “Mobile Bank”) and a Flutter-rendered banking-style login interface (card number, password, password recovery), but no real Bank Mellat backend connection or banking transaction logic.

Fig. 6: A recognized attack pattern from the motivating example. P RAXIS then prompts it (Figure 5) to judge each behavior in its context and to reason how the behaviors compose into an attack, identifying the attack’s key behaviors. P RAXIS labels the APK malicious if such an attack emerges, and benign otherwise. For a malicious verdict, it returns the attack pattern and these key behaviors, each with its evidence and a description matched to its code, as a code-grounded account of the decision. Figure 6 illustrates this on the motivating example (§II-B): five behaviors composing into an SMS-exfiltration attack pattern. IV. E VALUATION We evaluate P RAXIS by investigating the following research questions:

RQ1: How effective is P RAXIS at malware detection compared with existing approaches? • RQ2: How well does P RAXIS identify malicious behaviors? • RQ3: How does each component of P RAXIS contribute to its effectiveness? • RQ4: How does the underlying LLM affect the effectiveness and cost of P RAXIS? •

A. Experimental Setup 1) Baselines: We use seven baselines in total: six for malware detection and two for malicious-behavior identification, with ForeDroid serving in both roles. For malware detection, we compare P RAXIS against six state-of-the-art Android malware detectors spanning two categories. ① Learning-based detectors. We include four learningbased detectors [33], [34], spanning feature-based (Drebin) and graph-based (MalScan, MsDroid, MaskDroid) detection. Drebin [2] extracts static features from the manifest and code, encodes them as a binary feature vector, and trains an SVM classifier for malware detection. MalScan [3] constructs function call graphs, represents each APK using centrality-based features of sensitive APIs, and trains a k-nearest-neighbor classifier. MsDroid [4] extracts sensitive API graphs and trains a GNN-based classifier. MaskDroid [5] further improves GNN robustness through masked graph representation learning and contrastive learning. ② LLM-based detectors. We include two LLM-based detectors, LAMD [9] and ForeDroid [10], both of which use an LLM to analyze app behavior; for ForeDroid, we use the OCSVM model released by its authors. For malicious-behavior identification, we compare against two baselines that also produce behavior records: ForeDroid, described above, and ProMal [35]. ProMal is not designed for APK-level malware detection; it assumes the input APK is already malicious and maps API-level evidence to malicious behavior records using an expert-built knowledge graph. 2) Dataset: Our evaluation dataset contains 1,033 apps in total, split into three sets, each reflecting a setting that detectors encounter in real-world deployment: time-shift (600 apps), the most recent malware (2024–2026); diverse-family (163 malware), one sample from each of many distinct families; and privileged-benign (270 benign apps), each requesting many sensitive permissions. Training and validation data. P RAXIS requires no training, so this data serves only the learning-based baselines, which we retrain on a unified set since their original training data is unavailable or inconsistent across studies. Following standard collection practice [7], [34], [10], [13], we collect apps from AndroZoo [36] and label them with VirusTotal [37]. The training set is balanced across 2021–2023 at 10,000 apps per year (30,000 in total), and the validation set adds a disjoint 2,500 apps per year, on which the baselines reach F1 scores of 97.8% (Drebin), 96.7% (MalScan), 91.5% (MsDroid), and 95.1% (MaskDroid), confirming they are properly trained. Note that the three evaluation sets described next are all disjoint from these.

Time-shift. This set evaluates whether detectors generalize to recent APKs. We use samples from 2024–2026, with 100 malware from MalwareBazaar [38] and 100 benign APKs from AndroZoo per year, totaling 600 APKs. For learning-based detectors, this setting measures robustness to concept drift as samples move away from the training distribution [7]. For LLM-based detectors, it tests whether they are also affected by changes in APKs over time, despite not relying on taskspecific training. Diverse-family. This set evaluates whether a detector remains effective across diverse Android malware families. We draw from GPMalware [39] and MalwareBazaar [38], together spanning 2015–2026; after discarding samples that lack a reliable family label, we obtain 163 malware spanning 163 distinct families. Privileged-benign. Many legitimate apps, such as security, backup, and device-management tools, genuinely require sensitive permissions, which makes them easy to mistake for malware. This set measures how often a detector falsely flags such apps as malicious. We collect benign APKs from AndroZoo spanning 2015–2025, rank them by the number of declared dangerous permissions, and keep the top 270 statically analyzable ones; each declares at least 9 dangerous permissions, and the set spans 49 Google Play categories. 3) Environment: P RAXIS, LAMD, and ForeDroid all use DeepSeek-V4-Pro, which balances reasoning quality and inference cost, and running every method on the same model keeps the comparison fair. The one exception is P RAXIS’s corpus summarization (§ III-B1), which runs over every app-specific function and uses the cheaper DeepSeek-V4-Flash to keep this high-volume step affordable. We fix the temperature to 0 for all calls to aid reproducibility. Because LLM outputs can still vary at temperature 0, we run each LLM-based method (P RAXIS, LAMD, and ForeDroid) three times and take the majority verdict over the three runs. For retrieval (§III-B1), we empirically set the similarity weights to α = 0.7 and β = 0.3, favoring semantic over lexical similarity, and keep the top k = 10 candidates for each role, balancing coverage against verification cost. 4) Evaluation Method for RQ1: We compare P RAXIS against the six baselines from § IV-A1. Because the three test sets differ in composition, we report the metric each supports: on the balanced time-shift set, F1 together with false-negative rate (FNR) and false-positive rate (FPR); on the malware-only diverse-family set, FNR (the fraction of malware missed); and on the benign-only privileged-benign set, FPR (the fraction of benign apps flagged as malicious). 5) Evaluation Method for RQ2: We evaluate P RAXIS’s behavior identification effectiveness from two angles: a comparison with ForeDroid [10] and Promal [35], the state-ofthe-art tools that identify malicious behaviors, and a per-stage analysis of P RAXIS’s pipeline. To support these evaluations, we build a behavior-level ground truth on the diverse-family dataset, chosen because every sample is accompanied by a high-quality threat report. Following existing practice [10], we first refine the 8 payload

categories defined in GPMalware [39] into 50 fine-grained behavior types. We then manually extract the documented malicious behaviors from each threat report and its APK and annotate them, yielding 962 ground-truth behaviors across the 163 samples. Two authors, each with more than three years of Android malware analysis experience, independently assign both ground-truth behaviors and candidate behaviors to one of the 50 fine-grained behavior types. Disagreements in type assignment are resolved through discussion. For each sample, behavior identification is computed by matching the assigned behavior types of the recovered behaviors against those of the ground-truth behaviors. We apply this protocol in two settings. In the baseline comparison, we compare the final behavior records produced by P RAXIS and ForeDroid on the 81 samples that both methods correctly classify as malicious, covering 565 groundtruth behaviors. In the per-stage analysis, we apply the same protocol to the outputs of every stage on the diverse-family dataset. Inter-annotator agreement reaches Cohen’s κ = 0.88 and 0.83 for the two settings, respectively. 6) Evaluation Method for RQ3: To evaluate the contribution of each major stage in P RAXIS, we construct three ablated variants corresponding to the three stages of our pipeline. w/o Multi-Signals replaces multi-signal behavior hypothesis generation (§III-A) with hypotheses generated solely from sensitive APIs, evaluating the benefit of multi-signals. w/o Verification removes both structural(§III-B2) and semantic verification (§III-B3), evaluating the importance of grounding behavior hypotheses in code evidence. w/o Context removes userawareness judgment (§III-C1), functional context judgment (§III-C2), and attack-pattern recognition (§III-C3). It instead uses a plain judgment prompt to decide maliciousness directly from the recovered code evidence and behavior hypotheses, without explicit context-aware reasoning. We evaluate all variants on the same three evaluation datasets as RQ1 and report the corresponding detection metrics. 7) Evaluation Method for RQ4: We run P RAXIS with three LLMs spanning different capability and cost tiers: GPT5.2, DeepSeek-V4-Pro (our default), and GPT-5.4-mini. Each substitutes only the detection-reasoning model; corpus summarization (§ III-B1) is held fixed at the lightweight model (§ IV-A3), so the comparison isolates the reasoning model. We report effectiveness with the same per-set metrics as RQ1, and cost as the average dollar cost per app, split into the fixed summarization cost and the model-dependent judgment cost. B. Results of RQ1: Malware Detection Performance Table I shows that P RAXIS leads on every setting and overall: the highest F1 on time-shift (92.2%), the lowest FNR on diverse-family (20.9%), the lowest FPR on privilegedbenign (13.0%), and the best overall F1 (87.4%). It exceeds the strongest baseline, Drebin (68.8%), by 27.0% and the weakest, MsDroid (52.6%), by 66.2% in relative overall F1. P RAXIS’s advantage is that it evaluates maliciousness directly, recovering each behavior from code and judging

TABLE I: Malware Detection under Challenging Scenarios. Method

Time-Shift FNR

FPR

TABLE II: Fine-Grained Behavior Identification Comparison.

Diverse-Family

Privileged-Benign

Overall

Method

#Detected

#FP

#FN

Precision

Recall

F1

F1

FNR

FPR

F1

Promal

5664

4581

119

19.1%

78.9%

30.8%

ForeDroid

1590

1473

334

8.5%

38.5%

13.9%

Ours

501

30

118

94.8%

80.9%

87.3%

Drebin

27.3%

3.3%

82.6%

25.2%

65.2%

68.8%

MalScan

49.3%

8.3%

63.7%

39.3%

60.0%

55.7%

MsDroid

44.0%

31.0%

59.9%

36.8%

75.2%

52.6%

MaskDroid

31.3%

16.7%

74.1%

22.7%

72.6%

63.8%

LAMD

50.0%

15.0%

60.6%

26.9%

80.0%

55.0%

ForeDroid

56.0%

10.7%

56.9%

37.4%

54.1%

53.5%

Ours

11.7%

3.3%

92.2%

20.9%

13.0%

87.4%

whether it is malicious in context, exactly what maliciousness depends on. The baselines instead reach maliciousness only through proxies that correlate with it, a learned feature distribution or a fixed list of sensitive APIs, and each setting is a case where one of these proxies decouples from actual malicious behavior. A learned distribution goes stale as apps evolve, so the learning-based baselines drift to 59.9–82.6% F1 on time-shift. A sensitive-API list misses malware that acts through other code, capping the API-keyed baselines at 52.6– 63.8% overall F1, and fires on benign apps that use those APIs legitimately, raising their FPR to 54.1–80.0% on privilegedbenign. C. Results of RQ2: Malicious Behavior Identification 1) Fine-Grained Behavior Identification Performance: As shown in Table II, P RAXIS substantially outperforms both baselines in fine-grained behavior identification, achieving an F1 of 87.3% compared with 30.8% for ProMal and 13.9% for ForeDroid. This improvement is primarily due to a large precision gain (94.8% vs. 19.1% and 8.5%), while maintaining comparable recall to ProMal (80.9% vs. 78.9%) and substantially outperforming ForeDroid (38.5%). Although ForeDroid and ProMal generate far more candidates (1,590 and 5,664, respectively), most are spurious and do not correspond to genuine malicious behaviors, indicating that recovering lowlevel API chains or knowledge-graph operations alone is insufficient to reconstruct complete malicious behaviors. FP Analysis. Most of the 30 false positives come from thirdparty SDKs bundled in the APK. Such SDKs perform sensitive operations, such as advertising-ID collection, but P RAXIS cannot see their internal implementation and so cannot tell whether an operation is benign library functionality or part of the app’s malicious behavior. It therefore retains these sensitive operations as code-grounded evidence, which can push the verdict to malicious. A promising direction for future work is to understand these third-party SDKs more accurately, which would reduce such false positives. FN Analysis. The 118 false negatives produced by P RAXIS mostly stem from content that is loaded only at runtime, which static analysis cannot see: a page an attacker serves into a WebView, or a payload downloaded or decrypted on the fly. In these cases P RAXIS observes the loading logic, such as the WebView setup or the load call, but not the content or code that actually runs, and it is that runtime content that determines maliciousness.

TABLE III: Per-Stage Behavior Identification Performance. Metric

Generation

Confirmation

Judgement

Precision

46.5%

84.0%

96.8%

Recall

97.4%

86.2%

79.5%

F1

62.9%

85.1%

87.3%

#Candidates

4265

1519

821

TABLE IV: Ablation Study of Major Components. Configuration

Diverse-Family

Privileged-Benign

FNR

FPR

F1

FNR

FPR

F1

20.0%

1.7%

88.1%

33.7%

7.4%

83.3%

w/o Verification

9.8%

21.7%

85.1%

24.5%

47.4%

74.9%

w/o Context

95.3%

4.4%

8.7%

67.5%

1.5%

24.7%

Full Setting

11.7%

3.3%

92.2%

20.9%

13.0%

87.4%

w/o Multi-Signals

Time-Shift

Overall

2) Per-Stage Behavior Analysis: Table III shows that P RAXIS progressively refines behavior candidates across its three stages. This process sharply improves precision from 46.5% to 96.8%, while retaining 79.5% of the ground-truth behaviors. Overall, the pipeline improves F1 by 24.4 percentage points, showing that high-recall hypothesis generation can be effectively turned into precise behavior recovery through evidence confirmation and judgment. Manual inspection shows that the remaining recall loss comes from different sources at different stages. Generation misses 25 behaviors, mainly uncommon or family-specific behaviors whose signal combinations do not trigger explicit hypotheses. Confirmation removes 108 behaviors, mainly because static analysis cannot recover complete evidence chains, or because retrieval returns code that is semantically related to the hypothesis but does not contain the evidence required to support it. Judgment removes another 64 behaviors because their malicious intent is weak, ambiguous, or overshadowed by the dominant attack chain. D. Results of RQ3: Ablation Study Table IV shows that every component contributes to detection performance. First, without multiple signals to hypothesize from (w/o Multi-Signals), recall drops: the TimeShift FNR rises from 11.7% to 20.0% and the Diverse-Family FNR from 20.9% to 33.7%, because sensitive APIs alone miss behaviors that leave no sensitive-API trace, such as app uninstallation driven through the Android Intent mechanism with action ACTION DELETE. Second, without verification (w/o Verification), precision drops: the Time-Shift FPR rises from 3.3% to 21.7% and the Privileged-Benign FPR from 13.0% to 47.4%, since nothing forces the LLM’s hypotheses to be backed by executable evidence and plausible but unsupported behaviors are flagged as malicious. Third, without context-

TABLE V: Detection Performance under Different LLMs. Model

Diverse-Family

Privileged-Benign

FNR

Time-Shift FPR

F1

FNR

FPR

Overall F1

GPT-5.4-mini

8.1%

9.0%

91.0%

19.0%

22.2%

84.4%

GPT-5.2

20.0%

1.0%

88.3%

23.9%

7.4%

85.4%

DeepSeek-V4-Pro

11.7%

3.3%

92.2%

20.9%

13.0%

87.4%

aware judgment (w/o Context), recall collapses: the TimeShift FNR rises from 11.7% to 95.3%, as the judge, though still given behaviors and their evidence, cannot separate a malicious behavior from legitimate app functionality. Each stage thus guards against a distinct failure, and recovered behavior alone is not enough to decide maliciousness. E. Results of RQ4: Effectiveness and Cost Across LLMs Table V shows that all three models achieve overall F1 above 84%, indicating that P RAXIS maintains strong effectiveness across different LLMs. The models exhibit distinct effectiveness trade-offs. GPT-5.2 achieves the lowest FPR (1.0% on time-shift and 7.4% on privileged-benign) but also the highest FNR (20.0%), indicating that it adopts a more conservative decision strategy. GPT-5.4-mini shows the opposite pattern, achieving the highest recall but the highest FPR (22.2% on privileged-benign), suggesting that it is more likely to classify ambiguous behaviors as malicious. DeepSeek-V4-Pro balances these two extremes and achieves the best overall F1 (87.4%). Cost also varies substantially across models. Function summarization always runs on the fixed lightweight model (DeepSeek-V4-Flash), so its cost stays at approximately $0.56 per sample regardless of the detection model. The remaining cost is $0.04 with DeepSeek-V4-Pro, $0.29 with GPT-5.4mini, and $0.67 with GPT-5.2. Despite costing far more per judgment, GPT-5.2 does not exceed DeepSeek-V4-Pro’s F1, making DeepSeek-V4-Pro the most cost-effective of the three. V. T HREATS TO VALIDITY Our study has three threats to validity. First, our dataset may not represent all malware in the wild. To mitigate this, we collect 1,033 APKs spanning 2015 to 2026 and split them into three settings, each targeting a distinct dimension of diversity: temporal drift, behavioral coverage across 163 malware families, and functional coverage across 49 Google Play categories. Second, judging manually whether each recovered behavior is malicious is inherently subjective. To mitigate this, we ground RQ2 in public threat reports from recognized security organizations such as Kaspersky, ESET, and Cisco Talos, plus independent researchers; because such reports may omit implementation details or undocumented behaviors, our annotators also inspect the source code to confirm each behavior. We follow the dual-annotator protocol of §IV-C, reaching Cohen’s κ of 0.88 and 0.83 for behavior identification and per-stage analysis. Third, P RAXIS relies on an LLM to hypothesize, confirm, and judge behaviors, so its verdicts could vary with the choice of model and with nondeterministic decoding. To mitigate this, we decode at temperature 0 and take the majority verdict over three runs,

and our cross-model evaluation (§IV-E) shows that P RAXIS stays effective across LLMs of different capability and cost. VI. R ELATED W ORK Android Malware Detection. Android malware detection has evolved from hand-crafted static features [2], [40], [41], [42] to structural program representations [6], [3], [43], [4], [5] and LLM-based code analysis [44], [10], [9]. Early featurebased detectors [2], [41], [42] extract permissions, API calls, and other static features, and train ML classifiers to identify malicious patterns. Drebin [2] uses sparse static features with a linear SVM, while later methods such as XMal [41] and RAMDA [42] learn more discriminative or robust feature representations. However, feature-based detectors capture individual features but not the structural relations among program elements. Later detectors model API-call sequences or call-graph structure. MaMaDroid [6] abstracts API calls to package-level states and models their transitions as Markov chains. Graph-based detectors such as MalScan [3], HomDroid [15], MsDroid [4], and MaskDroid [5] further use function call graphs or sensitive-API-centered subgraphs to improve detection and robustness. Recent LLM-based detectors shift from learned representations to behavior-level reasoning. ForeDroid [10] summarizes entry-to-sink API-call chains with an LLM, trains an OCSVM on the summaries, and uses the LLM for explanation. LAMD [9] progressively summarizes multi-level backward slices around sensitive APIs to infer malicious behaviors in a training-free pipeline. Despite these advances, existing detectors provide behavioral explanations without grounding them in connected code evidence. In contrast, P RAXIS produces evidence-grounded behavior explanations together with the detection result. Malicious Behavior Understanding. Prior work has also studied how security-relevant behaviors are implemented and interpreted in APKs. Manual efforts such as Cao et al. [39] and MalRadar [45] provide high-quality behavior annotations for Android malware families, but require extensive expert reverse engineering. ProMal [35] reduces manual effort by using an expert-built knowledge graph to interpret malware behaviors from API-level evidence. However, it assumes a known malware as input, and its knowledge graph is constructed at a coarse granularity around APIs and parameters rather than complete behaviors. Moreover, the knowledge graph is not automatically updated from newly analyzed malware. InconPreter [46] analyzes UI-triggered API chains to explain risky behaviors and expose inconsistencies between claimed and implemented functionality. However, it remains API-chaincentric rather than recovering complete malicious behaviors. VII. C ONCLUSION We present P RAXIS, an Android malware detection framework that recovers evidence-grounded malicious behaviors beyond binary detection. Across three challenging evaluation settings, P RAXIS achieves 87.4% overall F1, outperforming the strongest baseline by 18.6 percentage points. Its recovered behavior records match ground-truth malicious behaviors at

87.3% F1, a substantial gain over the state-of-the-art baseline at 30.8%. P RAXIS remains effective across three LLMs, demonstrating that its behavior-oriented reasoning generalizes across different foundation models. R EFERENCES [1] WeLiveSecurity, ESET, “It threat evolution in q1 2026. mobile statistics,” https://securelist.com/malware-report-q1-2026-mobile-statistics/ 119819/, 2026, accessed: 2026-05-01. [2] D. Arp, M. Spreitzenbarth, M. Hubner, H. Gascon, K. Rieck, and C. Siemens, “Drebin: Effective and explainable detection of android malware in your pocket.” in Network and Distributed System Security Symposium (NDSS), vol. 14, 2014, pp. 23–26. [3] Y. Wu, X. Li, D. Zou, W. Yang, X. Zhang, and H. Jin, “Malscan: Fast market-wide mobile malware scanning by social-network centrality analysis,” in 2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2019, pp. 139–150. [4] Y. He, Y. Liu, L. Wu, Z. Yang, K. Ren, and Z. Qin, “Msdroid: Identifying malicious snippets for android malware detection,” IEEE Transactions on Dependable and Secure Computing, vol. 20, no. 3, pp. 2025–2039, 2022. [5] J. Zheng, J. Liu, A. Zhang, J. Zeng, Z. Yang, Z. Liang, and T.-S. Chua, “Maskdroid: Robust android malware detection with masked graph representations,” in Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering, 2024, pp. 331–343. [6] L. Onwuzurike, E. Mariconti, P. Andriotis, E. D. Cristofaro, G. Ross, and G. Stringhini, “Mamadroid: Detecting android malware by building markov chains of behavioral models (extended version),” ACM Transactions on Privacy and Security (TOPS), vol. 22, no. 2, pp. 1–34, 2019. [7] F. Pendlebury, F. Pierazzi, R. Jordaney, J. Kinder, and L. Cavallaro, “{TESSERACT}: Eliminating experimental bias in malware classification across space and time,” in 28th USENIX security symposium (USENIX Security 19), 2019, pp. 729–746. [8] W. Yang, X. Xiao, B. Andow, S. Li, T. Xie, and W. Enck, “Appcontext: Differentiating malicious and benign mobile app behaviors using context,” in 2015 IEEE/ACM 37th IEEE international conference on software engineering, vol. 1. IEEE, 2015, pp. 303–313. [9] X. Qian, X. Zheng, Y. He, S. Yang, and L. Cavallaro, “Lamd: Contextdriven android malware detection and classification with llms,” in 2025 IEEE Security and Privacy Workshops (SPW). IEEE, 2025, pp. 126– 136. [10] J. Li, S. Chen, C. Wu, Y. Zhang, and L. Fan, “Foredroid: Scenarioaware analysis for android malware detection and explanation,” in Proceedings of the 2025 ACM SIGSAC Conference on Computer and Communications Security, 2025, pp. 1379–1393. [11] P. He, Y. Xia, X. Zhang, and S. Ji, “Efficient query-based attack against ml-based android malware detection under zero knowledge setting,” in Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security (CCS), 2023, pp. 90–104. [12] H. Li, Z. Cheng, B. Wu, L. Yuan, C. Gao, W. Yuan, and X. Luo, “Blackbox adversarial example attack towards fcg based android malware detection under incomplete feature information,” in 32nd USENIX Security Symposium (USENIX), 2023, pp. 1181–1198. [13] S. Song, X. Xie, R. Feng, Q. Guo, and S. Chen, “Fcghunter: Towards evaluating robustness of graph-based android malware detection,” IEEE Transactions on Software Engineering, 2025. [14] J. Samhi, L. Li, T. F. Bissyandé, and J. Klein, “Difuzer: Uncovering suspicious hidden sensitive operations in android apps,” in Proceedings of the 44th International Conference on Software Engineering, 2022, pp. 723–735. [15] Y. Wu, D. Zou, W. Yang, X. Li, and H. Jin, “Homdroid: detecting android covert malware by social-network homophily analysis,” in Proceedings of the 30th acm sigsoft international symposium on software testing and analysis, 2021, pp. 216–229. [16] M. H. Ali, “Technical analysis of irata android malware,” https:// muha2xmad.github.io/malware-analysis/irata/, 2022, accessed: 2026-0501. [17] S. Arzt, S. Rasthofer, C. Fritz, E. Bodden, A. Bartel, J. Klein, Y. Le Traon, D. Octeau, and P. McDaniel, “Flowdroid: Precise context, flow, field, object-sensitive and lifecycle-aware taint analysis for android apps,” ACM sigplan notices, vol. 49, no. 6, pp. 259–269, 2014.

[18] C. Liu, H. Wang, T. Liu, D. Gu, Y. Ma, H. Wang, and X. Xiao, “Promal: precise window transition graphs for android via synergy of program analysis and machine learning,” in Proceedings of the 44th International Conference on Software Engineering, 2022, pp. 1755–1767. [19] R. Vallée-Rai, P. Co, E. Gagnon, L. Hendren, P. Lam, and V. Sundaresan, “Soot: A java bytecode optimization framework,” in CASCON first decade high impact papers, 2010, pp. 214–224. [20] National Security Agency, “Ghidra software reverse engineering framework,” https://github.com/nationalsecurityagency/ghidra, 2026, accessed: 2026-05-01. [21] J. Samhi, J. Gao, N. Daoudi, P. Graux, H. Hoyez, X. Sun, K. Allix, T. F. Bissyandé, and J. Klein, “Jucify: A step towards android code unification for enhanced static analysis,” in Proceedings of the 44th International Conference on Software Engineering, 2022, pp. 1232–1244. [22] N. Xi, Y. Zhang, P. Feng, S. Ma, J. Ma, Y. Shen, and Y. Yang, “Gnndroid: Graph-learning based malware detection for android apps with native code,” IEEE Transactions on Dependable and Secure Computing, vol. 22, no. 2, pp. 1460–1476, 2024. [23] A. Ruggia, A. Possemato, S. Dambra, A. Merlo, S. Aonzo, and D. Balzarotti, “The dark side of native code on android,” ACM Transactions on Privacy and Security, vol. 28, no. 2, pp. 1–33, 2025. [24] Z. Ma, H. Wang, Y. Guo, and X. Chen, “Libradar: Fast and accurate detection of third-party libraries in android apps,” in Proceedings of the 38th international conference on software engineering companion, 2016, pp. 653–656. [25] N. Reimers and I. Gurevych, “Sentence-bert: Sentence embeddings using siamese bert-networks,” in Proceedings of the 2019 conference on empirical methods in natural language processing and the 9th international joint conference on natural language processing (EMNLPIJCNLP), 2019, pp. 3982–3992. [26] S. Robertson and H. Zaragoza, The probabilistic relevance framework: BM25 and beyond. Now Publishers Inc, 2009, vol. 4. [27] L. Li, A. Bartel, T. F. Bissyandé, J. Klein, Y. Le Traon, S. Arzt, S. Rasthofer, E. Bodden, D. Octeau, and P. McDaniel, “Iccta: Detecting inter-component privacy leaks in android apps,” in 2015 IEEE/ACM 37th IEEE International Conference on Software Engineering, vol. 1. IEEE, 2015, pp. 280–291. [28] M. Christodorescu, S. Jha, and C. Kruegel, “Mining specifications of malicious behavior,” in Proceedings of the the 6th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering, 2007, pp. 5–14. [29] M. Fredrikson, S. Jha, M. Christodorescu, R. Sailer, and X. Yan, “Synthesizing near-optimal malware specifications from suspicious behaviors,” in 2010 IEEE Symposium on Security and Privacy. IEEE, 2010, pp. 45–60. [30] J. Yan, S. Zhang, Y. Liu, J. Yan, and J. Zhang, “Iccbot: fragmentaware and context-sensitive icc resolution for android applications,” in Proceedings of the ACM/IEEE 44th international conference on software engineering: companion proceedings, 2022, pp. 105–109. [31] S. Xi, S. Yang, X. Xiao, Y. Yao, Y. Xiong, F. Xu, H. Wang, P. Gao, Z. Liu, F. Xu et al., “Deepintent: Deep icon-behavior learning for detecting intention-behavior discrepancy in mobile apps,” in Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, 2019, pp. 2421–2436. [32] J. Li, J. Liu, J. Mao, J. Zeng, and Z. Liang, “Ui-ctx: Understanding ui behaviors with code contexts for mobile applications.” in NDSS, 2025. [33] C. Gao, G. Huang, H. Li, B. Wu, Y. Wu, and W. Yuan, “A comprehensive study of learning-based android malware detectors under challenging environments,” in Proceedings of the 46th IEEE/ACM International Conference on Software Engineering (ICSE), 2024, pp. 1–13. [34] J. Liu, J. Zeng, F. Pierazzi, Z. Yang, L. Cavallaro, and Z. Liang, “Unraveling the key of machine learning-based android malware detection,” ACM Transactions on Software Engineering and Methodology, 2026. [35] C. Wu, S. Chen, J. Li, R. Chai, L. Fan, X. Xie, and R. Feng, “Beyond decision: Android malware description generation through profiling malicious behavior trajectory,” ACM transactions on software engineering and methodology, vol. 34, no. 7, pp. 1–39, 2025. [36] K. Allix, T. F. Bissyandé, J. Klein, and Y. Le Traon, “Androzoo: Collecting millions of android apps for the research community,” in Proceedings of the 13th international conference on mining software repositories, 2016, pp. 468–471. [37] VirusTotal, “Virustotal,” https://www.virustotal.com, accessed: 2026-0501.

[38] abuse.ch, “Malwarebazaar,” https://bazaar.abuse.ch/, 2026, accessed: 2026-05-01. [39] M. Cao, K. Ahmed, and J. Rubin, “Rotten apples spoil the bunch: an anatomy of google play malware,” in Proceedings of the 44th International Conference on Software Engineering, 2022, pp. 1919– 1931. [40] J. Garcia, M. Hammad, and S. Malek, “Lightweight, obfuscationresilient detection and family identification of android malware,” ACM Transactions on Software Engineering and Methodology (TOSEM), vol. 26, no. 3, pp. 1–29, 2018. [41] B. Wu, S. Chen, C. Gao, L. Fan, Y. Liu, W. Wen, and M. R. Lyu, “Why an android app is classified as malware: Toward malware classification interpretation,” ACM Transactions on Software Engineering and Methodology (TOSEM), vol. 30, no. 2, pp. 1–29, 2021. [42] H. Li, S. Zhou, W. Yuan, X. Luo, C. Gao, and S. Chen, “Robust android malware detection against adversarial example attacks,” in Proceedings of the Web Conference 2021, 2021, pp. 3603–3612. [43] X. Zhang, Y. Zhang, M. Zhong, D. Ding, Y. Cao, Y. Zhang, M. Zhang, and M. Yang, “Enhancing state-of-the-art classifiers with api semantics to detect evolved android malware,” in Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security (CCS), 2020, pp. 757–770. [44] W. Zhao, J. Wu, and Z. Meng, “Apppoet: Large language model based android malware detection via multi-view prompt engineering,” Expert Systems with Applications, vol. 262, p. 125546, 2025. [45] L. Wang, H. Wang, R. He, R. Tao, G. Meng, X. Luo, and X. Liu, “Malradar: Demystifying android malware in the new era,” Proceedings of the ACM on Measurement and Analysis of Computing Systems, vol. 6, no. 2, pp. 1–27, 2022. [46] C. Yue, K. Chen, Z. Guo, J. Dai, X. Sun, and Y. Yang, “What’s done is not what’s claimed: Detecting and interpreting inconsistencies in app behaviors.” in NDSS, 2025.