Separating the app from what it embeds
An Android app usually contains two kinds of network calls: those to its own backend and those made by third-party software development kits. The second group covers payments, analytics, crash reporting, customer support, maps and push messaging. Recovering an integration means identifying which SDK owns a call, what the SDK expects in return, and where the app's own data ends and the vendor's begins.
That distinction decides the work. First-party calls can be reimplemented freely. A vendor SDK carries terms, credentials tied to an account, and a protocol that may change without notice, so the useful output is an accurate description of the integration.
A single feature can involve both kinds of call. A checkout flow may call the app's backend to create an order and a payment SDK to collect card details, and the two exchange identifiers. Recovering the integration means following those identifiers across the boundary.
Identify the SDKs in the build
SDKs leave several kinds of evidence, and cross-checking them avoids mistaking a first-party class for a vendor one.
Initialisation code is a good starting point. Most SDKs require an explicit init call with an application context and a key, and that call usually sits in the application class. Finding it names the SDK and shows the configuration values it needs.
- Package prefixes in the DEX that match the vendor's namespace.
- Native libraries shipped for specific architectures, common with analytics and media SDKs.
- Assets such as model files, licence files, configuration JSON or certificate bundles.
- Manifest components the SDK contributes, including services, receivers and providers.
- API keys and identifiers in string resources or generated constants.
Maven coordinates sometimes survive in metadata files inside the APK, which names the artifact and its version directly. When they do not, the package prefix and the endpoint hostname usually identify the vendor.
Trace the integration's network activity
Record traffic while you exercise the feature. Group requests by hostname, because vendor traffic tends to go to a small number of hosts that differ from the app's own backend. For each host, note the paths, the method, the content type and the authentication scheme.
Vendor authentication varies. Some SDKs send an API key as a header or a query parameter. Others exchange an app key for a short-lived token at startup. A few sign requests with a secret embedded in the app. Certificate pinning inside an SDK is common, and it changes how you observe traffic without changing what you can conclude from the request shapes once the pinning is handled.
Some SDKs batch and delay their requests. An analytics SDK may queue events and send them on a timer or when the app goes to the background, so traffic that appears unrelated to the feature you exercised can belong to it. Record a longer window and match events by their payload rather than by their timing.
Reconstruct the calls that matter
For each operation the app performs, capture a request and its response and record the variables. Watch for values the SDK fetches before the call: a device identifier, a locale, a session token, or a configuration blob from a remote config endpoint. Those startup calls are part of the integration, and a reproduction that skips them usually fails on the first real request.
Payload formats split into JSON and binary. A binary body is often protobuf, and the SDK ships the generated message classes with the field constants intact. Envelope details matter as well: an idempotency key, a tenant or merchant identifier, a client-generated request id, and retry headers that mark a repeated attempt.
Reconstruct requests in the order the SDK makes them. A vendor that issues a token at startup, then fetches configuration, then performs the operation you care about will reject a client that starts at the operation.
Deciding what to document and what to leave alone
Write down the vendor, the endpoints the SDK calls, the credentials it uses, and the fields the app passes to it. That record is enough to review an integration, migrate away from a vendor, or reproduce the behaviour on infrastructure the team controls.
Where an SDK depends on account-level credentials or a signed agreement, treat the record as documentation and route production use through the vendor's own terms. A clear boundary here is what keeps the work useful.
Related work
Reviewed 28 September 2026 · SReverse research desk