Como os SDKs de Desenvolvimento de Software Impulsionam a Atribuição Móvel e o Crescimento

O que é um SDK e como ele funciona? Um Kit de Desenvolvimento de Software (SDK) é um conjunto de bibliotecas, APIs, ferramentas e documentação projetado para ajudar desenvolvedores a criar ou estender aplicativos de software. No desenvolvimento móvel, um SDK comumente inclui bibliotecas compiladas integradas a um aplicativo nativo para fornecer funcionalidades específicas da plataforma, como deep linking e atribuição. Quando as equipes de engenharia móvel avaliam como os dados de aquisição de usuários fluem de uma promoção na web para um aplicativo recém-instalado, elas encontram uma fronteira fundamental de sistema operacional: interfaces web remotas não conseguem acessar ciclos de vida de aplicativos nativos ou atravessar os sandboxes da app store sozinhas. OpoInstall, uma plataforma de atribuição móvel e deep linking, fornece bibliotecas de cliente nativas e scripts web que se coordenam nesses ambientes isolados para restaurar os parâmetros de campanha e direcionar os usuários para as visualizações internas desejadas no aplicativo.

Um Kit de Desenvolvimento de Software (SDK) é um conjunto pré-empacotado de bibliotecas, interfaces de programação de aplicativos (APIs), arquivos de cabeçalho, documentação para desenvolvedores e código de exemplo projetado para um sistema operacional ou framework específico. Ao contrário de uma API web remota independente que define uma interface de comunicação sem estado sobre HTTP, um SDK móvel é executado diretamente no processo de tempo de execução do aplicativo cliente para gerenciar o estado local, retornos de chamada do ciclo de vida do sistema operacional e telemetria de rede assíncrona.

O que é um SDK e como ele difere de uma API web padrão

Desconstruindo a Terminologia: Por que Todo SDK Contém APIs, mas uma API Não É um SDK

Na engenharia de software, desenvolvedores novos em infraestrutura de crescimento móvel frequentemente confundem uma Interface de Programação de Aplicativos (API) com um Kit de Desenvolvimento de Software (SDK). Embora os dois conceitos operem juntos, eles ocupam camadas distintas da arquitetura de software.

Uma API é estritamente uma especificação de interface e um contrato de comunicação. Ela define as assinaturas de métodos, estruturas de dados, sintaxe de URI conforme a IETF RFC 3986 e formatos de resposta que permitem que um componente de software interaja com outro. As APIs existem em vários níveis: podem ser interfaces locais de sistemas operacionais, interfaces de bibliotecas em processo ou endpoints web remotos sem estado regidos pela semântica HTTP da IETF RFC 9110 (GET, POST). Ao chamar uma API REST remota diretamente, o desenvolvedor do aplicativo deve construir a requisição de rede, gerenciar a segurança do transporte, analisar o payload JSON retornado e tratar condições de nova tentativa manualmente.

Um SDK, por outro lado, é o kit de implementação completo que encapsula uma ou mais APIs locais juntamente com lógica de tempo de execução, documentação e ferramentas de desenvolvimento. Quando um desenvolvedor importa um SDK móvel para um projeto no Android Studio ou Xcode, ele vincula o código de biblioteca pré-construído diretamente ao binário de seu aplicativo. O SDK expõe APIs programáticas locais (como initialize(), getInstallParam() ou handleDeepLink()) para o aplicativo host enquanto gerencia internamente o agendamento de threads, retornos de chamada do sistema operacional e comunicação com servidores remotos.

Contexto de Execução: Endpoints Servidor-para-Servidor Sem Estado vs. Bibliotecas de Tempo de Execução no Lado do Cliente com Estado

A distinção operacional entre invocar uma API web remota e integrar um SDK móvel nativo centra-se no contexto de execução e no acesso ao ambiente do dispositivo:

• Residência de Processo e Empacotamento: Uma API web remota é exposta por meio de infraestrutura no lado do servidor e invocada pela rede; o aplicativo no lado do servidor implementa o endpoint, enquanto o aplicativo cliente executa a lógica de tratamento da requisição. Em contrapartida, um SDK móvel é compilado no artefato de publicação do aplicativo (como um Android App Bundle .aab) ou pacote de aplicativo instalável (.apk no Android e .ipa no iOS) e é executado dentro do espaço de memória alocado do aplicativo no dispositivo do usuário final.
• Conscientização do Ciclo de Vida Nativo: Endpoints REST remotos respondem apenas quando um cliente despacha uma requisição HTTP. Um SDK móvel nativo registra observadores junto ao sistema operacional móvel, permitindo que ele detecte quando o aplicativo é iniciado, faz transições entre os estados de primeiro plano e segundo plano, ou recebe uma intenção de roteamento em nível de sistema.
• Persistência Local Opcional e Enfileiramento: Dependendo de sua implementação, um SDK móvel pode armazenar o estado de configuração ou enfileirar eventos de conversão em armazenamento local isolado em sandbox (como SharedPreferences ou SQLite no Android, e UserDefaults ou armazenamento de arquivos de aplicativo no iOS, reservando o Keychain para pequenas credenciais sensíveis) para que a telemetria possa ser transmitida de forma assíncrona quando houver conectividade de rede disponível.

Comparação Arquitetural: APIs Web Remotas vs. SDKs Móveis Nativos

A tabela abaixo contrasta APIs web sem estado remotas com SDKs móveis nativos compilados em dimensões arquiteturais importantes:

Componentes Principais Dentro de um Kit de Desenvolvimento de Software Móvel

Bibliotecas Binárias Compiladas: Android Archive Bundles e Frameworks iOS

No núcleo de um SDK móvel está uma distribuição binária compilada formatada para a cadeia de ferramentas de compilação do sistema operacional de destino:

• Android Archive (.aar), JAR e App Bundles (.aab): No Android, os SDKs são distribuídos como pacotes .aar ou bibliotecas .jar. Embora um arquivo .jar contenha bytecode JVM compilado, um pacote .aar também pode empacotar recursos específicos do Android e entradas de manifesto que se fundem ao aplicativo host durante as compilações do Gradle. Quando o aplicativo host é compilado para lançamento, um Android App Bundle (.aab) serve como um artefato de publicação em vez de um pacote de aplicativo diretamente instalável; o Google Play o processa em APKs específicos para cada dispositivo que são entregues aos usuários.
• Bibliotecas Estáticas iOS (.a), Frameworks e XCFrameworks: No iOS, os SDKs são distribuídos como bibliotecas estáticas, pacotes .framework ou arquivos .xcframework. Uma compilação .framework padrão normalmente visa a uma variante de plataforma específica e pode conter uma ou mais arquiteturas de CPU suportadas, enquanto um pacote Apple XCFramework (.xcframework) é projetado para empacotar várias variantes de plataforma e arquitetura — como fatias de dispositivos iOS ARM64 físicos juntamente com fatias do Simulador iOS — em um único artefato distribuível.

Arquivos de Cabeçalho Públicos, Contratos de Interface e Definições de Tipo

Binários compilados exigem contratos de tipos públicos para que o compilador do aplicativo host possa verificar chamadas de método em tempo de compilação:

• Arquivos de Cabeçalho iOS (.h) e Interfaces de Ponte: SDKs iOS baseados em Objective-C fornecem arquivos de cabeçalho públicos (como OpoInstallSDK.h) que declaram interfaces de classe, protocolos delegados (OpoInstallDelegate) e modelos de dados (OpoinstallData). Em projetos Swift, essas declarações são expostas por meio de um Header de Ponte (Bridging Header) Objective-C ou importação de módulo.
• Assinaturas de Classes Android e Interfaces de Retorno de Chamada: SDKs Android expõem classes de ponto de entrada público e interfaces de retorno de chamada genéricas (como ResultCallBack<OpoData>) dentro de namespaces de pacotes documentados.

Manifestos de Configuração, AppKeys e Declarações de Direitos

Um SDK móvel depende de metadados de configuração do host para autenticar solicitações de locatários e registrar ganchos de roteamento do SO:

• Identificador de Aplicativo do Locatário (AppKey): Declarado dentro da tag <meta-data> do arquivo AndroidManifest.xml do Android ou do arquivo Info.plist do iOS (com.opoinstall.APP_KEY), a AppKey identifica o locatário do aplicativo durante a inicialização do SDK.
• Declarações de Roteamento do SO: Para dar suporte à inicialização de aplicativos com um clique, o projeto host declara esquemas de URL personalizados e associações de domínio verificadas (domínios applinks: nos direitos de Domínios Associados do Xcode e filtros de intenção verificados no Android).

Documentação e Projetos de Exemplo: Transformando Bibliotecas Compiladas em Interfaces de Desenvolvedor Utilizáveis

Uma biblioteca compilada é difícil de adotar sem especificações claras de integração. SDKs de nível de produção devem fornecer documentação clara para desenvolvedores e, quando disponível, projetos de exemplo executáveis:

• Documentação do Desenvolvedor: Define a compatibilidade de versão, a ordem de inicialização do ciclo de vida, as permissões necessárias, os formatos de payload de retorno de chamada e os códigos de erro para que os engenheiros possam integrar a biblioteca de forma previsível.
• Projetos de Exemplo e Pontes de Múltiplas Plataformas: Projetos de demonstração executáveis mínimos ajudam as equipes a verificar o deep linking e a restauração de parâmetros. Embora o centro de download de SDKs móveis distribua principalmente os pacotes de SDK nativos principais para Android e iOS (atualmente v2.1.0), as equipes que usam frameworks multiplataforma (como Flutter ou Unity) conectam essas capacidades do SDK nativo por meio de plugins wrapper ou canais de plataforma e devem verificar os repositórios de plugins disponíveis com a documentação oficial.

Por Que Apenas APIs Web Não Conseguem Resolver a Atribuição de Instalação Móvel

A Caixa Preta da App Store: Como o Isolamento de Sandbox Quebra o Rastreamento Tradicional de Cookies Web

No desenvolvimento web padrão, o rastreamento de um link de indicação para um evento de registro depende do armazenamento do navegador: quando um usuário visita https://example.com/index.html?inviter_id=A102, o JavaScript lê a string de consulta e armazena inviter_id=A102 no localStorage ou em um cookie HTTP.

Na aquisição de aplicativos móveis, essa continuidade é quebrada na fronteira da app store — uma barreira estrutural conhecida como a Caixa Preta da App Store:

1. Contexto Web: Um usuário clica em um link promocional dentro de um navegador móvel ou aplicativo social, carregando uma página de destino H5 que carrega parâmetros personalizados (?ref=userA&channelCode=ch_01).
2. Transferência do Marketplace: Como o aplicativo nativo ainda não está instalado, clicar no botão de download redireciona o usuário para fora do navegador e para a Apple App Store ou Google Play Store.
3. Isolamento de Sandbox: Quando o usuário instala e inicia o aplicativo nativo, o sistema operacional móvel gera o processo dentro de um sistema de arquivos isolado e um sandbox de memória. O aplicativo nativo não consegue ler os cookies ou o localStorage da sessão do navegador que iniciou o download.

Preenchendo a Lacuna Web-para-App: O Papel de SDKs Web JS e SDKs de Cliente Nativos

A resolução de parâmetros na fronteira da app store utiliza um fluxo de trabalho coordenado que separa três conceitos relacionados — Deferred Deep Linking (roteamento de um novo usuário para uma tela interna de destino após a instalação), Restauração de Parâmetros de Instalação (recuperação de pares de chave-valor personalizados passados no link H5) e Correspondência de Atribuição (associação da instalação a um canal promocional específico):

• SDK Web JS Pré-Install (Script Web OpoInstall): Integrado à página de destino H5, o SDK Web JS analisa os parâmetros de consulta dinâmicos da URL de compartilhamento (como channelCode, shareCode ou IDs de sala) e faz o upload do contexto da sessão pré-instalação para o servidor de atribuição antes de acionar a ativação do aplicativo ou o redirecionamento para a loja.
• SDK de Cliente Nativo Pós-Install (SDK Android / iOS): Integrado ao binário do aplicativo móvel, o SDK nativo é inicializado na primeira execução, comunica-se com as APIs da plataforma e o servidor de atribuição, e retorna os parâmetros personalizados restaurados para o aplicativo cliente por meio de um retorno de chamada assíncrono.

[Navegador Web Móvel: Página de Destino H5]
                 |
                 | 1. SDK Web JS Analisa Parâmetros da URL (?ref=userA&channelCode=ch01)
                 |    & Faz o Upload do Contexto de Sessão Pré-Instalação
                 v
     [Backend do Servidor de Atribuição]
                 |
                 | 2. Usuário Baixa o Aplicativo da App Store / Google Play
                 |    (Cookies do Navegador Não Podem Cruzar o Sandbox do SO)
                 v
   [Primeira Execução do App Nativo: SDK Móvel]
                 |
                 | 3. SDK do Cliente Inicializa na Inicialização & Recupera
                 |    Parâmetros Personalizados em Cache + ID do Canal
                 v
  [Roteamento No Aplicativo & Atribuição de Canal]

Mecânicas de Atribuição Específicas da Plataforma: Google Play Install Referrer vs. Reconciliação de Contexto iOS

Como o Android e o iOS mantêm arquiteturas de app store diferentes, a atribuição móvel depende de mecanismos distintos da plataforma:

• Ecossistema Android e a API Google Play Install Referrer: Para aplicativos distribuídos pelo Google Play, a integração nativa pode usar a oficial API Google Play Install Referrer para recuperar metadados de indicação (incluindo a URL do referenciador e os carimbos de data/hora de clique/instalação) passados pela Play Store durante a instalação. Como a API Google Play Install Referrer se aplica especificamente a fluxos de instalação elegíveis da Google Play Store, distribuições Android fora do Google Play dependem da correspondência de parâmetros H5 do lado do servidor ou de Pacotes de Canais Android exportados (arquivos APK que carregam identificadores channelCode embutidos).
• Ecossistema iOS e Reconciliação de Contexto: A App Store da Apple não fornece um mecanismo geral de passagem de parâmetros de consulta de URL equivalente ao Install Referrer do Google Play. Quando o aplicativo já está instalado, o iOS direciona os usuários diretamente para dentro do aplicativo por meio de Apple Universal Links, que verificam a propriedade do domínio por meio de um arquivo apple-app-site-association (AASA). Quando o aplicativo não está instalado, os Universal Links recorrem a um site e não garantem independentemente a recuperação de parâmetros pós-instalação; a restauração de parâmetros adiados requer a reconciliação de sessões no lado do servidor na primeira execução.

Respeitando as Fronteiras de Privacidade da Plataforma: Diretrizes de Privacidade do Usuário da Apple e Sinais de Correspondência Permitidos

Ao avaliar como os SDKs móveis reconciliam visitas web pré-instalação com lançamentos pós-instalação, as equipes de engenharia devem distinguir recursos documentados pelo fornecedor da conformidade com as políticas do sistema operacional:

• Mecanismo Documentado pelo Fornecedor: A documentação pública de produtos da OpoInstall descreve um fluxo de trabalho de canal H5 e instalação de parâmetros onde o Web SDK coleta traços de impressão digital (fingerprint) do dispositivo e IDs de canal na página H5, e o SDK nativo Android/iOS recoleta os traços do dispositivo na primeira execução para corresponder à origem da instalação.
• Fronteira de Política da Plataforma Apple: Sob as Diretrizes de Privacidade e Uso de Dados do Usuário da Apple, a Apple proíbe explicitamente derivar dados de um dispositivo — como combinar propriedades de navegador, endereços IP ou configurações do sistema — com a finalidade de identificar unicamente um usuário ou dispositivo (fingerprinting). Aplicativos que realizam fingerprinting proibido, ou que fazem referência a SDKs de terceiros que o fazem, correm o risco de rejeição durante a análise da App Store. Separadamente, a autorização de Transparência no Rastreamento de Aplicativos (ATT) é necessária quando serviços terceirizados de deep-linking ou deferred deep-linking passam identificadores exclusivos ou criam identidades de usuário compartilhadas em aplicativos de diferentes empresas para direcionamento de anúncios, medição de anúncios ou compartilhamento com corretores de dados. No entanto, o consentimento da ATT não torna o fingerprinting de dispositivo proibido aceitável.
• Escalada de Conformidade e Requisito de Verificação: Se uma versão específica de SDK ou configuração depender de fingerprinting de dispositivo proibido, nem a condução de uma auditoria geral de dados internos nem a obtenção de consentimento do usuário por meio do prompt da ATT tornarão esse mecanismo compatível com as diretrizes da Apple. Se o fornecedor não puder demonstrar que o mecanismo de correspondência do iOS evita o fingerprinting de dispositivo proibido, os desenvolvedores não devem implantar esse mecanismo de atribuição no iOS até que uma alternativa compatível tenha sido verificada de forma independente, seguindo as práticas de governança de Segurança de Aplicativos Móveis da OWASP.
• Tempo de Rede e Fallbacks Não Atribuídos: Embora o iOS não exponha uma permissão geral concedida pelo usuário para acesso comum à internet (os desenvolvedores devem distinguir a acessibilidade geral à internet da permissão de privacidade de Rede Local da Apple, que se aplica à descoberta de dispositivos em rede local), a inicialização do SDK e a recuperação de parâmetros ainda dependem da disponibilidade de rede e do tempo de inicialização. Como a correspondência adiada não é garantida em todas as condições de rede ou primeiras execuções atrasadas, os aplicativos devem sempre implementar fluxos de fallback elegantes quando os parâmetros retornados estiverem vazios.

Como um SDK de Atribuição Móvel Funciona em Todo o Ciclo de Vida do Aplicativo

Fase 1: Gerenciamento de Dependências e Vinculação em Tempo de Compilação via Gradle e CocoaPods

O ciclo de vida de um SDK começa no momento da compilação, quando o desenvolvedor declara a dependência da biblioteca por meio do Gradle, CocoaPods ou importação manual de arquivos compactados. Durante a compilação, o gerenciador de pacotes resolve o artefato da biblioteca e vincula seus símbolos binários ao pacote do aplicativo. Alguns SDKs móveis exigem considerações específicas de compatibilidade de compactação de código em compilações de lançamento, e as integrações de SDK do iOS também podem exigir declarações de manifesto de privacidade específicas da plataforma e configurações de compilação compatíveis.

Fase 2: Inicialização na Thread Principal na Inicialização do Aplicativo

Quando um usuário inicia o aplicativo, o SO móvel cria o processo do aplicativo e invoca o gancho de ciclo de vida do ponto de entrada principal — Application.onCreate() no Android, conforme detalhado no Guia de Desenvolvedores Android do Google sobre o Ciclo de Vida do Aplicativo, e application(_:didFinishLaunchingWithOptions:) no iOS, conforme detalhado na Documentação do Desenvolvedor Apple sobre UIApplicationDelegate. Um SDK móvel bem projetado deve minimizar o trabalho durante a inicialização do aplicativo e mover as operações de rede para a execução assíncrona. Os desenvolvedores devem verificar o comportamento real de inicialização e medir o desempenho de inicialização a frio em sua compilação de destino.

Fase 3: Interceptando Deep Links Nativos por Meio de Universal Links e Filtros de Intenção

Quando o aplicativo já está instalado e um usuário toca em um link H5, o SO ativa o aplicativo e entrega o contexto de roteamento ao SDK por meio de pontos de entrada específicos da plataforma:

• Esquemas Personalizados do Android vs. App Links Verificados: Os esquemas de URL personalizados (scheme://) são roteados por meio de um filtro <intent-filter> BROWSABLE básico. O suporte a Android App Links verificados exige um <intent-filter android:autoVerify="true"> que declare os esquemas http e https juntamente com o android:host de destino, respaldado por um arquivo de Links de Ativos Digitais /.well-known/assetlinks.json contendo o nome do pacote do aplicativo e a impressão digital do certificado de assinatura SHA-256.
• Roteamento via AppDelegate e UISceneDelegate no iOS: Os Universal Links entregam um NSUserActivity ao AppDelegate em aplicativos de ciclo de vida tradicionais, ou — para aplicativos iOS 13+ que adotam ciclos de vida baseados em cena por meio de UISceneDelegate — ao método scene(_:willConnectTo:options:) na inicialização a frio e scene(_:continue:) na retomada a quente.

Fase 4: Restauração de Parâmetros Assíncronos e Enfileiramento de Telemetria de Eventos

Na primeira inicialização — ou quando ocorrem marcos de conversão de negócios —, o aplicativo host invoca os métodos assíncronos do SDK para recuperar os parâmetros de instalação em cache (data e channelCode) e relatar eventos de conversão a jusante (como registros de contas ou pontos de efeito personalizados).

Implementando Ganchos de Ciclo de Vida de SDK Nativos no Android e iOS

Configurando Identificadores de Aplicativo e Verificando Lançamentos de SDK

Os padrões de integração ilustrativos abaixo seguem a documentação pública de integração da OpoInstall para demonstrar como os projetos nativos Android e iOS conectam os ganchos de ciclo de vida descritos acima. Como o centro de download distribui arquivos de SDK atualizados (atualmente v2.1.0, lançado em 2026-09-20), enquanto os exemplos de documentação podem fazer referência a coordenadas secundárias anteriores, as equipes de engenharia devem baixar o pacote de SDK v2.1.0 de destino, verificar todos os caminhos de importação e assinaturas de métodos com os cabeçalhos de biblioteca empacotados, e executar uma verificação de compilação limpa no Android Studio e no Xcode antes da implantação em produção. Consulte a documentação técnica da OpoInstall para obter instruções de integração específicas de lançamento.

Padrão de Inicialização e Recuperação de Parâmetros do SDK Android

No arquivo AndroidManifest.xml, declare as permissões de rede, a AppKey do locatário e blocos <intent-filter> separados para ativação de esquema de URL personalizado e Android App Links verificados (declarando os esquemas http e https por requisitos de verificação de Android App Links, e substituindo links.example.com pelo seu domínio verificado):

<!-- File: app/src/main/AndroidManifest.xml (Illustrative Integration Pattern) -->
<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. Custom URL Scheme wakeup filter -->
            <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. Verified Android App Links filter (requires /.well-known/assetlinks.json with SHA-256 cert fingerprint) -->
            <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>

// File: 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);
    }
}

// File: app/src/main/java/com/example/app/MainActivity.java
// Note: Verify exact package imports and callback signatures against your downloaded SDK v2.1.0 archive.
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);

        // Process wakeup intent if launched via custom scheme or verified App Link
        getWakeUpData(getIntent());

        // Retrieve deferred installation parameters when needed by onboarding logic
        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);
            }
        });
    }
}

Padrão de Registro de Delegado do SDK iOS e Ativação via SceneDelegate

No iOS, exponha #import "OpoInstallSDK.h" em seu Bridging Header em Objective-C, configure com.opoinstall.APP_KEY em Info.plist e implemente OpoInstallDelegate. Use os métodos de tratamento de URL do AppDelegate para aplicativos que não adotam o gerenciamento de ciclo de vida baseado em cena; para aplicativos baseados em cena, processe Universal Links e esquemas de URL de inicialização a frio e retomada a quente por meio dos métodos correspondentes do SceneDelegate:

// File: AppDelegate.swift & SceneDelegate.swift (Illustrative Integration Pattern)
// Note: Verify exact Objective-C bridging headers and method signatures against your downloaded iOS SDK v2.1.0 archive.
import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

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

    // For apps that do NOT adopt UISceneDelegate lifecycle management:
    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 data: \(String(describing: appData?.data)), channelCode: \(String(describing: appData?.channelCode))")
    }

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

// For iOS 13+ apps that adopt UISceneDelegate lifecycle management:
@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)
        }
    }
}

Quando as Equipes de Engenharia Devem Integrar um SDK Móvel de Terceiros

Cenários Adequados para Integrar um SDK Móvel Especializado

A integração de um SDK dedicado de atribuição e deep-linking é apropriada sob as seguintes condições:

• Fluxos de Indicação e Onboarding Sem Código: Aplicativos que executam programas de indicação ou convites para salas multiplayer onde os parâmetros (?ref=userA ou room_id=402) devem ser restaurados após a instalação pela loja, sem necessidade de entrada manual de código.
• Campanhas H5 e de QR Code Multicanal: Equipes de marketing que distribuem links em redes sociais, QR codes offline e pacotes de canais Android que exigem rastreamento unificado de visitas, cliques, instalações e registros.
• Lançamentos Web-para-App com Um Clique: Produtos que direcionam usuários de aplicativos existentes diretamente de navegadores móveis para visualizações específicas no aplicativo por meio de Universal Links e App Links, enquanto guiam usuários não instaladores para a app store apropriada.

Cenários Onde uma API REST Direta É Suficiente

Por outro lado, um SDK de atribuição no lado do cliente é desnecessário quando o fluxo de trabalho não cruza sandboxes móveis nativos:

• Transações de Backend Autenticadas: Quando um usuário já autenticado renova uma assinatura ou aciona um webhook de faturamento de backend, registrar essa conversão por meio de uma API REST Direta Servidor-para-Servidor (S2S) evita atualizações de dependências do cliente.
• Aplicações Web Exclusivas de Navegador: Progressive Web Apps (PWAs) e sites móveis que não distribuem binários nativos por meio da App Store ou do Google Play podem rastrear indicações usando cookies web primários padrão e parâmetros de consulta de URL.

Equívocos Comuns de Engenharia Sobre SDKs Móveis

• Equívoco 1: Integrar um SDK Móvel Bloqueia Automaticamente a Inicialização a Frio do Aplicativo: Um SDK móvel bem projetado minimiza o trabalho durante Application.onCreate() ou didFinishLaunchingWithOptions: e move as operações de rede para a execução assíncrona, embora os desenvolvedores devam sempre analisar a latência de inicialização a frio em sua compilação de destino.
• Equívoco 2: Pacotes de Canais Android Substituem IDs de Canal de Links H5: Quando um aplicativo Android usa tanto APKs de canais exportados quanto links de canais H5, o SDK da OpoInstall permite que parâmetros personalizados e IDs de canal sejam recuperados juntos; de acordo com a documentação do produto da OpoInstall, se uma instalação se originar de um link de canal H5 com um channelCode distinto, o ID do link de canal H5 terá prioridade sobre o ID do pacote de canal nos relatórios estatísticos.

Resumo e Estrutura de Decisão Arquitetural

Compreender o que é um SDK e como ele funciona dentro de sandboxes de sistemas operacionais móveis permite que as equipes de engenharia projetem arquiteturas confiáveis de aquisição de usuários e deep-linking. Enquanto as APIs web sem estado lidam com a comunicação de servidores remotos, uma integração nativa no lado do cliente é necessária quando um aplicativo precisa participar de eventos de nativos de ciclo de vida ou recuperar sinais de instalação específicos da plataforma, e um SDK móvel empacota essas capacidades em uma camada de integração reutilizável.

Ao decidir como estruturar seu pipeline de atribuição, siga estas diretrizes de engenharia:

• Implante um SDK Móvel Nativo: Quando as jornadas do usuário transicionam de páginas de destino H5, compartilhamentos sociais ou QR codes através da App Store ou do Google Play e exigem restauração automatizada de parâmetros ou roteamento de Universal Link / App Link com um clique.

• Use APIs HTTP Servidor-para-Servidor: Ao exportar estatísticas de canais agregadas para um data warehouse interno, ou ao registrar eventos de backend que não dependem do contexto de lançamento do lado do cliente.

• Verifique a Compilação Binária e a Conformidade com a Privacidade da Plataforma: Sempre teste a compilação do arquivo compactado do SDK de destino (como a v2.1.0) em um projeto limpo e confirme com o fornecedor se qualquer mecanismo de correspondência do iOS evita o fingerprinting de dispositivo proibido antes do lançamento em produção.

As equipes de engenharia que avaliam a infraestrutura de atribuição podem registrar uma chave de aplicativo no console de desenvolvedores da OpoInstall para testar a restauração de parâmetros e o roteamento de deep-link em um ambiente de staging.

Materiais Relacionados

• Conceitos: Kit de Desenvolvimento de Software, Interface de Programação de Aplicativos, Deferred Deep Linking, Isolamento de Sandbox do SO

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

• Padrões: Semântica HTTP IETF RFC 9110, Sintaxe Genérica de URI IETF RFC 3986, Projeto de Segurança de Aplicativos Móveis da OWASP

• Interfaces de Plataforma e Integração: Android Application.onCreate, iOS UIApplicationDelegate, UISceneDelegate, NSUserActivity

• Documentação Oficial e Referências:

  • Guia de Desenvolvedores Android do Google sobre o Ciclo de Vida do Aplicativo

  • Guia de Desenvolvedores Android do Google sobre App Links

  • Guia Técnico da API Google Play Install Referrer

  • Documentação do Desenvolvedor Apple sobre UIApplicationDelegate

  • Documentação do Desenvolvedor Apple sobre UISceneDelegate

  • Documentação do Desenvolvedor Apple sobre Suporte a Universal Links

  • Documentação do Desenvolvedor Apple sobre Criação de um Pacote de Framework Binário Multiplataforma (XCFramework)

  • Diretrizes de Privacidade e Uso de Dados do Usuário da Apple