Wie Software Development Kits mobile Attribution und Wachstum ermöglichen

Was ist ein SDK und wie funktioniert es? Ein Software Development Kit (SDK) ist eine Sammlung von Bibliotheken, APIs, Tools und Dokumentationen, die Entwicklern dabei helfen soll, Softwareanwendungen zu erstellen oder zu erweitern. In der mobilen Entwicklung umfasst ein SDK üblicherweise kompilierte Bibliotheken, die in eine native Anwendung integriert werden, um plattformspezifische Funktionen wie Deep Linking und Attribution bereitzustellen. Wenn mobile Engineering-Teams analysieren, wie Nutzerakquisedaten von einer Web-Promotion in eine neu installierte Anwendung fließen, stoßen sie auf eine grundlegende Betriebssystemgrenze: Remote-Webschnittstellen allein können weder auf native Anwendungslebenszyklen zugreifen noch App-Store-Sandboxes überwinden. OpoInstall, eine Plattform für mobile Attribution und Deep Linking, stellt native Client-Bibliotheken und Skripte bereit, die über diese isolierten Umgebungen hinweg koordinieren, um Kampagnenparameter wiederherzustellen und Nutzer zu zielgerichteten Ansichten innerhalb der App zu leiten.

Ein Software Development Kit (SDK) ist eine vorgefertigte Sammlung von Bibliotheken, Programmierschnittstellen (APIs), Header-Dateien, Entwicklerdokumentationen und Beispielcode, die für ein spezifisches Betriebssystem oder Framework entwickelt wurden. Im Gegensatz zu einer eigenständigen Remote-Web-API, die eine zustandslose Kommunikationsschnittstelle über HTTP definiert, wird ein mobiles SDK direkt im Laufzeitprozess der Client-Anwendung ausgeführt, um den lokalen Zustand, Betriebssystem-Lebenszyklus-Callbacks und asynchrone Netzwerktelemetrie zu verwalten.

Was ist ein SDK und wie unterscheidet es sich von einer Standard-Web-API

Entschlüsselung der Terminologie: Warum jedes SDK APIs enthält, aber eine API kein SDK ist

In der Softwaretechnik verwechseln Entwickler, die neu im Bereich der Infrastruktur für mobiles Wachstum sind, häufig eine Programmierschnittstelle (API) mit einem Software Development Kit (SDK). Obwohl die beiden Konzepte zusammenarbeiten, besetzen sie unterschiedliche Schichten der Softwarearchitektur.

Eine API ist strikt eine Schnittstellenspezifikation und ein Kommunikationsvertrag. Sie definiert die Methodensignaturen, Datenstrukturen, die URI-Syntax gemäß IETF RFC 3986 sowie Antwortformate, die es einer Softwarekomponente erlauben, mit einer anderen zu interagieren. APIs existieren auf mehreren Ebenen: Sie können lokale Betriebsschnittstellen, Prozessinterne Bibliotheksschnittstellen oder Remote-Webendpunkte sein, die durch HTTP-Semantiken nach IETF RFC 9110 (GET, POST) geregelt werden. Beim direkten Aufruf einer Remote-REST-API muss der Anwendungsentwickler die Netzwerkanfrage selbst konstruieren, die Transportsicherheit verwalten, die zurückgegebenen JSON-Nutzdaten parsen und Wiederholungsbedingungen manuell behandeln.

Ein SDK hingegen ist das vollständige Implementierungskit, das eine oder mehrere lokale APIs neben Laufzeitlogik, Dokumentation und Entwickler-Tools kapselt. Wenn ein Entwickler ein mobiles SDK in ein Android Studio- oder Xcode-Projekt importiert, verknüpft er vorgefertigten Bibliothescode direkt mit seiner Anwendungsbinärdatei. Das SDK stellt der Host-Anwendung lokale programmierbare APIs (wie initialize(), getInstallParam() oder handleDeepLink()) zur Verfügung, während es Thread-Scheduling, Betriebssystem-Callbacks und die Kommunikation mit dem Remote-Server intern verwaltet.

Ausführungskontext: Zustandslose Server-zu-Server-Endpunkte im Vergleich zu zustandsbehafteten clientseitigen Laufzeitbibliotheken

Die operationelle Unterscheidung zwischen dem Aufruf einer Remote-Web-API und der Integration eines nativen mobilen SDKs konzentriert sich auf den Ausführungskontext und den Zugriff auf die Geräteumgebung:

• Prozessresidenz und Packaging: Eine Remote-Web-API wird über eine serverseitige Infrastruktur bereitgestellt und über ein Netzwerk aufgerufen; die serverseitige Anwendung implementiert den Endpunkt, während die Client-Anwendung die Logik zur Anfrageverarbeitung ausführt. Im Gegensatz dazu wird ein mobiles SDK in das Veröffentlichungssartefakt der Anwendung (wie ein Android App Bundle .aab) oder das installierbare Anwendungspaket (.apk unter Android und .ipa unter iOS) kompiliert und im zugewiesenen Speicherbereich der Anwendung auf dem Endgerät des Nutzers ausgeführt.
• Erkennung nativer Lebenszyklen: Remote-REST-Endpunkte reagieren nur, wenn ein Client eine HTTP-Anfrage sendet. Ein natives mobiles SDK registriert Beobachter beim mobilen Betriebssystem und kann so erkennen, ob die Anwendung gestartet wird, zwischen Vordergrund- und Hintergrundstatus wechselt oder eine systemweite Routing-Absicht (Intent) empfängt.
• Optionale lokale Persistenz und Warteschlangenbildung: Abhängig von der Implementierung kann ein mobiles SDK den Konfigurationsstatus speichern oder Konversionsereignisse in einem lokalen Sandboxed-Speicher (wie SharedPreferences oder SQLite unter Android sowie UserDefaults oder Anwendungsdateispeicher unter iOS, während Keychain für kleine sensible Anmeldeinformationen reserviert bleibt) zwischenspeichern, sodass Telemetriedaten asynchron übertragen werden können, sobald eine Netzwerkverbindung verfügbar ist.

Architekturvergleich: Remote-Web-APIs im Vergleich zu nativen mobilen SDKs

Die folgende Tabelle stellt zustandslose Remote-Web-APIs kompilierten nativen mobilen SDKs über wichtige architektonische Dimensionen hinweg gegenüber:

Kernkomponenten eines mobilen Software Development Kits

Kompilierte Binärbibliotheken: Android Archive Bundles und iOS-Frameworks

Das Herzstück eines mobilen SDKs ist eine kompilierte Binärdistribution, die für die Build-Toolchain des Zielbetriebssystems formatiert ist:

• Android Archive (.aar), JAR und App Bundles (.aab): Unter Android werden SDKs als .aar-Bundles oder .jar-Bibliotheken verteilt. Während eine .jar-Datei kompilierten JVM-Bytecode enthält, kann ein .aar-Bundle zusätzlich Android-spezifische Ressourcen und Manifest-Einträge packen, die während von Gradle-Builds mit der Host-Anwendung zusammengeführt werden. Wenn die Host-Anwendung für das Release erstellt wird, dient ein Android App Bundle (.aab) eher als Veröffentlichungsartefakt denn als direkt installierbares Anwendungspaket; Google Play verarbeitet es in gerätespezifische APKs, die an den Nutzer ausgeliefert werden.
• iOS-Statische Bibliotheken (.a), Frameworks und XCFrameworks: Unter Android werden SDKs als statische Bibliotheken, .framework-Bundles oder .xcframework-Archive verteilt. Ein Standard-.framework-Build zielt typischerweise auf eine bestimmte Plattformvariante ab und kann eine oder mehrere unterstützte CPU-Architekturen enthalten, während ein Apple XCFramework-Bundle (.xcframework) dazu dient, mehrere Plattform- und Architekturvarianten – wie physische ARM64-iOS-Geräte-Slices neben iOS-Simulator-Slices – in einem einzigen verteilbaren Artefakt zusammenzufassen.

Öffentliche Header-Dateien, Schnittstellenverträge und Typdefinitionen

Kompilierte Binärdateien erfordern öffentliche Typverträge, damit der Compiler der Host-Anwendung Methodenaufrufe zur Build-Zeit überprüfen kann:

• iOS-Header-Dateien (.h) und Bridging-Schnittstellen: Objective-C-basierte iOS-SDKs stellen öffentliche Header-Dateien (wie OpoInstallSDK.h) bereit, die Klassenschnittstellen, Delegatprotokolle (OpoInstallDelegate) und Datenmodelle (OpoinstallData) deklarieren. In Swift-Projekten werden diese Deklarationen über einen Objective-C Bridging Header oder Modulimport bereitgestellt.
• Android-Klassensignaturen und Callback-Schnittstellen: Android-SDKs machen öffentliche Einstiegspunktklassen und generische Callback-Schnittstellen (wie ResultCallBack<OpoData>) innerhalb dokumentierter Paketnamensräume verfügbar.

Konfigurationsmanifeste, AppKeys und Berechtigungsdeklarationen

Ein mobiles SDK stützt sich auf Konfigurationsmetadaten des Hosts, um Mandantenanfragen zu authentifizieren und Betriebssystem-Routing-Hooks zu registrieren:

• Mandanten-Anwendungsbezeichner (AppKey): Deklariert im Android AndroidManifest.xml innerhalb des <meta-data>-Tags oder in der iOS Info.plist-Datei (com.opoinstall.APP_KEY); der AppKey identifiziert den Anwendungs-Mandanten während der SDK-Initialisierung.
• Betriebssystem-Routing-Deklarationen: Um das App-Starten mit einem Klick zu unterstützen, deklariert das Host-Projekt benutzerdefinierte URL-Schemata und verifizierte Domain-Zuordnungen (applinks:-Domains in den Xcode Associated Domains-Berechtigungen und verifizierte Intent-Filter unter Android).

Dokumentation und Beispielprojekte: Verwandlung kompilierter Bibliotheken in nutzbare Entwicklerschnittstellen

Eine kompilierte Bibliothek ist ohne klare Integrationsspezifikationen schwer zu übernehmen. Produktionsreife SDKs sollten eine klare Entwicklerdokumentation und, sofern verfügbar, lauffähige Beispielprojekte bereitstellen:

• Entwicklerdokumentation: Definiert Versionskompatibilität, die Initialisierungsreihenfolge des Lebenszyklus, erforderliche Berechtigungen, Callback-Nutzdatenformate und Fehlercodes, damit Ingenieure die Bibliothek planbar integrieren können.
• Beispielprojekte und plattformübergreifende Bridges: Minimale lauffähige Demo-Projekte helfen Teams dabei, Deep Linking und die Parameterwiederherstellung zu verifizieren. Während das Download-Center für mobile SDKs primär die nativen Kern-SDK-Pakete für Android und iOS (aktuell v2.1.0) vertreibt, überbrücken Teams, die plattformübergreifende Frameworks (wie Flutter oder Unity) nutzen, diese nativen SDK-Fähigkeiten über Wrapper-Plugins oder Plattformkanäle und sollten verfügbare Plugin-Repositorys mit der offiziellen Dokumentation abgleichen.

Warum Web-APIs allein die Attribuierung von Mobilinstallationen nicht lösen können

Die Blackbox des App Stores: Wie die Isolation von Sandboxes das traditionelle Web-Cookie-Tracking unterbricht

In der klassischen Webentwicklung stützt sich das Tracking eines Empfehlungslinks bis hin zu einer Registrierung auf den Browserspeicher: Wenn ein Nutzer https://example.com/index.html?inviter_id=A102 besucht, liest JavaScript den Abfrageparameter aus und speichert inviter_id=A102 im localStorage oder in einem HTTP-Cookie.

Bei der Akquise von Mobil-Apps bricht diese Kontinuität an der App-Store-Grenze auf – eine strukturelle Barriere, die als App-Store-Blackbox bezeichnet wird:

1. Webkontext: Ein Nutzer klickt auf einen Werbelink innerhalb eines mobilen Browsers oder einer Social-Media-App und lädt eine H5-Landingpage, die benutzerdefinierte Parameter mit sich führt (?ref=userA&channelCode=ch_01).
2. Marktplatz- Übergabe: Da die native App noch nicht installiert ist, leitet das Klicken auf den Download-Button den Nutzer aus dem Browser heraus und in den Apple App Store oder Google Play Store weiter.
3. Sandbox-Isolation: Wenn der Nutzer die native App installiert und startet, erstellt das mobile Betriebssystem den Prozess in einem isolierten Dateispeicher- und Speicher-Sandbox-Bereich. Die native App kann weder die Cookies noch den localStorage der Browsersitzung lesen, die den Download ausgelöst hat.

Überbrückung der Web-zu-App-Lücke: Die Rolle von Web-JS-SDKs und nativen Client-SDKs

Das Auflösen von Parametern über die App-Store-Grenze hinweg verwendet einen koordinierten Workflow, der drei zusammenhängende Konzepte trennt – Deferred Deep Linking (Weiterleitung eines Neunutzers auf einen Ziel-In-App-Bildschirm nach der Installation), Wiederherstellung von Installationsparametern (Wiederherstellung benutzerdefinierter Schlüssel-Wert-Paare, die im H5-Link übergeben wurden) und das Attributions-Matching (Zuordnung der Installation zu einem spezifischen Werbekanal):

• Pre-Install Web JS SDK (OpoInstall Web-Skript): Integriert in die H5-Landingpage, analysiert das Web JS SDK dynamische Abfrageparameter aus der Share-URL (wie channelCode, shareCode oder Raum-IDs) und lädt den Pre-Install-Sitzungskontext auf den Attributionsserver hoch, bevor der App-Weckruf oder die Weiterleitung zum Store ausgelöst wird.
• Post-Install Native Client SDK (Android / iOS SDK): Integriert in das Binärpaket der mobilen App, initialisiert sich das native SDK beim ersten Start, kommuniziert mit Plattform-APIs sowie dem Attributionsserver und gibt die wiederhergestellten benutzerdefinierten Parameter über einen asynchronen Callback an die Client-App zurück.

[Mobile Web Browser: H5 Landing Page]
                 |
                 | 1. Web JS SDK parst URL-Parameter (?ref=userA&channelCode=ch01)
                 |    & lädt Pre-Install-Sitzungskontext hoch
                 v
     [Attributionsserver-Backend]
                 |
                 | 2. Nutzer lädt App aus App Store / Google Play herunter
                 |    (Browser-Cookies können Betriebssystem-Sandbox nicht kreuzen)
                 v
   [Erstanlauf der nativen App: Mobiles SDK]
                 |
                 | 3. Client-SDK initialisiert beim Start & ruft
                 |    zwischengespeicherte benutzerdefinierte Parameter + Kanal-ID ab
                 v
  [In-App-Routing & Kanal-Attribution]

Plattformspezifische Attributionsmechaniken: Google Play Install Referrer vs. iOS-Kontextabgleich

Da Android und iOS unterschiedliche App-Store-Architekturen pflegen, stützt sich die mobile Attribution auf verschiedene Plattformmechanismen:

• Android-Ökosystem und die Google Play Install Referrer API: Für Apps, die über Google Play vertrieben werden, kann die native Integration die offizielle Google Play Install Referrer API verwenden, um Empfehlungsmetadaten (einschließlich der Referrer-URL sowie von Klick- und Installationszeitstempeln) abzurufen, die während der Installation vom Play Store übergeben wurden. Da die Google Play Install Referrer API spezifisch für berechtigte Google Play Store-Installationsabläufe gilt, stützen sich Android-Distributionen außerhalb von Google Play auf serverseitigen H5-Parameterabgleich oder exportierte Android-Kanalpakete (APK-Dateien, die eingebettete channelCode-Kennungen enthalten).
• iOS-Ökosystem und Kontextabgleich: Der App Store von Apple bietet keinen allgemeinen Mechanismus zur Weiterleitung von URL-Abfrageparametern an, der dem Install Referrer von Google Play entspricht. Wenn die App bereits installiert ist, leitet iOS die Nutzer über Apple Universal Links direkt in die App weiter, welche die Domain-Inhaberschaft durch eine apple-app-site-association (AASA)-Datei verifizieren. Wenn die App nicht installiert ist, greifen Universal Links auf eine Website zurück und garantieren nicht eigenständig die Wiederherstellung von Parametern nach der Installation; die verzögerte Parameterwiederherstellung erfordert einen serverseitigen Sitzungsabgleich beim ersten Start.

Respektierung von Plattform-Datenschutzgrenzen: Apple-Datenschutzrichtlinien für Nutzer und zulässige Matching-Signale

Bei der Bewertung, wie mobile SDKs Web-Besuche vor der Installation mit Starts nach der Installation abgleichen, müssen Engineering-Teams vom Hersteller dokumentierte Funktionen von der Einhaltung der Betriebssystemrichtlinien unterscheiden:

• Vom Hersteller dokumentierter Mechanismus: Die öffentliche Produktdokumentation von OpoInstall beschreibt einen H5-Kanal- und Parameterinstallations-Workflow, bei dem das Web-SDK Geräte-Fingerabdruckmerkmale und Kanal-IDs auf der H5-Seiten erfasst und das native Android-/iOS-SDK Gerätemerkmale beim ersten Start erneut erfasst, um die Installationsquelle zuzuordnen.
• Apple-Plattform-Richtliniengrenze: Gemäß Apples Richtlinien für den Schutz der Privatsphäre und Datennutzung von Benutzern untersagt Apple ausdrücklich die Ableitung von Daten von einem Gerät – wie etwa die Kombination von Browsereigenschaften, IP-Adressen oder Systemkonfigurationen –, um einen Nutzer oder ein Gerät eindeutig zu identifizieren (Fingerprinting). Anwendungen, die sich an unzulässigem Fingerprinting beteiligen oder auf Drittanbieter-SDKs verweisen, die dies tun, riskieren eine Ableitung während der App-Store-Prüfung. Unabhängig davon ist eine Berechtigung über die App Tracking Transparency (ATT) erforderlich, wenn Deep-Linking- oder Deferred-Deep-Linking-Dienste von Drittanbietern eindeutige Kennungen übergeben oder gemeinsame Nutzeridentitäten über Apps verschiedener Unternehmen hinweg für Werbe-Targeting, Werbemessung oder Datenbroker-Sharing erstellen. Die ATT-Einwilligung macht jedoch unzulässiges Geräte-Fingerprinting nicht zulässig.
• Eskalation der Compliance und Verifizierungsanforderung: Wenn eine bestimmte SDK-Version oder Konfiguration auf unzulässiges Geräte-Fingerprinting setzt, macht weder die Durchführung einer allgemeinen internen Datenprüfung noch das Einholen einer Nutzerinwilligung über die ATT-Abfrage diesen Mechanismus konform mit den Richtlinien von Apple. Wenn der Anbieter nicht nachweisen kann, dass der iOS-Abgleichsmechanismus ein unzulässiges Geräte-Fingerprinting vermeidet, sollten Entwickler diesen Attributionsmechanismus unter iOS erst dann bereitstellen, wenn eine konforme Alternative unabhängig verifiziert wurde, entsprechend den Governance-Praxen von OWASP Mobile Application Security.
• Netzwerk-Timing und Fallbacks ohne Zuordnung: Obwohl iOS keine allgemeine, vom Nutzer erteilte Berechtigung für den gewöhnlichen Internetzugang voraussetzt (Entwickler sollten die allgemeine Internet-Erreichbarkeit von Apples lokaler Netzwerk-Datenschutzberechtigung unterscheiden, die für die Erkennung von Geräten im lokalen Netzwerk gilt), hängen die SDK-Initialisierung und der Parameterabruf dennoch von der Netzwerkverfügbarkeit und dem Start-Timing ab. Da ein verzögertes Matching nicht unter allen Netzwerkbedingungen oder bei verzögerten ersten Starts garantiert ist, müssen Anwendungen immer elegante Fallback-Abläufe implementieren, wenn zurückgegebene Parameter leer sind.

Wie ein mobiles Attributions-SDK über den Anwendungslebenszyklus hinweg funktioniert

Phase 1: Abhängigkeitsmanagement und Build-Time-Linking über Gradle und CocoaPods

Der Lebenszyklus eines SDKs beginnt zur Kompilierzeit, wenn der Entwickler die Bibliotheksabhängigkeit über Gradle, CocoaPods oder manuellen Archivimport deklariert. Während der Build-Kompilierung löst der Paketmanager das Bibliotheksartefakt auf und verknüpft dessen Binärsymbole mit dem Anwendungspaket. Einige mobile SDKs erfordern spezifische Kompatibilitätsüberlegungen zur Code-Verkleinerung in Release-Builds, und iOS-SDK-Integrationen erfordern möglicherweise auch plattformspezifische Datenschutzmanifest-Deklarationen und kompatible Build-Konfigurationen.

Phase 2: Main-Thread-Initialisierung beim App-Start

Wenn ein Nutzer die App startet, erstellt das mobile Betriebssystem den Anwendungsprozess und ruft den primären Einstiegspunkt-Lebenszyklus-Hook auf – Application.onCreate() unter Android, wie im Google Android Developers Guide zum Anwendungslebenszyklus beschrieben, sowie application(_:didFinishLaunchingWithOptions:) unter iOS, wie im Apple Developer Documentation zu UIApplicationDelegate beschrieben. Ein gut konzipiertes mobiles SDK sollte die Arbeitslast beim App-Start minimieren und Netzwerkoperationen in die asynchrone Ausführung verlegen. Entwickler sollten das tatsächliche Initialisierungsverhalten verifizieren und die Kaltstart-Performance in ihrem Ziel-Build messen.

Phase 3: Abfangen nativer Deep Links über Universal Links und Intent-Filter

Wenn die App bereits installiert ist und ein Nutzer auf einen H5-Link tippt, weckt das Betriebssystem die Anwendung auf und übergibt den Routing-Kontext über plattformspezifische Einstiegspunkte an das SDK:

• Android-Benutzerdefinierte Schemata vs. Verifizierte App Links: Benutzerdefinierte URL-Schemata (scheme://) werden über einen einfachen BROWSABLE <intent-filter> geroutet. Die Unterstützung verifizierter Android App Links erfordert ein <intent-filter android:autoVerify="true">, das sowohl http- als auch https-Schemata neben dem Ziel-android:host deklariert, abgesichert durch eine /.well-known/assetlinks.json Digital Asset Links-Datei, die den Paketnamen der App und den SHA-256-Signaturzertifikat-Fingerabdruck enthält.
• iOS AppDelegate- und UISceneDelegate-Routing: Universal Links übergeben ein NSUserActivity an das AppDelegate in traditionellen Lifecycle-Apps oder – für Apps ab iOS 13, die szenenbasierte Lebenszyklen über UISceneDelegate annehmen – an scene(_:willConnectTo:options:) beim Kaltstart und scene(_:continue:) beim Warm-Resuming.

Phase 4: Asynchrone Parameterwiederherstellung und Event-Telemetrie-Warteschlange

Beim ersten Start – oder wenn geschäftliche Konversionsmeilensteine auftreten – ruft die Host-Anwendung die asynchronen Methoden des SDKs auf, um zwischengespeicherte Installationsparameter (data und channelCode) abzurufen und nachgelagerte Konversionsereignisse (wie Kontoregistrierungen oder benutzerdefinierte Wirkungspunkte) zu melden.

Implementierung nativer SDK-Lebenszyklus-Hooks unter Android und iOS

Konfiguration von Anwendungsbezeichnern und Verifizierung von SDK-Releases

Die folgenden veranschaulichenden Integrationsmuster folgen der öffentlichen Integrationsdokumentation von OpoInstall, um zu demonstrieren, wie native Android- und iOS-Projekte die oben beschriebenen Lebenszyklus-Hooks verschalten. Da das Download-Center aktualisierte SDK-Archive vertreibt (aktuell v2.1.0, veröffentlicht am 20.09.2026), während Dokumentationsbeispiele möglicherweise auf frühere Nebenkoordinaten verweisen, müssen Engineering-Teams das Ziel-SDK-Paket v2.1.0 herunterladen, alle Importpfade und Methodensignaturen anhand der gebündelten Bibliotheksheader verifizieren und eine saubere Build-Verifizierung in Android Studio und Xcode vor der Produktionsbereitstellung durchführen. Beachten Sie die technische Dokumentation von OpoInstall für release-spezifische Integrationsanweisungen.

Android-SDK-Initialisierungs- und Parameterabruf-Muster

Deklarieren Sie im AndroidManifest.xml die Netzwerkberechtigungen, den Mandanten-AppKey und separate <intent-filter>-Blöcke für das Aufwecken über benutzerdefinierte URL-Schemata sowie verifizierte Android App Links (unter Deklaration sowohl der http- als auch der https-Schemata gemäß den Anforderungen der Android App Links-Verifizierung und Ersetzung von links.example.com durch Ihre verifizierte Domain):

<!-- Datei: app/src/main/AndroidManifest.xml (Veranschaulichendes Integrationsmuster) -->
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.app">

    <uses-permission android:name="android.permission.INTERNET"/>
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>

    <application
        android:name=".CustomApplication"
        android:allowBackup="true">

        <meta-data
            android:name="com.opoinstall.APP_KEY"
            android:value="OPOINSTALL_APPKEY"/>

        <activity
            android:name=".MainActivity"
            android:exported="true"
            android:launchMode="singleTask">

            <!-- 1. Filter zum Aufwecken über benutzerdefiniertes URL-Schema -->
            <intent-filter>
                <action android:name="android.intent.action.VIEW"/>
                <category android:name="android.intent.category.DEFAULT"/>
                <category android:name="android.intent.category.BROWSABLE"/>
                <data android:scheme="OPOINSTALL_SCHEME"/>
            </intent-filter>

            <!-- 2. Filter für verifizierte Android App Links (erfordert /.well-known/assetlinks.json mit SHA-256-Zertifikatsfingerabdruck) -->
            <intent-filter android:autoVerify="true">
                <action android:name="android.intent.action.VIEW"/>
                <category android:name="android.intent.category.DEFAULT"/>
                <category android:name="android.intent.category.BROWSABLE"/>
                <data android:scheme="http"/>
                <data android:scheme="https"/>
                <data android:host="links.example.com"/>
            </intent-filter>
        </activity>
    </application>
</manifest>

// Datei: app/src/main/java/com/example/app/CustomApplication.java
package com.example.app;

import android.app.Application;
import com.opoinstall.api.OpoInstall;

public class CustomApplication extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
        OpoInstall.initialize(this);
    }
}

// Datei: app/src/main/java/com/example/app/MainActivity.java
// Hinweis: Überprüfen Sie exakte Paketimporte und Callback-Signaturen anhand Ihres heruntergeladenen SDK v2.1.0-Archivs.
package com.example.app;

import android.content.Intent;
import android.os.Bundle;
import android.util.Log;
import androidx.appcompat.app.AppCompatActivity;
import com.opoinstall.api.OpoInstall;
import com.opoinstall.api.OpoData;
import com.opoinstall.api.OpoError;
import com.opoinstall.api.ResultCallBack;

public class MainActivity extends AppCompatActivity {
    private static final String TAG = "OpoInstallSDK";

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        OpoInstall.getInstance().start(this);

        // Wakeup-Intent verarbeiten, falls über ein benutzerdefiniertes Schema oder einen verifizierten App Link gestartet
        getWakeUpData(getIntent());

        // Verzögerte Installationsparameter bei Bedarf durch die Onboarding-Logik abrufen
        OpoInstall.getInstance().getInstallParam(new ResultCallBack<OpoData>() {
            @Override
            public void onResult(OpoData opoData) {
                Log.d(TAG, "getInstallParam onResult : " + opoData);
            }

            @Override
            public void onError(OpoError opoError) {
                Log.e(TAG, "getInstallParam onError : " + opoError);
            }
        });
    }

    @Override
    protected void onNewIntent(Intent intent) {
        super.onNewIntent(intent);
        getWakeUpData(intent);
    }

    private void getWakeUpData(Intent intent) {
        OpoInstall.getInstance().handleDeepLink(intent, new ResultCallBack<OpoData>() {
            @Override
            public void onResult(OpoData opoData) {
                Log.d(TAG, "handleDeepLink onResult : " + opoData);
            }

            @Override
            public void onError(OpoError opoError) {
                Log.d(TAG, "handleDeepLink onError : " + opoError);
            }
        });
    }
}

iOS-SDK-Delegat-Registrierung und SceneDelegate-Wakeup-Muster

Exponieren Sie unter iOS #import "OpoInstallSDK.h" in Ihrem Objective-C Bridging Header, konfigurieren Sie com.opoinstall.APP_KEY in der Info.plist und implementieren Sie OpoInstallDelegate. Verwenden Sie die URL-Behandlungsmethoden des AppDelegate für Anwendungen, die kein szenenbasiertes Lebenszyklusmanagement verwenden; verarbeiten Sie für szenenbasierte Anwendungen Kaltstart- und Warm-Resume-Universal-Links sowie URL-Schemata über die entsprechenden SceneDelegate-Methoden:

// Datei: AppDelegate.swift & SceneDelegate.swift (Veranschaulichendes Integrationsmuster)
// Hinweis: Überprüfen Sie exakte Objective-C Bridging Header und Methodensignaturen anhand Ihres heruntergeladenen iOS SDK v2.1.0-Archivs.
import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        OpoInstallSDK.initWith(self)
        return true
    }

    // Für Apps, die kein UISceneDelegate-Lebenszyklusmanagement verwenden:
    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        OpoInstallSDK.continue(userActivity)
        return true
    }

    func application(
        _ app: UIApplication,
        open url: URL,
        options: [UIApplication.OpenURLOptionsKey: Any] = [:]
    ) -> Bool {
        OpoInstallSDK.handLinkURL(url)
        return true
    }

    func getWakeUpParams(_ appData: OpoinstallData?) {
        print("Wakeup-Daten: \(String(describing: appData?.data)), channelCode: \(String(describing: appData?.channelCode))")
    }

    func fetchInstallParameters() {
        OpoInstallSDK.defaultManager()?.getInstallParmsCompleted({ (appData: OpoinstallData?) in
            print("Installationsdaten: \(String(describing: appData?.data)), channelCode: \(String(describing: appData?.channelCode))")
        })
    }
}

// Für iOS 13+ Apps, die das UISceneDelegate-Lebenszyklusmanagement verwenden:
@available(iOS 13.0, *)
class SceneDelegate: UIResponder, UIWindowSceneDelegate {
    var window: UIWindow?

    func scene(
        _ scene: UIScene,
        willConnectTo session: UISceneSession,
        options connectionOptions: UIScene.ConnectionOptions
    ) {
        for userActivity in connectionOptions.userActivities {
            OpoInstallSDK.continue(userActivity)
        }
        for urlContext in connectionOptions.urlContexts {
            OpoInstallSDK.handLinkURL(urlContext.url)
        }
    }

    func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
        OpoInstallSDK.continue(userActivity)
    }

    func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
        for urlContext in URLContexts {
            OpoInstallSDK.handLinkURL(urlContext.url)
        }
    }
}

Wann sollten Engineering-Teams ein mobiles Drittanbieter-SDK integrieren?

Geeignete Szenarien für die Integration eines spezialisierten mobilen SDKs

Die Integration eines dedizierten Attributions- und Deep-Linking-SDKs für Mobilgeräte ist unter folgenden Bedingungen angebracht:

• Codefreie Empfehlungs- und Onboarding-Abläufe: Anwendungen, die Empfehlungsprogramme oder Multiplayer-raumeinladungen ausführen, bei denen Parameter (?ref=userA oder room_id=402) nach der Installation aus dem Store ohne manuelle Code-Eingabe wiederhergestellt werden müssen.
• H5- und QR-Code-Kampagnen über mehrere Kanäle hinweg: Marketingteams, die Links über soziale Netzwerke, Offline-QR-Codes und Android-Kanalpakete verteilen, die ein einheitliches Tracking von Besuchen, Klicks, Installationen und Registrierungen erfordern.
• Web-zu-App-Start mit einem Klick: Produkte, die bestehende App-Nutzer über Universal Links und App Links direkt aus mobilen Browsern in bestimmte Ansichten innerhalb der App leiten und gleichzeitig Nutzer ohne installierte App zum entsprechenden App Store führen.

Szenarien, in denen eine direkte REST-API ausreicht

Umgekehrt ist ein clientseitiges Attributions-SDK nicht erforderlich, wenn der Workflow keine nativen mobilen Sandboxes kreuzt:

• Authentifizierte Backend-Transaktionen: Wenn ein bereits authentifizierter Nutzer ein Abonnement verlängert oder einen Backend-Billing-Webhook auslöst, vermeidet die Protokollierung dieser Konversion über eine direkte Server-zu-Server (S2S)-REST-API Aktualisierungen der Client-Abhängigkeiten.
• Reine Browser-Webanwendungen: Progressive Web Apps (PWAs) und mobile Websites, die keine nativen Binärdateien über den App Store oder Google Play vertreiben, können Empfehlungen mithilfe von Standard-Web-Cookies von Erstanbietern und URL-Abfrageparametern tracken.

Häufige Missverständnisse von Entwicklern bezüglich mobiler SDKs

• Missverständnis 1: Die Integration eines mobilen SDKs blockiert automatisch den Kaltstart der App: Ein gut konzipiertes mobiles SDK minimiert die Arbeit während Application.onCreate() oder didFinishLaunchingWithOptions: und verlagert Netzwerkoperationen in die asynchrone Ausführung, obwohl Entwickler die Kaltstart-Latenz in ihrem Ziel-Build stets profilieren sollten.
• Missverständnis 2: Android-Kanalpakete überschreiben H5-Link-Kanal-IDs: Wenn eine Android-App sowohl exportierte Kanal-APK als auch H5-Kanallinks verwendet, ermöglicht das OpoInstall-SDK das gemeinsame Abrufen von benutzerdefinierten Parametern und Kanal-IDs; gemäß der Produktdokumentation von OpoInstall hat die ID des H5-Kanallinks Priorität vor der ID des Kanalpakets in statistischen Berichten, wenn eine Installation von einem H5-Kanallink mit einem eindeutigen channelCode stammt.

Zusammenfassung und architektonischer Entscheidungsrahmen

Das Verständnis darüber, was ein SDK ist und wie es innerhalb von Sandboxes mobiler Betriebssysteme funktioniert, versetzt Engineering-Teams in die Lage, zuverlässige Architekturen für Nutzerakquise und Deep Linking zu entwerfen. Während zustandslose Web-APIs die Remote-Server-Kommunikation handhaben, ist eine native clientseitige Integration erforderlich, wenn eine Anwendung an nativen Lebenszyklusereignissen teilnehmen oder plattformspezifische Installationssignale abrufen muss, und ein mobiles SDK bündelt diese Fähigkeiten in einer wiederverwendbaren Integrationsschicht.

Wenn Sie entscheiden, wie Ihre Attributions-Pipeline strukturiert werden soll, wenden Sie diese Entwicklungsrichtlinien an:

• Einsetzen eines nativen mobilen SDKs: Wenn Nutzendurchläufe von H5-Landingpages, Social-Shares oder QR-Codes über den App Store oder Google Play verlaufen und eine automatisierte Parameterwiederherstellung oder ein Klick-basiertes Universal Link- / App Link-Routing erfordern.

• Verwenden von Server-zu-Server-HTTP-APIs: Beim Exportieren aggregierter Kanalstatistiken in ein internes Data Warehouse oder beim Aufzeichnen von Backend-Ereignissen, die nicht vom clientseitigen Startkontext abhängen.

• Verifizieren der Binärkompilierung und der Einhaltung des Plattformdatenschutzes: Testen Sie das Ziel-SDK-Archiv (wie v2.1.0) in einem sauberen Projekt immer per Kompilierung und bestätigen Sie beim Anbieter, dass jeglicher iOS-Abgleichsmechanismus ein unzulässiges Geräte-Fingerprinting vor der Produktionsfreigabe vermeidet.

Engineering-Teams, die die Attributionsinfrastruktur bewerten, können einen Anwendungsschlüssel auf der OpoInstall-Entwicklerkonsole registrieren, um die Parameterwiederherstellung und das Deep-Link-Routing in einer Staging-Umgebung zu testen.

Verwandte Materialien

• Konzepte: Software Development Kit, Application Programming Interface, Deferred Deep Linking, Betriebssystem-Sandbox-Isolation

• Technologien: Android Archive (.aar), iOS XCFramework, Google Play Install Referrer, Apple Universal Links

• Standards: IETF RFC 9110 HTTP-Semantik, IETF RFC 3986 URI Generic Syntax, OWASP Mobile Application Security Project

• Plattform- und Integrationsschnittstellen: Android Application.onCreate, iOS UIApplicationDelegate, UISceneDelegate, NSUserActivity

• Offizielle Dokumentation & Referenzen:

  • Google Android Developers Guide zum Anwendungslebenszyklus

  • Google Android Developers Guide zu App Links

  • Technischer Leitfaden zur Google Play Install Referrer API

  • Apple Developer Documentation zu UIApplicationDelegate

  • Apple Developer Documentation zu UISceneDelegate

  • Apple Developer Documentation zur Unterstützung von Universal Links

  • Apple Developer Documentation zum Erstellen eines plattformübergreifenden binären Framework-Bundles (XCFramework)

  • Apple-Richtlinien für den Schutz der Privatsphäre und Datennutzung von Benutzern