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.