app/services/copilot/knowledge/technical/android-sdk-overview.md

# Android Native SDK Overview

## Overview

The Android native SDK lives at `android/shieldyono-sdk/`, written in Kotlin under the package `com.sbi.shieldyono`. It is described in the codebase as a "bank-agnostic Universal Banking Security SDK" — meaning its on-device modules are designed to be reusable protection primitives, not hard-wired specifically to SBI YONO. It runs on-device and operates independently of the backend for its core detection logic, calling out to the core backend only where cloud-side enrichment adds value (currently, APK verdicts).

## Modules

The SDK is organized into several functional modules:

- **APK download monitoring** — watches for APK files being downloaded/installed on the device, which is the trigger point for both local checks and the cloud-enriched analysis call.
- **Behaviour/sensor collection** — gathers device usage and sensor-derived behavioural signals, which can be submitted to the core backend's `behaviour` router (`/api/v1/behaviour/*`) for further analysis.
- **Device security checks** — evaluates the device's general security posture (integrity-style checks), complementing the core backend's `/api/v1/device/analyze` endpoint.
- **Dangerous-permission analysis** — inspects installed apps' requested permissions to flag combinations or individual permissions considered high-risk.
- **RAT (Remote Access Trojan) detection** — looks for on-device indicators associated with remote-access-trojan-style malware, a category of threat particularly relevant to banking-fraud scenarios (e.g. screen-sharing/remote-control abuse).
- **Trusted-app-registry / impersonation checks** — maintains a notion of trusted/known-good apps and checks whether an app is impersonating a legitimate one (e.g. a fake banking app mimicking YONO's identity).
- **Local risk calculator** — combines the SDK's own on-device signals into a local risk assessment, so the device can act on some level of risk awareness even without a live network connection to the backend.
- **SIM-swap / telephony monitoring** — watches telephony-layer signals relevant to SIM-swap style attacks, a common precursor to account-takeover fraud.

## Network client

The SDK includes its own network client that calls the core backend's `POST /api/v1/apk/analyze` endpoint to get a cloud-enriched verdict for APKs the SDK has flagged for a closer look. This is the SDK's main point of integration with the rest of the Shield backend stack — the core backend proxies that request onward to the dedicated APK scanner microservice (Androguard/YARA/APKiD/ML), and the enriched verdict flows back down to the device through the SDK.

## How it complements the backend engines

The SDK and the backend engines are deliberately split by where they run and what they're best at:

- **On-device (SDK)**: fast, always-available checks that don't require a network round trip — permission analysis, RAT indicators, trusted-app/impersonation checks, sensor/behaviour collection, SIM-swap monitoring, and a local risk score. These can run even with no connectivity and give the device some baseline protection immediately.
- **Cloud (core backend + APK scanner microservice)**: the deeper, more expensive static-analysis passes (Androguard structural parsing, YARA signature matching, APKiD packer detection, ML classification) that are too heavy to run on-device, plus URL/QR/smishing scanning that inherently requires reputation data and models better hosted centrally.

The SDK's local risk calculator and the backend's risk/immunity scoring are complementary layers rather than duplicates: the SDK gives an immediate, offline-capable signal, while the backend call (when connectivity is available) enriches that with deeper static analysis for a more authoritative verdict on APKs specifically.

## Scope note

The SDK's on-device modules (behaviour collection, device checks, dangerous-permission analysis, RAT detection, trusted-app-registry checks, SIM-swap monitoring, and the local risk calculator) operate locally on the device. Beyond the APK-analysis call described above, this document does not assert additional direct network integrations for those modules beyond what is listed — treat any other claimed SDK-to-backend calls as unconfirmed.