This site is called Measure The Web, and a large part of what it documents transfers directly to mobile: you still need a sampling frame, a vantage point, a classifier and a story about what you did not observe. But four things change enough to break a web-trained intuition, and this page is about those four.

1. The population lives behind a store, not a DNS name. You cannot just fetch an app the way you fetch a URL. Getting 10,000 APKs is a research task with its own tooling, its own terms of service and its own reproducibility problem.
2. You get two incompatible views of the same app. Static analysis of the binary sees code that may never run; dynamic analysis sees only the code your driver managed to reach. Neither is the app, and the field's own measurements of the gap are unflattering.
3. The app has to be driven. A web crawler loads a URL and the page happens. An app shows you a login wall, an onboarding carousel and a consent dialog, and if you do not get through them you have measured the splash screen.
4. The app can refuse to be watched. Certificate pinning, root and emulator detection, packing and native code are all deployed in the wild, and they are the reason a mobile traffic measurement has a coverage number where a web crawl has none.

Everything on this page about “the literature” is a claim about seven venues — CCS, IMC, NDSS, PETS, USENIX Security, TheWebConf and IEEE S&P, 2010–2026, 5,859 papers with extracted full text. Mobile-app work is also published at mobile-systems and software-engineering venues (MobiSys, MobiCom, MSR, ICSE, ASE) and at usable-security venues (SOUPS), none of which are in the corpus, so treat the counts as “how these seven security and privacy venues do mobile”, not as the state of mobile research.¹⁾ See Corpus.

Two different slices of the corpus are relevant, and they answer different questions:

The gap matters. mobilePlat also contains cellular-network measurement, Bluetooth-tracker security, smartphone user studies and handset firmware work — all legitimately “mobile”, none of them app analysis. Every figure on this page is on appAnalysis (N=529) unless it says otherwise, because that is the population a reader planning an app measurement belongs to.

Two more signals overlap it heavily but not completely: 364 papers name a tool the extraction classified as mobile-instrumentation (32 of them outside both slices above), and 502 papers draw a population whose unit is mobile-apps (24 outside both). If you are searching the literature yourself, none of these three queries alone finds everything.

Where the work is published, as a share of each venue's own output: PETS 12.9% (66 of 510), NDSS 11.7% (82 of 701), CCS 10.7% (106 of 990), USENIX Security 10.1% (143 of 1,410), IEEE S&P 8.2% (63 of 767), IMC 5.0% (32 of 638), TheWebConf 4.4% (37 of 843). PETS and NDSS are where a mobile privacy measurement most often lands; IMC and TheWebConf, the two most web-flavoured venues here, publish the least of it.

There are four routes and they are not equivalent.

The official Google Play Developer (Android Publisher) API cannot fetch other developers' APKs. It is scoped to apps you publish. There is no sanctioned bulk-download path, which is why every large Android study in the corpus uses AndroZoo, an unofficial scraper, or a mirror.

Scraper currency, checked 2026-08-27:

On terms of service: the Play-specific terms do not carry a blanket anti-scraping clause; the relevant text is in Google's general Terms of Service, and its current wording is conditioned on machine-readable instructions — it prohibits “using automated means to access content from any of our services in violation of the machine-readable instructions on our web pages (for example, robots.txt files that disallow crawling, training, or other activities)”.⁹⁾ That is narrower than the blanket prohibition older papers quote, and it means play.google.com/robots.txt is a document your ethics section should actually have read. Only 8 of 529 appAnalysis papers mention store terms of service anywhere near a word about scraping or downloading. This is a reporting gap, not evidence that the field has concluded it is fine.

Harder, and the corpus shows it: of 529 appAnalysis papers, 39 match only iOS patterns and 66 match both, against 369 Android-only.¹⁰⁾ Decrypting a store IPA requires a device that will let you dump the decrypted binary, which historically meant a jailbreak.

Because a jailbreak is tied to specific hardware and firmware, an iOS measurement is implicitly a measurement of whatever devices you could jailbreak, and that is a sampling statement you owe the reader: model, iOS version, and jailbreak.

One structural change since 2024 that redefines the iOS population: in the EU, “the App Store” is no longer the only channel. Apple's own documentation states that “users in the EU can install notarized iOS and iPadOS apps from alternative app marketplaces or directly from an authorized developer's website”, with further changes to eligibility and fees effective 1 October 2026.¹⁶⁾ A 2026 iOS study sampling only the App Store is sampling one distribution channel out of three in the EU, and should say so. [4Liu, Yijing; Zhang, Yiming; Liu, Baojun; Duan, Haixin (2026): "Cracks in the Walled Garden: Dissecting the Gray-Market of Unauthorized iOS App Distribution via Ad Hoc Sideloading", in: Proceedings of the USENIX Security Symposium. (Link)] is the corpus's closest look at unauthorised iOS distribution.

App store listings, availability, rankings, prices and privacy labels are per-country. So is the app binary in some cases. A study that scraped “the top 500 free apps” without saying from which storefront has not specified its sample — the equivalent of not naming your ranking list on the web side (Website selection).

The corpus is bad at this. Of 529 appAnalysis papers, 430 have at least one vantage tuple, and only 117 of those 430 (27.2%) state a location at all; 313 (72.8%) produce only a not-stated sentinel. [5Kumar, Renuka; Virkud, Apurva; Sundara Raman, Ram; Prakash, Atul; Ensafi, Roya (2022): "A Large-scale Investigation into Geodifferences in Mobile Apps", in: Proceedings of the USENIX Security Symposium. (Link)] is the paper to read on why it matters: geodifferences in mobile apps are real and measurable.

An app is a moving target in a way a URL is not: the developer ships a new build weekly, and the store deletes apps constantly. [6Lin, Fuqi; Wang, Haoyu; Wang, Liu; Liu, Xuanzhe (2021): "A Longitudinal Study of Removed Apps in iOS App Store", in: Proceedings of the ACM Web Conference. (DOI)] recorded 1,129,615 removal records covering 1,033,488 distinct apps in the iOS App Store, with a median 28.5 days between removal peaks, and 5% of removed apps had at one point ranked in the top 1500 of a category. [7Wang, Haoyu; Li, Hao; Guo, Yao (2019): "Understanding the Evolution of Mobile App Ecosystems: A Longitudinal Measurement Study of Google Play", in: Proceedings of the ACM Web Conference. (DOI)] found roughly 61% of long-lasting Google Play apps received no update at all across their observation window — so churn is concentrated, not uniform.

That means an app set is only reproducible if you publish package name plus version code plus the SHA-256 of the APK/IPA you analysed, and the fetch date. In the corpus, 400 appAnalysis papers draw a population whose unit is mobile-apps; 222 of them (55.5%) state a version or date for at least one of those populations, and at the tuple level only 393 of 930 (42.3%) do. Nearly half of the mobile-app populations in these seven venues cannot be reconstructed.

How big are these samples? Of the 397 papers stating an n for a mobile-apps population (916 tuples): median 1,300, 10th percentile 17, 90th percentile 329,272, max 65,000,000. Papers commonly have several sets at once — a large statically-analysed set and a small dynamically-analysed or hand-audited one:

Static analysis is how the field does scale: 225 of 529 appAnalysis papers (42.5%) name at least one static-analysis or reverse-engineering tool, and that share has been flat at 41–44% across all four era windows (2010–2015, 2016–2020, 2021–2024, 2025–2026). It is not fashion; it is the only way to touch a million apps.

The current toolchain, with the share of the 529 that used each (folded — see Methodology and limitations of these figures):

This is the most important thing on this page for anyone about to write “we used FlowDroid to find data leaks”.

[9Bonett, Richard; Kafle, Kaushal; Moran, Kevin; Nadkarni, Adwait; Poshyvanyk, Denys (2018): "Discovering Flaws in Security-Focused Static Analysis Tools for Android using Systematic Mutation", in: Proceedings of the USENIX Security Symposium. (Link)] (μSE) injected 7,584 synthetic data leaks into real apps, filtered to 2,026 that were verified executable at runtime, and ran three well-known Android leak detectors over them. FlowDroid missed over 48% of them. Argus missed over 73%. DroidSafe missed over 4%. The analysis also surfaced 13 flaws in FlowDroid documented neither in its paper nor in its repository. [10Pauck, Felix; Bodden, Eric; Wehrheim, Heike (2018): "Do Android taint analysis tools keep their promises?", in: Proceedings of the 26th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering. (DOI)] reached a compatible conclusion by a different route, reproducing published taint-analysis benchmarks.

Two consequences:

• A static count is a lower bound on the behaviour and an upper bound on the executed behaviour, simultaneously. It misses flows it cannot resolve (reflection, JNI, dynamic loading) and reports flows that never execute.
• You must validate, on your own data. In the corpus, of the 472 appAnalysis papers that classified anything, 79 (16.7%) report no validation of any classifier they used, but only 178 (37.7%) validated every classifier they used — 218 papers (46.2%) have at least one classifier with none-reported. 321 (68.0%) report some manual validation. Manual validation of a sample is cheap and is the single easiest thing a reviewer will ask you for.

Obfuscation and native code are the other half of the problem and they are widespread: 144 of 529 papers mention native code, JNI or the NDK; 85 mention packing or unpacking; 29 name ProGuard, R8 or DexGuard. [11Schmidt, David; Tagliaro, Carlotta; Borgolte, Kevin; Lindorfer, Martina (2023): "IoTFlow: Inferring IoT Device Behavior at Scale through Static Mobile Companion App Analysis", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)] ran APKiD to detect packers precisely so it could report which apps its static analysis could not reach.

Dynamic analysis has grown from a niche to a norm. Split by what a paper actually instruments:

2025–2026 is provisional: CCS 2026 and IMC 2026 have not been held, and IEEE S&P 2026 and TheWebConf 2026 are under-selected because selection screens on abstracts that are not yet in OpenAlex. Read the last column as a direction, not a level.

Both appear; the corpus does not report the choice well. Probes over the 529 full texts: 109 say “physical device” or “real device” (or phone/smartphone/handset), 51 name an Android emulator product or phrase, and only 25 state plainly that they ran on an emulator. Emulator use as a share of the named tool families has fallen — 8.0% of 2010–2015 papers named an emulator against 1.1% of 2025–2026 — and the plausible explanation is that apps detect emulators — 15 papers mention emulator detection and 35 mention root detection, SafetyNet or Play Integrity — though the corpus cannot establish the causal link, only the co-occurrence.

The relevant platform fact: SafetyNet Attestation “was deprecated in 2022 and fully turned down in January 2025”, and the Play Integrity API is its sole replacement.²⁵⁾ An app checking device integrity in 2026 is calling Play Integrity, which reports on the device, the app's own integrity and the account — so a rooted handset and an emulator both fail it. If your target apps gate behaviour on integrity, say what you did about it.

A web crawl's interaction depth is a knob (Interaction). An app's is a research problem. The drivers in use:

Only 48 of 529 papers report any coverage measure, and 30 (5.7%) combine a UI driver with traffic interception — the “drive it and watch the wire” pipeline that a privacy measurement actually needs. When coverage is measured, the gap is large: [9Bonett, Richard; Kafle, Kaushal; Moran, Kevin; Nadkarni, Adwait; Poshyvanyk, Denys (2018): "Discovering Flaws in Security-Focused Static Analysis Tools for Android using Systematic Mutation", in: Proceedings of the USENIX Security Symposium. (Link)] could only confirm 2,026 of 7,584 injected leaks as executable using GUI exploration, and [12Lin, Hongyu; Hu, Yicheng; Xu, Haitao; Lu, Yanchen; Ren, Mengxia; Hao, Shuai; Yue, Chuan; Li, Zhao; Zhang, Fan; Jiang, Yixin (2026): "ChameleoScan: Demystifying and Detecting iOS Chameleon Apps via LLM-Powered UI Exploration", in: Proceedings of the Network and Distributed System Security Symposium. (Link)] needed an LLM to get through the UI at all — it reports resolving 85.96% of intrusive ads and 95.56% of pop-ups blocking its exploration, and found distracting elements on 19.21% of the pages it visited.

The two systematic reviews to read before building a driver are [13Kong, Pingfan; Li, Li; Gao, Jun; Liu, Kui; Bissyandé, Tegawendé F.; Klein, Jacques (2019): "Automated Testing of Android Apps: A Systematic Literature Review", IEEE Transactions on Reliability 68(1):45-66. (DOI)] on automated Android testing (2019) and [14Li, Li; Bissyandé, Tegawendé F.; Papadakis, Mike; Rasthofer, Siegfried; Bartel, Alexandre; Octeau, Damien; Klein, Jacques; Traon, Le (2017): "Static analysis of Android apps: A systematic literature review", Information and Software Technology 88:67-95. (DOI)] on static analysis (2017). Both are outside these seven venues, and both are old enough that they predate Frida's adoption and every LLM-based method — read them for the taxonomy of approaches, not for the tool list.

To see an app's traffic you terminate its TLS at a proxy you control. Four things stand between you and that, in order.

1. The app must trust your CA. Since Android 7.0 (API level 24) — 2016 — the default trust anchors for an app are system CAs only. Android's own documentation gives the defaults verbatim: apps targeting “Android 6.0 (API level 23) and lower” get <certificates src="system" /> and <certificates src="user" />; apps targeting “Android 7.0 (API level 24) to Android 8.1 (API level 27)” get system only.²⁸⁾ Installing your root as a user certificate therefore does nothing for any modern app. Your options are to install it as a system CA (root plus Magisk, or a modified system image), or to repackage the app with a Network Security Configuration that trusts user CAs, or to hook the validation.

Two footnotes worth knowing. Android's debug-overrides block is exempt from pinning — “certificate pinning is not performed when the server's certificate chain uses one of these debug-only trust anchors” — but it applies only when android:debuggable is true, so it is a repackaging technique, not a shortcut. And Certificate Transparency enforcement, which is the newer platform mechanism in this area, is scoped to “publicly-trusted TLS certificates”;²⁹⁾ a locally-installed interception root is not publicly trusted, so CT is not, on the documentation's own wording, an additional barrier to interception. Android 16 is the current stable release and Android 17 (API 37) is in beta as of 2026-08-27.³⁰⁾

2. The app may pin anyway. This is where the honest numbers live. [3Pradeep, Amogh; Paracha, Muhammad Talha; Bhowmick, Protick; Davanian, Ali; Razaghpanah, Abbas; Chung, Taejoong; Lindorfer, Martina; Vallina-Rodriguez, Narseo; Levin, Dave; Choffnes, David (2022): "A Comparative Analysis of Certificate Pinning in Android & iOS", in: Proceedings of the ACM Internet Measurement Conference. (DOI)] is the reference measurement, and it separates potential from actual pinning, which almost nothing else does:

Read the last row twice. With the standard toolchain, roughly half of pinned destinations on Android stayed dark. Any traffic measurement over a large app set has a hole of this shape, and the number is not zero.

Other measurements triangulate the prevalence, and they disagree because they measure different things over different populations — which is the point:

• [16Oltrogge, Marten; Huaman, Nicolas; Klivan, Sabrina; Acar, Yasemin; Backes, Michael; Fahl, Sascha (2021): "Why Eve and Mallory Still Love Android: Revisiting TLS (In)Security in Android Applications", in: Proceedings of the USENIX Security Symposium. (Link)]: of 1,335,322 free Play apps, 99,212 shipped a custom Network Security Configuration; of those, 88,174 (88.87%) downgraded security relative to the defaults, and only 663 used NSC pinning. Separately, 8,606 apps deliberately re-enabled trust in user-installed CAs — those are the apps you can still MITM with a user cert. Mind the denominator: the paper reports this as “8.67%”, which is the share of the 99,212 apps with a custom NSC, not of the 1,098,479 apps targeting Android 7+ that the same sentence names (that share is 0.78%). Both numbers are in the paper; only one of them is 8.67%.
• [11Schmidt, David; Tagliaro, Carlotta; Borgolte, Kevin; Lindorfer, Martina (2023): "IoTFlow: Inferring IoT Device Behavior at Scale through Static Mobile Companion App Analysis", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)]: 385 of 9,889 IoT companion apps (3.89%) used pinning, detected from the NSC.
• [17Pourali, Sajjad; Yu, Xiufen; Zhao, Lianying; Mannan, Mohammad; Youssef, Amr (2024): "Racing for TLS Certificate Validation: A Hijacker's Guide to the Android TLS Galaxy", in: Proceedings of the USENIX Security Symposium. (Link)]: pinning is not the only failure mode. 1,529 of 2,765 (55.3%) Chinese-store apps had at least one of four certificate-validation defects, against 322 of 5,061 (6.4%) Play apps — so which store you sampled changes the answer by nearly an order of magnitude.

3. Your bypass tools must still work. Currency, checked 2026-08-27:

4. You have to report what you lost. Only 13 of 529 papers mention the Network Security Configuration at all; 71 (13.4%) mention pinning; 33 describe bypassing it. Given that traffic interception appears in 110 papers, most papers that intercepted traffic never wrote down what they could not intercept.

Once you can see an app, what does the literature look at? Classification targets, of the 529:

And by method (of the 472 papers that classified something):

Some measured results worth knowing before you re-measure them:

• Third-party SDKs are near-universal and the reported figure depends entirely on the detector. [18Kollnig, Konrad; Shuba, Anastasia; Binns, Reuben; Van Kleek, Max; Shadbolt, Nigel (2022): "Are iPhones Really Better for Privacy? A Comparative Study of iOS and Android Apps", Proceedings on Privacy Enhancing Technologies 2022(2):6-24. (DOI)], over random samples of 12,000 apps per platform, found 88.73% of Android and 79.35% of iOS apps contained at least one tracking library, and 81.44% / 68.46% contacted a tracking domain at startup. [19Rodriguez, David; Calandrino, Joseph A.; Del Alamo, Jose M.; Sadeh, Norman (2025): "Privacy Settings of Third-Party Libraries in Android Apps: A Study of Facebook SDKs", Proceedings on Privacy Enhancing Technologies 2025(2):173-187. (DOI)] found 53.68% of its Android sample embedded at least one Facebook SDK and only 6.79% had disabled the SDK's advertiser-ID collection from its privacy-hostile default.
• Pre-consent transmission in apps is the mobile analogue of the web's pre-consent cookie result. [15Koch, Simon; Altpeter, Benjamin; Johns, Martin (2023): "The OK Is Not Enough: A Large Scale Study of Consent Dialogs in Smartphone Applications", in: Proceedings of the USENIX Security Symposium. (Link)]: 3,013 of 3,654 analysed apps (82.5%) contacted a monitored tracking endpoint before any interaction, 1,285 (35.2%) sent a unique identifier, and only 146 (4.0%) set any TCF string — so a TCF-based methodology (TCF consent strings) covers almost nothing on mobile. See also [20Nguyen, Trung Tin; Backes, Michael; Marnau, Ninja; Stock, Ben (2021): "Share First, Ask Later (or Never?) Studying Violations of GDPR's Explicit Consent in Android Apps", in: Proceedings of the USENIX Security Symposium. (Link)] and [21Nguyen, Trung Tin; Backes, Michael; Stock, Ben (2022): "Freely Given Consent?: Studying Consent Notice of Third-Party Tracking and Its Violations of GDPR in Android Apps", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)].
• Store-declared privacy is a measurable artefact and it is wrong a lot. [22Khandelwal, Rishabh; Nayak, Asmit; Chung, Paul; Fawaz, Kassem (2024): "Unpacking Privacy Labels: A Measurement and Developer Perspective on Google's Data Safety Section", in: Proceedings of the USENIX Security Symposium. (Link)]: 46.8% of Play apps had a Data Safety entry as of 31 May 2023; 40% changed it at least once across ten snapshots between June 2022 and May 2023; and of a subset of popular apps declaring no data sharing, 42% shipped an advertising or analytics library. Only 55 of 529 corpus papers mention privacy labels or Data Safety at all — this is under-measured relative to how easy it is to scrape.
• Static and dynamic views of the same app genuinely diverge. [11Schmidt, David; Tagliaro, Carlotta; Borgolte, Kevin; Lindorfer, Martina (2023): "IoTFlow: Inferring IoT Device Behavior at Scale through Static Mobile Companion App Analysis", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)] compared both on the 13 apps whose physical IoT devices it had, and got 54 domains and 281 paths statically against 40 domains and 160 paths dynamically — static found more, because dynamic could not reach it. Do not assume the dynamic view is the ground truth; it is a different lower bound.

Everything in this section is over appAnalysis (N=529 papers), from data/extract/run1 as of 2026-08-27.

Tooling, folded into families. Full table and per-era breakdown in the report script output on mobile_and_app_measurement.

Era denominators: 88 / 157 / 194 / 90 papers. 2025–2026 is provisional.

Where the population came from. sourceList is free text and unstable, so the raw table undercounts badly: the largest single string is “Google Play” at 134 papers, but merging the 62 spellings that name Google Play (including its pre-2012 name, “Android Market”) gives 250 papers — 47.3% of the 529, an 87% increase over the raw figure. The alias list and every merged spelling are on the provenance page.

How the sample was drawn, for the 400 papers with a mobile-apps population: purposive 196 (49.0%), top-n 140 (35.0%), random 91 (22.8%), pre-existing-dataset 71 (17.8%), exhaustive 51 (12.8%), seed-and-crawl 38 (9.5%), convenience 35 (8.8%), stratified 28 (7.0%). Multi-valued, so shares do not sum to 100%. “Top-n of a store chart” is the mobile equivalent of “Alexa top 1M” and inherits every objection on Website selection plus one more: the chart is per-country and per-day and there is no Tranco for it.

Where the field goes quiet, each against its own denominator:

Full-text probes over the same 529 papers, whitespace collapsed and hyphenation rejoined. These count papers that mention a thing, which is an upper bound on doing it and a lower bound on nothing:

• Every table names its own denominator, and appAnalysis (529) is not mobile (1,075) and neither is 5,859. A percentage without one of these three attached is a mistake.
• Sentinels are never counted as answers. not-stated and none-mentioned are reported as themselves; the “states a value” column is what remains.
• Papers are counted, never tuples. A paper naming Frida five times is one paper.
• Free-text names are folded, because tools[].name agrees run-to-run on only about 20% of exact strings. The fold is a targeted one: it defines families for mobile-specific tooling and deliberately leaves general-purpose tools (Python, VirusTotal, Chrome) unmapped. It maps 921 of 3,306 “used” tool tuples (27.9%); the residue is 2,385 tuples across 1,732 distinct names and is printed in full on the provenance page. Folding changes the answer materially — adb goes from 28 papers under its largest single spelling to 71 folded, across 11 spellings.
• Probe regex width decides the number. A case-insensitive probe for “Xposed” returns 256 papers because it matches the word “exposed”; the case-sensitive probe returns 40. The same correction takes “mentions an LLM” from 167 to 42 and “App Store” from 243 to 142. Every probe on this page is the narrow, case-sensitive form, and the wide variants are published alongside on the provenance page so you can see the difference.
• The Android/iOS split is a regex over metadata, not a read of 529 papers. It is published because “the corpus is mostly Android” is worth knowing and a crude number beats no number, but do not quote it to three significant figures.
• crawlConfig barely applies here. Only 115 of 529 appAnalysis papers have one, and within those, statefulness is stated by 10 and headlessness by 12. That is a schema shaped for web crawls meeting a mobile population, not a finding about mobile methodology. The mobile analogues — device or emulator, root state, account state, storefront — have no field, which is why this page uses full-text probes for them.
• 2026 is provisional and 2025 is thin at the edges. CCS 2026 and IMC 2026 have not been held; IEEE S&P 2026 and TheWebConf 2026 are under-selected by construction. Any claim resting on the 2025–2026 column rests on 90 papers.
• Corpus-wide caveats, including the extraction's own error rates and the venues that are absent, are on Corpus.
• The full query log, the report script and its unedited output, the fold and its complete residue, the quotes spot-checked, and the external sources accepted and rejected are at mobile_and_app_measurement.

Read as of 2026-08. The corpus rewards whatever was fashionable mid-window, so every row here is dated against evidence rather than against a general impression.

The summary: instrumentation has modernised and reporting has not. Frida, Magisk, jadx, Appium and mitmproxy are a genuinely good 2026 toolchain, and adoption is rising fast. The things that would make a mobile measurement checkable — the storefront, the app hashes, the decryption coverage, the classifier validation — are stated by between a quarter and a half of papers, and have not improved.

A methods section that survives review needs:

1. The store, the storefront country, and the date. Play or App Store or a named alternative; which country's storefront; which day. If the account, device and network regions differ from the storefront, list all four.
2. The app list, as package name + version code + binary hash. Publish it as an artefact (Artifacts). “The top 1,000 free apps” is not a sample anyone can reconstruct.
3. How you got the binaries, including the mirror if you used one, and whether you checked signing certificates against a first-party source.
4. The analysis host: emulator or handset, model, Android/iOS version, root or jailbreak state and how (Magisk version, jailbreak tool), and whether the app could detect it.
5. The interception setup and its coverage: proxy, where your CA sat (system or user or repackaged), which bypass tooling at which version, and the per-app outcome counts — downloaded, installed, launched without crashing, traffic captured, traffic decrypted, pinning detected and not bypassed.
6. The driving strategy and its depth: driver and version, event budget or timeout per app, whether you logged in, whether you interacted with consent dialogs and how (Consent), and any coverage measure you can afford.
7. The static toolchain and its versions, and what fraction of the app set it failed on — packed, native-only, or unparseable. A static result over “the apps that parsed” needs that denominator stated.
8. Validation of every classifier, on a hand-labelled sample of your own data, with the sample size and the agreement measure (Interrater agreement). 83.3% of the corpus's classifying papers validate at least one classifier, but only 37.7% validate all of them — the gap is usually the second, less glamorous classifier, and that is the one a reviewer will pick on.
9. Attrition, numerically, at every stage. Sampled → downloaded → installed → launched → analysed. [15Koch, Simon; Altpeter, Benjamin; Johns, Martin (2023): "The OK Is Not Enough: A Large Scale Study of Consent Dialogs in Smartphone Applications", in: Proceedings of the USENIX Security Symposium. (Link)] is the model: 4,779 downloaded, 3,654 analysed, every later percentage over 3,654.
10. Ethics: whether you had review (only 28.2% of appAnalysis papers state an outcome at all), whether you created accounts, and how you handled personal data that appeared in intercepted traffic (Ethics).

• Website selection — the ranking-list problem, which store charts inherit and worsen.
• Sampling — how to draw a sample and what to record so the draw is repeatable.
• Longitudinal — pinning your instruments across waves; app churn makes this harder, not easier.
• Crawling location — the vantage point, and the storefront's separate and equally important geography.
• Traffic files — what to do with the traffic once you have decrypted it.
• Interaction — the web analogue of driving the UI.
• Requests and Fingerprinting — the classification methods that transfer from web to app traffic, and the ones that do not.
• Consent and TCF consent strings — consent measurement, and why TCF-based methods cover almost nothing on mobile.
• Interrater agreement — validating a hand-labelled sample.
• Ethics — account creation, store terms, and personal data in intercepted traffic.
• Artifacts — publishing the app list with hashes.

[1]

Allix, Kevin; Bissyandé, Tegawendé F.; Klein, Jacques; Le Traon, Yves (2016): "AndroZoo: Collecting Millions of Android Apps for the Research Community", in: Proceedings of the 13th International Conference on Mining Software Repositories, pp. 468-471. (DOI)

[2]

Alecci, Marco; Ruiz Jiménez, Pedro Jesús; Allix, Kevin; Bissyandé, Tegawendé F.; Klein, Jacques (2024): "AndroZoo: A Retrospective with a Glimpse into the Future", in: Proceedings of the 21st International Conference on Mining Software Repositories, pp. 389-393. (DOI)

[3]

Pradeep, Amogh; Paracha, Muhammad Talha; Bhowmick, Protick; Davanian, Ali; Razaghpanah, Abbas; Chung, Taejoong; Lindorfer, Martina; Vallina-Rodriguez, Narseo; Levin, Dave; Choffnes, David (2022): "A Comparative Analysis of Certificate Pinning in Android & iOS", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[4]

Liu, Yijing; Zhang, Yiming; Liu, Baojun; Duan, Haixin (2026): "Cracks in the Walled Garden: Dissecting the Gray-Market of Unauthorized iOS App Distribution via Ad Hoc Sideloading", in: Proceedings of the USENIX Security Symposium. (Link)

[5]

Kumar, Renuka; Virkud, Apurva; Sundara Raman, Ram; Prakash, Atul; Ensafi, Roya (2022): "A Large-scale Investigation into Geodifferences in Mobile Apps", in: Proceedings of the USENIX Security Symposium. (Link)

[6]

Lin, Fuqi; Wang, Haoyu; Wang, Liu; Liu, Xuanzhe (2021): "A Longitudinal Study of Removed Apps in iOS App Store", in: Proceedings of the ACM Web Conference. (DOI)

[7]

Wang, Haoyu; Li, Hao; Guo, Yao (2019): "Understanding the Evolution of Mobile App Ecosystems: A Longitudinal Measurement Study of Google Play", in: Proceedings of the ACM Web Conference. (DOI)

[8]

Specter, Michael A.; Christodorescu, Mihai; Farr, Abbie; Ma, Bo; Lassonde, Robin (2025): "Fingerprinting SDKs for Mobile Apps and Where to Find Them: Understanding the Market for Device Fingerprinting", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)

[9]

Bonett, Richard; Kafle, Kaushal; Moran, Kevin; Nadkarni, Adwait; Poshyvanyk, Denys (2018): "Discovering Flaws in Security-Focused Static Analysis Tools for Android using Systematic Mutation", in: Proceedings of the USENIX Security Symposium. (Link)

[10]

Pauck, Felix; Bodden, Eric; Wehrheim, Heike (2018): "Do Android taint analysis tools keep their promises?", in: Proceedings of the 26th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering. (DOI)

[11]

Schmidt, David; Tagliaro, Carlotta; Borgolte, Kevin; Lindorfer, Martina (2023): "IoTFlow: Inferring IoT Device Behavior at Scale through Static Mobile Companion App Analysis", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)

[12]

Lin, Hongyu; Hu, Yicheng; Xu, Haitao; Lu, Yanchen; Ren, Mengxia; Hao, Shuai; Yue, Chuan; Li, Zhao; Zhang, Fan; Jiang, Yixin (2026): "ChameleoScan: Demystifying and Detecting iOS Chameleon Apps via LLM-Powered UI Exploration", in: Proceedings of the Network and Distributed System Security Symposium. (Link)

[13]

Kong, Pingfan; Li, Li; Gao, Jun; Liu, Kui; Bissyandé, Tegawendé F.; Klein, Jacques (2019): "Automated Testing of Android Apps: A Systematic Literature Review", IEEE Transactions on Reliability 68(1):45-66. (DOI)

[14]

Li, Li; Bissyandé, Tegawendé F.; Papadakis, Mike; Rasthofer, Siegfried; Bartel, Alexandre; Octeau, Damien; Klein, Jacques; Traon, Le (2017): "Static analysis of Android apps: A systematic literature review", Information and Software Technology 88:67-95. (DOI)

[15]

Koch, Simon; Altpeter, Benjamin; Johns, Martin (2023): "The OK Is Not Enough: A Large Scale Study of Consent Dialogs in Smartphone Applications", in: Proceedings of the USENIX Security Symposium. (Link)

[16]

Oltrogge, Marten; Huaman, Nicolas; Klivan, Sabrina; Acar, Yasemin; Backes, Michael; Fahl, Sascha (2021): "Why Eve and Mallory Still Love Android: Revisiting TLS (In)Security in Android Applications", in: Proceedings of the USENIX Security Symposium. (Link)

[17]

Pourali, Sajjad; Yu, Xiufen; Zhao, Lianying; Mannan, Mohammad; Youssef, Amr (2024): "Racing for TLS Certificate Validation: A Hijacker's Guide to the Android TLS Galaxy", in: Proceedings of the USENIX Security Symposium. (Link)

[18]

Kollnig, Konrad; Shuba, Anastasia; Binns, Reuben; Van Kleek, Max; Shadbolt, Nigel (2022): "Are iPhones Really Better for Privacy? A Comparative Study of iOS and Android Apps", Proceedings on Privacy Enhancing Technologies 2022(2):6-24. (DOI)

[19]

Rodriguez, David; Calandrino, Joseph A.; Del Alamo, Jose M.; Sadeh, Norman (2025): "Privacy Settings of Third-Party Libraries in Android Apps: A Study of Facebook SDKs", Proceedings on Privacy Enhancing Technologies 2025(2):173-187. (DOI)

[20]

Nguyen, Trung Tin; Backes, Michael; Marnau, Ninja; Stock, Ben (2021): "Share First, Ask Later (or Never?) Studying Violations of GDPR's Explicit Consent in Android Apps", in: Proceedings of the USENIX Security Symposium. (Link)

[21]

Nguyen, Trung Tin; Backes, Michael; Stock, Ben (2022): "Freely Given Consent?: Studying Consent Notice of Third-Party Tracking and Its Violations of GDPR in Android Apps", in: Proceedings of the ACM SIGSAC Conference on Computer and Communications Security. (DOI)

[22]

Khandelwal, Rishabh; Nayak, Asmit; Chung, Paul; Fawaz, Kassem (2024): "Unpacking Privacy Labels: A Measurement and Developer Perspective on Google's Data Safety Section", in: Proceedings of the USENIX Security Symposium. (Link)