PADRAIG on arXiv: model-based automated input generation for Android apps

What happened on 31 July

On 31 July 2026 at 19:20 UTC, v1 of PADRAIG: Precise Android Automated Input Generation was submitted to arXiv. Note that the arXiv journal reference shows it was published at QRS 2024, so this was a posting of earlier work rather than new research. PADRAIG builds a detailed control-flow model of the app under test to generate inputs. Per the abstract, on 19 randomly selected F-Droid apps it achieved on average 16% more line coverage than three state-of-the-art tools while cutting test-generation time by 84%. The same authors posted DroidGraph that day (originally DSA 2023), which combines static analysis with systematic exploratory tests and on average interacted with 18% more of each app than random exploration.

What it means for defenders

Both works aim at automated testing, but they also illustrate a protection-relevant fact: with a model derived from static analysis, automated tools can reach more screens and code paths more efficiently than random tapping. For developers, this means features hidden behind deep menus, long-press gestures or specific states are not safe; if the code ships, it may be reached systematically, including leftover debug panels, unreleased features or internal switches. The evaluation uses open-source F-Droid apps, and the abstracts do not discuss obfuscated apps, so the coverage numbers should not be extrapolated. The same techniques are equally valuable to defenders for testing their own apps.

Checks you can run

First, check whether release builds still contain code for debug panels, hidden entry points or unreleased features; remove what can be removed at compile time, and gate feature switches that must remain from the server per account. Second, run automated UI exploration on the obfuscated or hardened build to confirm the transformation did not break rarely visited screens or callbacks. Third, compare the list of screens reached by automated exploration with what the product intends to expose, and treat any unexpectedly reachable screen as an issue to fix. Repeat this comparison for every major release.

Your checklist

• Remove debug panels and unreleased feature code from release builds
• Run automated UI exploration on the hardened build
• Compare reachable screens with what the product intends to expose