Measure The Web

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Measuring Mobile Apps ======

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.

  - **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.
  - **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.
  - **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.
  - **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.

<WRAP important>
The question a mobile traffic measurement has to answer and a web crawl does not is **"how do you know your instrumentation saw the traffic?"** There is a real answer — report the share of your app set whose traffic you could actually decrypt, and the share you lost to pinning, crashes and download failures — and most papers do not give it. See [[#What to Report]].
</WRAP>

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.((The absent-venue list is a judgement about where this literature publishes, not a measurement — the corpus cannot see venues it does not contain. Two of the outside-corpus papers cited on this page are from MSR and one from ESEC/FSE, which is the shape of the gap.)) See [[Literature:Corpus]].

===== What to Read First =====

Five papers will orient you faster than anything else on this page, and each is here for a methodological reason rather than a topical one.

  - {[pradeep2022_comparative]} — **the certificate-pinning measurement.** The only paper we found that separates //potential// from //actual// pinning and reports what fraction of pinned destinations its bypass toolchain failed on. Read the methodology, not just the results.
  - {[bonett2018_discovering]} — **why your static analysis is wrong.** Injects executable leaks into real apps and measures what three well-known detectors miss. Read it before you write "we used FlowDroid". {[pauck2018_promises]} is the independent second opinion.
  - {[koch2023_enough]} — **the attrition model.** 4,779 apps downloaded, 3,654 analysed, every app-level percentage over the second number. Copy this reporting discipline exactly.
  - {[kollnig2022_iphones]} — **how to compare two platforms without cheating.** Random samples per platform, cross-platform app identity defined explicitly, code analysis and traffic analysis reported separately.
  - {[kumar2022_investigation]} — **why your storefront matters.** Geodifferences in mobile apps, measured.

Two systematic reviews give the taxonomy of approaches, both from outside these seven venues and both old enough to predate Frida's adoption and every LLM-based method: {[kong2019_testing]} on automated Android testing and {[li2017_static]} on static analysis. Read them for the map, not the tool list.

===== Which Population Is Yours =====

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

^ Slice ^ Definition ^ Papers ^ Share of 5,859 ^
| ''appAnalysis'' | the paper's study types include ''mobile-app-analysis'' — it took apps apart | **529** | 9.0% |
| ''mobilePlat'' | the paper's measured platforms include ''mobile'' | 1,075 | 18.3% |
| either | | 1,079 | |
| both | | 525 | |

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). As a //share of venue output// PETS and NDSS lead, but only narrowly and over a two-point spread; **by volume USENIX Security (143 papers) and CCS (106) publish the most of it**. IMC and TheWebConf, the two most web-flavoured venues here, publish the least either way. Note also that ''appAnalysis'' includes malware and vulnerability work, not only privacy measurement, so none of these shares is a share of "mobile privacy papers".

===== Getting the Apps =====

==== Android ====

There are four routes and they are not equivalent.

^ Route ^ What you get ^ The catch ^
| **AndroZoo** | 27,616,422 APKs as of 2026-08-27, with AV labels, plus Google Play metadata added December 2023((AndroZoo, [[https://androzoo.uni.lu/|androzoo.uni.lu]] and [[https://androzoo.uni.lu/access|Access Conditions]]. Checked 2026-08-27.)) | Access by email to ''androzoo@uni.lu'' from an **institutional** address with a fixed JSON template; personal-domain requests are not processed. API keys **expire after 6 months** and are capped at **500,000 successful APK downloads** per key. Non-commercial, no redistribution. Cite {[allix2016_androzoo]} and, for the metadata, {[alecci2024_retrospective]}. |
| **Scrape Google Play yourself** | current apps, current store metadata, your own sampling frame | Fragile and legally awkward — see below |
| **Third-party mirrors** (APKPure, APKMirror, APKCombo, Aptoide) | easy bulk download, historical versions | **Unverified provenance.** A mirror can serve a repackaged binary. If you use one, verify the signing certificate against Play or AndroZoo and //say that you did// |
| **F-Droid** | fully open index, ''index-v2.json'' with signature verification((F-Droid, [[https://f-droid.org/docs/All_our_APIs/|All our APIs]]. Checked 2026-08-27.)) | ~thousands of FOSS apps. A fine population for a study //about FOSS//; a badly biased one for a study about apps users have |

**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 the corpus's large Android studies rely on AndroZoo, an unofficial scraper, a mirror, a dataset someone else already collected, or industry telemetry — never on a first-party API. Of the 96 ''appAnalysis'' papers with a population of 100,000 apps or more, the sources include vendor product telemetry (NortonLifeLock, Palo Alto Networks), volunteer-device capture (Lumen), and inherited research datasets (Drebin, Andrubis) alongside the three routes above.

Scraper currency, checked 2026-08-27:

^ Tool ^ Latest ^ Status ^
| ''google-play-scraper'' (npm, metadata only) | 10.1.3, 2026-05-31((npm registry, [[https://www.npmjs.com/package/google-play-scraper|google-play-scraper]]; README at [[https://github.com/facundoolano/google-play-scraper|github.com/facundoolano/google-play-scraper]]. Checked 2026-08-27.)) | **Community maintenance only.** The README says: "I don't use or actively maintain this project anymore, other than reviewing community provided PRs. Expect the parser to break when Google Play's layout changes." |
| ''google-play-scraper'' (PyPI, metadata only) | 1.2.7, **2024-06-07**((PyPI, [[https://pypi.org/project/google-play-scraper/|google-play-scraper]]. Checked 2026-08-27.)) | Stalled — no release in over two years |
| ''apkeep'' (EFF) | 1.0.0, 2026-04-30((GitHub, [[https://github.com/EFForg/apkeep|EFForg/apkeep]]. Checked 2026-08-27.)) | **Actively maintained.** The one downloader here with a maintainer and a 2026 release |
| ''gplaycli'' | 3.29, **2020-03-10**; last commit 2021-10-02((GitHub, [[https://github.com/matlink/gplaycli|matlink/gplaycli]]. Checked 2026-08-27.)) | **Abandoned.** Still cited in papers; do not start here |
| ''PlaystoreDownloader'' | 2.0 alpha, 2022-01-08 | **Archived 2024-07-27**((GitHub, [[https://github.com/ClaudiuGeorgiu/PlaystoreDownloader|ClaudiuGeorgiu/PlaystoreDownloader]]. Checked 2026-08-27.)) — read-only, will not track Play's auth changes |

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)".((Google, [[https://policies.google.com/terms|Terms of Service]], effective 30 July 2026, "Don't abuse our services". Checked 2026-08-27.)) 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.

==== iOS ====

Harder, and the corpus shows it: of 529 ''appAnalysis'' papers, **39 match only iOS patterns and 66 match both**, against **369 Android-only**.((Classified by regex over each paper's title, tool names, population sources and detection phenomena; the regex is in ''scripts/report_mobile.mjs'' §3. A crude split, published because the honest alternative is no number at all. 55 papers matched neither pattern.)) Decrypting a store IPA requires a device that will let you dump the decrypted binary, which historically meant a jailbreak.

^ Tool ^ Latest ^ Note ^
| ''ipatool'' | v2.3.2, 2026-08-03((GitHub, [[https://github.com/majd/ipatool|majd/ipatool]]. Checked 2026-08-27.)) | Actively maintained; downloads (still-encrypted) IPAs with an Apple ID |
| ''frida-ios-dump'' | last commit **2020-06-01**((GitHub, [[https://github.com/AloneMonkey/frida-ios-dump|AloneMonkey/frida-ios-dump]]. Checked 2026-08-27.)) | Stale. Widely cited, including by {[pradeep2022_comparative]}; expect to fix it yourself |
| ''palera1n'' | v3.0.0 beta 2, 2026-08-03((GitHub, [[https://github.com/palera1n/palera1n|palera1n/palera1n]]. Checked 2026-08-27.)) | checkm8-based, so bounded to vulnerable hardware, not to iOS version |
| ''Dopamine'' | 3.0.9, 2026-08-22((GitHub, [[https://github.com/opa334/Dopamine|opa334/Dopamine]]. Checked 2026-08-27.)) | Actively released |
| ''TrollStore'' | 2.1.1, 2026-04-01((GitHub, [[https://github.com/opa334/TrollStore|opa334/TrollStore]]. Checked 2026-08-27.)) | Actively released. Permanent signing without a full jailbreak, on the iOS versions it supports |

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.((Apple, [[https://developer.apple.com/support/apps-in-the-eu|Apps in the EU]]; the older ''/support/dma-and-apps-in-the-eu/'' path redirects here. Checked 2026-08-27.)) A 2026 iOS study sampling only the App Store is sampling one distribution channel out of three in the EU, and should say so. {[liu2026_cracks]} is the corpus's closest look at unauthorised iOS distribution.

==== The storefront is part of your sampling frame ====

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 ([[Design: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. {[kumar2022_investigation]} is the paper to read on why it matters: geodifferences in mobile apps are real and measurable.

<WRAP tip>
Record, per crawl: store (Play / App Store / named alternative), **storefront country**, the account's locale and region, the device or emulator locale, the network egress country, and the dates. If any of the five disagree with each other, that is a finding, not a bug to hide.
</WRAP>

==== What to pin so someone can repeat you ====

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. {[lin2021_longitudinal]} 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. {[wang2019_evolution]} 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:

^ App-set size ^ Papers with ≥1 such set ^ Share of 397 ^
| 1–10 | 52 | 13.1% |
| 11–100 | 139 | 35.0% |
| 101–1,000 | 127 | 32.0% |
| 1,001–10,000 | 130 | 32.7% |
| 10,001–100,000 | 112 | 28.2% |
| >100,000 | 92 | 23.2% |

===== Static Analysis =====

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]]):

^ Tool ^ Papers ^ What it is for ^ Status, checked 2026-08-27 ^
| ''Soot'' | 65 (12.3%) | Java/Dalvik IR, the substrate under most Android analyses | Soot 4.7.1 (2026-02-23) still maintained, but the rewrite **SootUp** v3.0.1 (2026-08-07) is where new work goes((GitHub, [[https://github.com/soot-oss/soot|soot-oss/soot]] and [[https://github.com/soot-oss/SootUp|soot-oss/SootUp]]. Checked 2026-08-27.)) |
| ''apktool'' | 57 (10.8%) | unpack resources and manifest | v3.0.3, 2026-07-20((GitHub, [[https://github.com/iBotPeaches/Apktool|iBotPeaches/Apktool]]. Checked 2026-08-27.)) — maintained |
| ''FlowDroid'' | 49 (9.3%) | taint tracking, source→sink | 2.15.1, 2026-02-23((GitHub, [[https://github.com/secure-software-engineering/FlowDroid|secure-software-engineering/FlowDroid]]. Checked 2026-08-27.)) — maintained |
| ''Androguard'' | 37 (7.0%) | Python APK parsing and analysis | 4.1.4 on PyPI 2026-06-01((PyPI, [[https://pypi.org/project/androguard/|androguard]]. Checked 2026-08-27.)) — maintained |
| ''jadx'' | 32 (6.0%) | decompile to readable Java | 1.5.6, 2026-07-10((GitHub, [[https://github.com/skylot/jadx|skylot/jadx]]. Checked 2026-08-27.)) — maintained; **this is what replaced ''smali''/''dex2jar''** |
| ''smali''/''baksmali''/''dex2jar'' | 34 (6.4%) | disassemble to smali | Historical: **17.0% of 2010–2015 papers, 3.3% of 2025–2026** |
| ''MobSF'' | 7 (1.3%) | batteries-included audit framework | v4.5.2, 2026-08-10((GitHub, [[https://github.com/MobSF/Mobile-Security-Framework-MobSF|MobSF/Mobile-Security-Framework-MobSF]]. Checked 2026-08-27.)) — maintained |
| ''LibRadar'' | 23 (4.3%) | third-party library detection | **Abandoned — last commit 2018-12-21**((GitHub, [[https://github.com/pkumza/LibRadar|pkumza/LibRadar]]. Checked 2026-08-27.)) |
| ''LibScout'' | 10 (1.9%) | third-party library detection | **Abandoned — last commit 2019-10-25**((GitHub, [[https://github.com/reddr/LibScout|reddr/LibScout]]. Checked 2026-08-27.)) |
| ''PScout'' | 12 (2.3%) | permission↔API mapping | Historical; the mapping is version-specific and the tool is not tracking new Android releases |

<WRAP alert>
**''LibRadar'' and ''LibScout'' are the two most-used SDK detectors in this corpus and both stopped being maintained before Android 11.** Their signature databases predate most of the SDKs a 2026 study cares about. If you use one, you are measuring "SDKs that existed in 2018 and still have the same fingerprint", and you must validate against something current — {[specter2025_fingerprinting]} built its own signatures for exactly this reason and ended up with 723 SDK families over 14,178 versions. Recovering the ground truth is the work; the tool is not.
</WRAP>

==== Static analysis is unsound in practice, and the field measured it ====

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

{[bonett2018_discovering]} (μ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**. {[pauck2018_promises]} 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. {[schmidt2023_iotflow]} ran ''APKiD'' to detect packers precisely so it could report which apps its static analysis could not reach.

===== Dynamic Analysis =====

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

^ What it instruments ^ Papers (of 529) ^ 2010–2015 (88) ^ 2016–2020 (157) ^ 2021–2024 (194) ^ 2025–2026* (90) ^
| static analysis / RE | 225 (42.5%) | 42.0% | 43.9% | 42.3% | 41.1% |
| runtime hooking | 155 (29.3%) | 11.4% | 20.4% | 37.6% | **44.4%** |
| traffic interception | 110 (20.8%) | 8.0% | 15.3% | 26.8% | **30.0%** |
| UI exploration | 89 (16.8%) | 4.5% | 16.6% | 18.6% | **25.6%** |
| //static **and** traffic in the same paper// | 55 (10.4%) | 4.5% | 7.6% | 12.9% | **15.6%** |

//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.//

==== Emulator or handset ====

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.((Google, [[https://developer.android.com/privacy-and-security/safetynet/deprecation-timeline|SafetyNet Attestation API deprecation timeline]]; the older ''/safetynet/attestation'' path redirects here and carries the same sentence. Checked 2026-08-27.)) 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.

==== Driving the app: the coverage problem ====

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

^ Driver ^ Papers ^ Note ^
| ''Monkey'' (Android UI/Application Exerciser) | 34 (6.4%) | Still shipped in the Android SDK((Google, [[https://developer.android.com/studio/test/other-testing-tools/monkey|UI/Application Exerciser Monkey]]. Checked 2026-08-27.)); random events, no state model. The floor, not the goal |
| ''Appium'' | 17 (3.2%) | 3.7.0, 2026-08-24((npm registry, [[https://www.npmjs.com/package/appium|appium]]. Checked 2026-08-27.)) — the maintained cross-platform option, drives UiAutomator2 on Android and XCUITest on iOS |
| ''UI Automator'' / ''uiautomator2'' | 15 (2.8%) | Android-native, scriptable |
| ''DroidBot'' and relatives | 14 (2.6%) | Model-based exploration; research code |
| ''AndroidViewClient'' | 6 (1.1%) | |

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: {[bonett2018_discovering]} could only confirm 2,026 of 7,584 injected leaks as executable using GUI exploration, and {[lin2026_chameleoscan]} used an LLM to get through the UI — 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 {[kong2019_testing]} on automated Android testing (2019) and {[li2017_static]} 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.

<WRAP important>
**Attrition is a number you must report, and almost nobody does.** {[koch2023_enough]} downloaded 4,779 apps and successfully analysed **3,654 (76.5%)** — 71.0% on Android, 85.7% on iOS. Its app-level results are all over 3,654, not 4,779, and the paper says so. That is the model to copy: the app set you //analysed// is not the app set you //sampled//, and the difference is not random.
</WRAP>

===== The Certificate-Pinning Problem =====

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

<WRAP info>
**Steps 1–3 below are Android.** iOS interception is a different problem and the page treats it as one: on iOS you install your CA as a configuration profile //and// enable full trust for it in Settings, which gets you unpinned traffic; for pinned apps you need code injection, which on a store-signed binary means a jailbroken device — so the iOS route runs through the jailbreak tooling in [[#iOS]] above, and your device and firmware are part of your sample description. {[pradeep2022_comparative]} did exactly this (Checkra1n plus Frida) and is the worked example. The one iOS-specific pinning-bypass tool the corpus names, SSL Kill Switch 2, is unmaintained and its README caps support at iOS 14.2 — there is no maintained drop-in replacement, so expect to write Frida hooks yourself.
</WRAP>

**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.((Google, [[https://developer.android.com/privacy-and-security/security-config|Network security configuration]]. Checked 2026-08-27.)) 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";((Google, [[https://developer.android.com/privacy-and-security/certificate-transparency-policy|Certificate Transparency policy]]. Checked 2026-08-27.)) 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.((Google, [[https://developer.android.com/about/versions|Android releases]] and [[https://developer.android.com/about/versions/17|Android 17]]. Checked 2026-08-27.))

**2. The app may pin anyway.** This is where the honest numbers live. {[pradeep2022_comparative]} is the reference measurement, and it separates //potential// from //actual// pinning, which almost nothing else does:

^ Measurement ^ Android ^ iOS ^
| static indicators of pinning (config, embedded certs, hashes, native strings) | up to **27%** of apps | up to **33%** |
| pinning observed at runtime, //Popular// set (n=1,000 per platform) | **6.7%** | **11.4%** |
| pinning observed at runtime, //Random// set (n=1,000 per platform) | **0.9%** | **2.5%** |
| unique pinned destinations they could circumvent with Frida hooks | **≈51.51%** | **≈66.15%** |

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:

  * {[oltrogge2021_mallory]}: 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%.
  * {[schmidt2023_iotflow]}: **385 of 9,889** IoT companion apps (3.89%) used pinning, detected from the NSC.
  * {[pourali2024_racing]}: 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:

^ Tool ^ Latest ^ Verdict ^
| **Frida** | 17.17.0, 2026-08-05((GitHub, [[https://github.com/frida/frida|frida/frida]]. Checked 2026-08-27.)) | **Current, and the field's default.** 0% of 2010–2015 ''appAnalysis'' papers, **33.3% of 2025–2026** |
| **objection** | 1.12.5, 2026-06-02((GitHub, [[https://github.com/sensepost/objection|sensepost/objection]]. Checked 2026-08-27.)) | **Current.** A Frida front-end; 7 of its 9 uses among the 529 are pinning bypass |
| **Magisk** | v30.7, 2026-02-23((GitHub, [[https://github.com/topjohnwu/Magisk|topjohnwu/Magisk]]. Checked 2026-08-27.)) | **Current.** How you get a system CA onto a handset |
| Xposed | archived; last release v89 (2017-12-17), last push 2020-06-08((GitHub, [[https://github.com/rovo89/Xposed|rovo89/Xposed]] — repository flag ''archived: true''. Checked 2026-08-27.)) | **Dead.** Peaked at 10.2% of 2016–2020 papers, 2.2% in 2025–2026 |
| LSPosed | v1.9.2, **2023-10-11**; last commit on the default branch **2024-01-07**((GitHub, [[https://github.com/LSPosed/LSPosed|LSPosed/LSPosed]]. The repository's ''pushed_at'' is 2026-08-26 because that counts any branch; the default branch has not moved since January 2024. Checked 2026-08-27.)) | **Stalled.** No release in nearly three years and no default-branch commit in over two |
| JustTrustMe | last release 2016; last commit 2024-09-02((GitHub, [[https://github.com/Fuzion24/JustTrustMe|Fuzion24/JustTrustMe]]. Checked 2026-08-27.)) | **Unmaintained**, and depends on the dead Xposed line |
| SSL Kill Switch 2 | 0.14, 2019-12-03; last commit 2023-07-09((GitHub, [[https://github.com/nabla-c0d3/ssl-kill-switch2|nabla-c0d3/ssl-kill-switch2]]. Checked 2026-08-27.)) | **Unmaintained**; its own README claims support only to iOS 14.2 |
| TrustMeAlready | archived 2019-09-23((GitHub, [[https://github.com/ViRb3/TrustMeAlready|ViRb3/TrustMeAlready]]. Checked 2026-08-27.)) | **Dead** |

**4. You have to report what you lost.** Intersected properly, over the full text of the **110 ''appAnalysis'' papers that named a traffic-interception tool**: **44 (40.0%)** mention pinning at all, **22 (20.0%)** describe bypassing it, **6 (5.5%)** mention the Network Security Configuration, and **65 (59.1%) mention none of the three**. So a clear majority of the papers that intercepted app traffic never wrote down what they could not intercept — and the ones that did are concentrated in the last few years.

==== Three things that will bite you that no paper warns you about ====

  * **A proxy sees the whole device, not your app.** Play Services, the OS itself and every other installed app also talk. A per-app claim needs per-app flow attribution — the UID behind the socket, a Frida stack trace, or one app installed at a time on a clean profile. A narrow probe for a paper //describing// that step finds **1 of 529**, which is more a comment on how rarely it is written down than on how often it is done. {[rodriguez2025_settings]} attributes connections to SDKs via Frida stack traces precisely because the proxy log alone cannot.
  * **QUIC bypasses a TCP proxy.** An app speaking HTTP/3 over UDP will simply not appear in mitmproxy unless you block UDP 443 to force TCP fallback, or terminate QUIC. A traffic measurement that does neither has a silent hole whose size it cannot report. **14 of the 529 papers mention QUIC at all.**
  * **There is a no-root route, and the corpus mostly forgot it.** An on-device ''VpnService'' app captures traffic without rooting, which is how the Lumen/ReCon/AntMonitor line of work collected from real users' devices. **39 of the 529 papers name such a tool or the API; 8 describe the technique.** It cannot break pinning, and it changes your population from "apps you chose" to "apps your volunteers had" — but for a field study, or for any measurement where rooting the handset is not an option, it is the technique to reach for. Lumen itself is gone (see below); the approach is not.

<WRAP tip>
A defensible pipeline in 2026, built from the components recent papers most often combine — Frida and mitmproxy co-occur in 16 of the 191 ''appAnalysis'' papers since 2023, and the full named stack in 3, so this is a recommendation assembled from practice rather than a practice the field has converged on: **Magisk-rooted physical handset → your root as a system CA → mitmproxy → Frida/objection to unhook pinning where needed → Appium or UiAutomator to drive**, with a per-app record of //downloaded, installed, launched, traffic captured, traffic decrypted, pinning detected//. ''mitmproxy'' is in 52 papers (9.8%) and rising; that record is what turns "we intercepted traffic" into a number.
</WRAP>

===== What the Corpus Says the Field Actually Measures =====

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

^ Target ^ Papers ^ Share ^
| ''mobile-app'' | 198 | 37.4% |
| ''vulnerability'' | 113 | 21.4% |
| ''sdk-or-library'' | 66 | 12.5% |
| ''domain'' | 51 | 9.6% |
| ''network-traffic'' | 44 | 8.3% |
| ''privacy-policy'' | 39 | 7.4% |

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

^ Method ^ Papers ^ Share of classifiers ^
| ''heuristic-rules'' | 257 | 54.4% |
| ''manual-labelling'' | 192 | 40.7% |
| ''static-analysis'' | 149 | 31.6% |
| ''supervised-ml'' | 103 | 21.8% |
| ''third-party-service'' | 87 | 18.4% |
| ''curated-database'' | 75 | 15.9% |
| ''dynamic-analysis'' | 48 | 10.2% |
| ''llm'' | 15 | 3.2% |

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.** {[kollnig2022_iphones]}, 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. {[rodriguez2025_settings]} 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.** {[koch2023_enough]}: **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 ([[Privacy:TCF consent strings]]) covers almost nothing on mobile. See also {[nguyen2021_sharefirst]} and {[nguyen2022_freely]}.
  * **Store-declared privacy is a measurable artefact and it is wrong a lot.** {[khandelwal2024_unpacking]}: **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.** {[schmidt2023_iotflow]} 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.

===== Use in Publications =====

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 [[provenance:design:mobile_and_app_measurement]].

^ Tool family ^ Papers ^ Share of 529 ^ 2010–2015 ^ 2016–2020 ^ 2021–2024 ^ 2025–2026* ^
| Frida | 74 | 14.0% | 0.0% | 3.8% | 19.6% | 33.3% |
| adb | 71 | 13.4% | 5.7% | 8.3% | 17.5% | 21.1% |
| Soot | 65 | 12.3% | 9.1% | 15.3% | 12.4% | 10.0% |
| apktool | 57 | 10.8% | 11.4% | 13.4% | 7.7% | 12.2% |
| mitmproxy | 52 | 9.8% | 1.1% | 7.0% | 13.9% | 14.4% |
| FlowDroid | 49 | 9.3% | 4.5% | 10.2% | 11.3% | 7.8% |
| Androguard | 37 | 7.0% | 8.0% | 4.5% | 9.3% | 5.6% |
| smali/baksmali/dex2jar | 34 | 6.4% | 17.0% | 7.0% | 2.6% | 3.3% |
| Monkey | 34 | 6.4% | 2.3% | 8.9% | 6.2% | 6.7% |
| jadx | 32 | 6.0% | 0.0% | 1.3% | 9.3% | 13.3% |
| Xposed | 31 | 5.9% | 0.0% | 10.2% | 6.7% | 2.2% |
| Play store scraper | 30 | 5.7% | 0.0% | 3.8% | 7.2% | 11.1% |
| LibRadar | 23 | 4.3% | 0.0% | 6.4% | 5.7% | 2.2% |
| Android emulator | 21 | 4.0% | 8.0% | 4.5% | 3.1% | 1.1% |
| Appium | 17 | 3.2% | 0.0% | 1.3% | 3.6% | 8.9% |
| pinning-bypass helper | 15 | 2.8% | 0.0% | 1.9% | 4.1% | 4.4% |
| Magisk | 14 | 2.6% | 0.0% | 0.6% | 2.6% | 8.9% |
| third-party APK mirror | 10 | 1.9% | 2.3% | 3.2% | 1.5% | 0.0% |
| TaintDroid | 7 | 1.3% | 6.8% | 0.6% | 0.0% | 0.0% |

//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.

^ Source ^ Papers ^ Share of 529 ^
| Google Play, all spellings merged | 250 | 47.3% |
| AndroZoo (largest single spelling) | 46 | 8.7% |
| custom seed list | 58 | 11.0% |
| Apple App Store (largest single spelling) | 11 | 2.1% |
| F-Droid | 7 | 1.3% |

**Datasets somebody else already collected.** ''pre-existing-dataset'' is the sampling method for 71 of those 400 papers (17.8%), and the page would be failing its own purpose if it did not name them. Beyond AndroZoo, the sources the corpus's own large populations draw on include **Drebin** and **Andrubis** (malware), the **Gamba et al. preinstalled-app dataset** and **Firmware Scanner** corpus, **Koodous**, **VirusShare** and the **AMD** dataset, **PrivacyGrade**, and the **Lumen** volunteer captures. Two of these are worth a warning: a malware dataset is not a sample of apps users have, and a 2014-era dataset used in a 2026 paper is a claim about 2014. Check the collection date before you inherit one.

**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 [[Design: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:

^ Field ^ Population ^ N ^ States a value ^
| ''vantage.locations'' | ''appAnalysis'' with a vantage tuple | 430 | 117 (**27.2%**) |
| ''population.listVersion'' | ''appAnalysis'' with a mobile-apps population | 400 | 222 (55.5%) |
| ''classification.validation'', ≥1 real value | ''appAnalysis'' that classified | 472 | 393 (**83.3%**) |
| ''classification.validation'', //every// classifier validated | ''appAnalysis'' that classified | 472 | 178 (**37.7%**) |
| ''ethics.reviewOutcome'' | ''appAnalysis'' | 529 | 149 (**28.2%**) |
| ''artifacts.availability'' | ''appAnalysis'' | 529 | 323 (61.1%), of which 267 (50.5%) public |

**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:

^ Probe ^ Papers ^
| mentions certificate/SSL/TLS pinning | 71 |
| describes bypassing pinning | 33 |
| names a pinning-bypass tool | 33 |
| mentions Frida (case-sensitive) | 87 |
| mentions Xposed (case-sensitive) | 40 |
| mentions mitmproxy | 59 |
| mentions the Network Security Configuration | 13 |
| mentions root detection / SafetyNet / Play Integrity | 35 |
| mentions emulator detection | 15 |
| says "physical/real device" | 109 |
| mentions native code / JNI / NDK | 144 |
| mentions packing or unpacking | 85 |
| names ProGuard / R8 / DexGuard | 29 |
| names an app-download or store-scraping tool | 46 |
| mentions AndroZoo | 68 |
| mentions privacy labels or Data Safety | 55 |
| names a UI-exploration driver | 61 |
| reports a coverage measure | 48 |
| mentions an LLM or GPT (case-sensitive) | 42 |
| mentions store terms of service near scraping/downloading | 8 |
| mentions QUIC | 14 |
| names an on-device-VPN capture tool or the ''VpnService'' API | 39 |
| describes the on-device-VPN capture technique | 8 |
| describes attributing traffic to a specific app or library | 1 |

==== Methodology and limitations of these figures ====

  * **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 [[Literature: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 **[[provenance:design:mobile_and_app_measurement]]**.

===== Which Methods Are Current =====

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.

^ Practice ^ Status ^ Evidence ^
| Hook the app with **Frida** (+ objection) | **Current, and the field's default.** | 0% of 2010–2015 ''appAnalysis'' papers → 33.3% of 2025–2026; Frida 17.17.0 released 2026-08-05 |
| Hook with **Xposed** or an Xposed module (JustTrustMe, TrustMeAlready) | **Superseded.** | Xposed archived, last push 2020-06-08; LSPosed's last release is 2023-10-11 and its default branch stopped in January 2024; corpus share fell 10.2% (2016–2020) → 2.2% (2025–2026) |
| **TaintDroid** for dynamic taint tracking | **Historical.** | 6.8% of 2010–2015 papers, **0% since 2021**, though 84 papers still //mention// it. It is a modified Android 4.x; it cannot run a 2026 app |
| **smali / baksmali / dex2jar** as the decompilation step | **Superseded by jadx.** | 17.0% → 3.3%; jadx 0% → 13.3% over the same windows |
| **Soot** as the analysis substrate | **Current, but check SootUp.** | Soot 4.7.1 (2026-02-23) maintained; SootUp v3.0.1 (2026-08-07) is the rewrite and where new development is |
| **FlowDroid** for taint analysis | **Current, and known-unsound.** | 2.15.1 (2026-02-23) maintained; missed >48% of executable injected leaks in {[bonett2018_discovering]}. Use it //and// validate |
| **LibRadar / LibScout** for SDK detection | **Abandoned, and still the corpus's most-used option.** | Last commits 2018 and 2019. Their signatures predate Android 11 |
| Build your **own SDK signatures** and publish them | **Current best practice, and rare.** | {[specter2025_fingerprinting]} (723 families, 14,178 versions); {[rodriguez2025_settings]} cross-validates LibScout against Frida rather than trusting it |
| **Emulator** as the analysis host | **Declining, and detectable.** | 8.0% → 1.1% of papers naming an emulator; Play Integrity replaced SafetyNet in January 2025 and fails both root and emulation |
| **Rooted physical handset + Magisk system CA** | **Current.** | Magisk v30.7 (2026-02); the practical route to a system CA short of building a modified system image |
| **Random UI events (Monkey)** as the exploration strategy | **The floor.** Still shipped, still used, still shallow. | 6.4% of papers; {[kong2019_testing]} is the survey of what else exists |
| **LLMs for classification** (policies, UI text, labels) | **New in 2025–2026 and moving fast.** | ''classification.method = llm'' among ''appAnalysis'' papers goes 0% (pre-2021) → 0.5% (2021–2024) → **15.6%** (2025–2026). 90-paper denominator; do not over-read the level, but the direction is unambiguous |
| **LLM-driven UI exploration** | **New, promising, one data point.** | {[lin2026_chameleoscan]} is the only paper we found in these seven venues using an LLM to //get through the UI// rather than to classify text. One paper is not a practice |
| **''gplaycli''** to fetch APKs | **Abandoned.** | Last release 2020-03-10, last commit 2021-10-02 |
| **''PlaystoreDownloader''** | **Archived 2024-07-27.** | Read-only repository |
| **''apkeep''** to fetch APKs | **Current.** | 1.0.0, 2026-04-30, maintained by the EFF |
| **''google-play-scraper''** for store metadata | **Works, unmaintained.** | npm 10.1.3 (2026-05-31) with an explicit "I don't use or actively maintain this project anymore" in the README; the PyPI package's last release is 2024-06-07 |
| **AndroZoo** as the app source | **Current, with new limits.** | 27.6M APKs; keys now expire at 6 months and cap at 500,000 downloads. Budget the cap into your design |
| **AppCensus** public app-privacy reports | **Gone.** | appcensus.io is live but is now an enterprise product with no free searchable report database (checked 2026-08-27) |
| **Lumen Privacy Monitor** as a data source | **Discontinued.** | Both known package IDs return HTTP 404 on Google Play (checked 2026-08-27) |
| **Exodus Privacy** for tracker signatures | **Live and free.** | reports.exodus-privacy.eu.org responding, platform version 1.32.4 (checked 2026-08-27). It does not publish its signature count on the front page; check before quoting one |
| Sampling **only the App Store** for an EU iOS study | **No longer complete.** | Apple's own DMA page documents alternative marketplaces and web distribution in the EU, with further changes effective 2026-10-01 |
| Reporting the **share of apps whose traffic you decrypted** | **Not established, and it should be.** | 110 papers intercepted traffic; 71 mention pinning; 33 describe bypassing it; 13 mention the NSC. The number exists in {[pradeep2022_comparative]} and almost nowhere else |

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.

===== What to Report =====

A methods section that survives review needs:

  - **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.
  - **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.
  - **How you got the binaries**, including the mirror if you used one, and whether you checked signing certificates against a first-party source.
  - **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.
  - **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.
  - **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 ([[Privacy:Consent]]), and any coverage measure you can afford.
  - **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.
  - **Validation of //every// classifier**, on a hand-labelled sample of your own data, with the sample size and the agreement measure ([[Statistics: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.
  - **Attrition, numerically, at every stage.** Sampled → downloaded → installed → launched → analysed. {[koch2023_enough]} is the model: 4,779 downloaded, 3,654 analysed, every later percentage over 3,654.
  - **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 ([[Practices:Ethics]]).

===== Open Questions =====

<WRAP todo>
  * **We found no re-measurement of the pinning-bypass success rate since 2022 in these seven venues.** {[pradeep2022_comparative]} gives ≈51.5% of pinned Android destinations circumvented and ≈66.2% on iOS. Frida is now at 17.17.0. Repeating that single measurement would be cheap and would be cited by every mobile traffic paper thereafter.
  * **There is no maintained, validated third-party-SDK detector.** LibRadar and LibScout are the field's workhorses and both stopped in the 2010s. A maintained signature set with a published validation would immediately improve a large slice of the mobile privacy literature. {[specter2025_fingerprinting]} shows the scale of what is missing.
  * **How much does a mirror change the binary?** We found no study in these seven venues that systematically compares APKs from APKPure, APKMirror or Aptoide against the Play original by signature and content. 10 papers in ''appAnalysis'' name a mirror among the tools they used, and 46 mention some third-party APK/IPA mirror or downloader somewhere in the text, so this is not a hypothetical gap.
  * **What is the actual storefront effect?** {[kumar2022_investigation]} establishes geodifferences exist. Nobody has published how much a headline mobile privacy figure moves when you re-run it against five storefronts — which is exactly what a reviewer should ask of any single-country app measurement.
  * **The static/dynamic gap has one careful measurement in this corpus.** {[schmidt2023_iotflow]} compared both on 13 apps. A study that ran a modern static and a modern dynamic pipeline over the same few thousand apps and published the disagreement matrix would settle a lot of arguments.
  * **No mobile equivalent of Tranco exists.** There is no versioned, citable, archived app-ranking list. Store charts are per-country, per-day and unarchived, so "top-//n// apps" is unreproducible by construction for the 140 papers that use it. Building one is a small piece of infrastructure with a large payoff.
  * **AppCensus's public database and Lumen both went away, and nothing replaced them.** Exodus Privacy is the live public tracker-signature source that remains. Whether anything replaces the volunteer-device traffic collection Lumen did is an open question with no candidate we could verify.
</WRAP>

===== Related Pages =====

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

====== References ======

<bibtex bibliography></bibtex>


/* This enables discussion under this article. */
~~DISCUSSION~~