ATAK (Android Team Awareness Kit) et son équivalent desktop WinTAK sont les applications de conscience situationnelle tactique de fait utilisées par les forces américaines et NATO, les militaires alliés, et de plus en plus par les primo-intervenants civils. Ils restituent une image opérationnelle commune partagée (COP), échangent des messages Cursor-on-Target (CoT) via TAK Server, gèrent les couches cartographiques et hébergent un SDK de plugin ouvert. Pour les ingénieurs logiciels de défense, construire un plugin ATAK ou WinTAK est généralement le chemin le plus rapide vers une capacité déployée — des ordres de grandeur plus rapide que livrer une application tactique autonome.
Cet article est un guide d'ingénierie : du projet Android Studio vide à un plugin signé et distribuable qui survit à la journée d'un véritable opérateur. Il suppose que vous avez demandé et obtenu le SDK ATAK-CIV depuis tak.gov et que vous disposez d'une instance TAK Server à laquelle vous pouvez vous connecter.
Pourquoi des plugins ATAK/WinTAK
La raison stratégique de construire un plugin plutôt qu'une application autonome est l'effet de levier. ATAK résout déjà les problèmes difficiles : rendu cartographique avec sources vectorielles et raster, gestion du GPS, intégration radio, messagerie CoT, découverte multicast, transport TAK Server chiffré, identité utilisateur et un modèle de navigation que les opérateurs ont appris pendant des années. Un plugin hérite gratuitement de tout cela.
La raison tactique est l'adoption. Un opérateur qui utilise déjà ATAK sur un Samsung S22 Tactical Edition ou un Galaxy XCover avec un harnais de poitrine installera un autre plugin en quelques secondes. Convaincre le même opérateur d'installer, d'apprendre et de faire confiance à une seconde application tactique autonome est un chemin à friction beaucoup plus élevée. Les plugins exploitent la surface de confiance existante. Pour de nouveaux capteurs, des flux de travail spécifiques à une mission, l'intégration de drones ou des traducteurs de messages spécifiques NATO, un plugin est presque toujours le bon format de livraison.
ATAK est une plateforme, pas seulement une application. Le traiter comme une plateforme — et votre code comme un participant aux contrats de cette plateforme — est le changement d'état d'esprit nécessaire pour livrer des plugins qui passent la revue opérateur.
ATAK-CIV vs ATAK-MIL
Il existe deux éditions ATAK qui intéressent un auteur de plugin. ATAK-CIV est la version civile distribuée via Google Play Store et via tak.gov pour un usage non restreint. ATAK-MIL est la variante militaire maintenue par le U.S. Army DEVCOM C5ISR Center et distribuée uniquement via des canaux contrôlés aux unités autorisées.
Du point de vue SDK, les deux partagent une API de plugin commune — le même AbstractPlugin, la même MapView, le même CotEventDispatcher. Les différences qui comptent pour un ingénieur plugin sont : ATAK-MIL inclut des adaptateurs pour données classifiées, une symbologie spécifique militaire (MIL-STD-2525D entièrement peuplé), des pilotes radio pour SRW, ANW2C, passerelles Link 16, et des contrôles de sécurité qui filtrent le chargement de plugins par clé de signature. Un plugin compilé contre ATAK-CIV se chargera contre ATAK-MIL pourvu que la version d'API corresponde et que le plugin soit signé par une clé approuvée — mais les hypothèses UI et de capacité peuvent casser si vous dépendez de widgets qui n'existent que dans une édition.
Prototypez sur ATAK-CIV. Le SDK est ouvert, les exigences matérielles sont moindres, et vous pouvez itérer contre un TAK Server public. Une fois la capacité éprouvée, portez vers ATAK-MIL : re-signez avec la chaîne de signature militaire approuvée, validez contre la version d'API cible et retestez sur les véritables appareils de l'utilisateur final (typiquement des Samsung classe EUD ou des afficheurs MPU5 de Persistent Systems).
Squelette de projet
Un plugin ATAK est un module bibliothèque Android avec un contrat de manifeste spécifique. Partez du projet Gradle plugin-template livré dans le SDK ATAK-CIV. Les dépendances qui comptent : le main.jar du SDK (API ATAK), le plugin Gradle gradle-atak-plugin et les bibliothèques AndroidX épinglées aux versions livrées par ATAK lui-même — un décalage de version est une cause fréquente de NoSuchMethodError à l'exécution.
Le AndroidManifest.xml doit déclarer les métadonnées du descripteur de plugin : com.atakmap.app.component pointant vers votre sous-classe d'AbstractPlugin, la version d'API ciblée et les permissions requises. ATAK utilise le manifeste pour découvrir et charger les plugins ; un descripteur incorrect est la raison la plus fréquente pour laquelle un plugin n'apparaît pas dans le gestionnaire de plugins ATAK.
Les hooks de cycle de vie vivent sur AbstractPlugin (aussi exposés comme IPlugin dans les versions plus récentes du SDK). onCreate(Context, MapView) est l'endroit où vous enregistrez outils, drop-downs, couches et listeners. onDestroyImpl est l'endroit où vous devez les désenregistrer — ne pas le faire provoque des fuites de listeners entre rechargements de plugins, un scénario réel lors de mises à jour opérateur. onConfigurationChanged gère la rotation de l'appareil et les changements de thème. Traitez les méthodes du cycle de vie comme celles d'une Activity Android : supposez qu'elles puissent être appelées plusieurs fois dans des ordres inattendus.
La compatibilité de version d'API est imposée au chargement. ATAK 4.x à 5.x a livré des changements d'API cassants ; épinglez PluginAPI dans votre manifeste à la version la plus basse que vous supportez, et testez contre chaque version mineure dans votre déploiement cible. Une matrice de compatibilité dans votre README — « ce plugin : ATAK-CIV 4.10 à 5.2, ATAK-MIL 5.0+ » — est le contrat que les opérateurs vous opposeront.
Intégration CoT
Cursor-on-Target (CoT) est le format de message XML que chaque participant de l'écosystème TAK parle. Chaque événement CoT a un UID, un code de type (une chaîne hiérarchique comme a-f-G-U-C-I pour unité terrestre amie, combat, infanterie), un point (lat/lon/hae), un horodatage, une heure d'obsolescence et des enfants détaillants arbitraires. Les plugins émettent du CoT pour signaler des contacts capteurs, des missions, des géofences et des types de piste personnalisés ; ils consomment du CoT pour réagir aux événements que l'opérateur ou d'autres systèmes produisent.
Les deux surfaces d'API qui comptent : CotMapComponent expose le CotEventDispatcher central pour les événements entrants, et CotMapComponent.getInternalDispatcher() plus CommsMapComponent.getInstance().sendCoT(event) pour les sortants. Enregistrez un CotEventListener dans onCreate, filtrez sur le préfixe de type, et dispatchez vers la logique métier de votre plugin. Pour les événements sortants, construisez le CotEvent par programme — ne concaténez pas de chaînes XML. Des opérateurs ont perdu des icônes de piste à cause d'un XML malformé produit par templating de chaînes.
La validation de schéma empêche la corruption des données tactiques. Validez chaque événement CoT entrant contre le schéma de détail attendu avant de faire confiance à son contenu — code de type, bornes de point (une latitude de 9000 est un bug de parseur quelque part en amont que vous ne voulez pas propager dans votre overlay), et monotonie de l'heure d'obsolescence. CoT est permissif par conception ; le parsing défensif est la responsabilité de l'auteur du plugin.
Plugins de couche cartographique
Le motif de plugin ATAK le plus courant est l'ajout d'une superposition cartographique personnalisée : télémétrie de drone, couverture de signal EW (guerre électronique), éventails d'artillerie amie, zones interdites de frappe, estimations de couverture radio maillée. La pile cartographique d'ATAK est GLMapView (OpenGL ES) avec un modèle d'ordre de couches basé sur un z-order entier plus des groupes de visibilité.
Ajoutez des couches en sous-classant AbstractLayer pour les données vectorielles ou en étendant TileClientControl pour les superpositions raster. MapItem est l'unité de contenu interactif — marqueurs, formes, primitives de dessin — et possède un cycle de vie complet : onMapItemEvent se déclenche pour clics, déplacements, suppressions et changements de visibilité. Les plugins à longue durée de vie doivent retirer leurs MapItems dans onDestroyImpl ; les éléments orphelins persistent à travers les rechargements de plugins et désorientent les opérateurs.
La performance compte plus que les gens ne le pensent. Des milliers d'éléments à la fois est normal — un flux ISR à grande zone produit facilement de 5 000 à 20 000 pistes visibles. Regroupez agressivement, utilisez Marker.setVisible(false) plutôt que supprimer/recréer, et déchargez les calculs lourds (buffers géodésiques, calculs de viewshed) hors du thread UI. Visez 60 fps sur un Samsung S22 Tactical ; sinon, votre plugin sera désinstallé.
Discipline UI
Les conventions UI d'ATAK existent pour une raison : un opérateur portant des gants, en faible luminosité, possiblement sous le feu, navigue par mémoire musculaire. Les Drop-Downs (le panneau coulissant de droite) sont la manière canonique de faire émerger l'UI du plugin. Étendez DropDownReceiver, enregistrez votre action d'intent, et laissez ATAK gérer le cycle de vie show/hide. N'affichez pas vos propres fenêtres de dialogue par-dessus la carte — elles cassent la pile de gestes carte et désorientent les opérateurs.
Le placement du menu de navigation est régi par l'enregistrement d'outils. Utilisez ToolbarBroadcastReceiver ou l'API plus récente de panneau plugin pour placer votre point d'entrée dans la barre d'outils de droite ou le tiroir de débordement. Le nommage compte : verbes courts (« Track », « Mark », « Scan »), pas des noms (« Tracking Manager »). Les icônes doivent être lisibles à 24dp sur un écran de 5 pouces en plein soleil — cela signifie haut contraste, une seule forme de premier plan, sans dégradé.
Le mode sombre est le seul mode. Le thème par défaut d'ATAK est construit pour l'opération en faible luminosité et la compatibilité vision nocturne. N'introduisez jamais un fond blanc dans un Drop-Down — il inonde l'optique NV de l'opérateur et annonce sa position. Utilisez les constantes de thème ATAK (atakmap.android.R.style.ATAK_TextAppearance et autres) pour que vos widgets adoptent le profil préféré de l'opérateur, y compris le mode lumière rouge compatible NVG.
Signature et distribution du plugin
ATAK impose la signature des plugins comme une barrière au chargement. Chaque APK de plugin doit être signé avec une clé que l'installation ATAK en cours d'exécution fait confiance. ATAK-CIV livre un magasin de confiance permissif qui accepte la clé de debug de développement plus un petit ensemble de clés communautaires ; ATAK-MIL n'accepte que les clés émises par l'autorité militaire contrôlante. Planifiez la signature tôt — re-signer un plugin déjà entre les mains des opérateurs nécessite une redistribution.
La chaîne de signature est Android standard : keytool pour générer le keystore, jarsigner ou les signingConfigs Gradle pour signer l'APK, apksigner v2/v3 pour vérifier. ATAK valide la signature au chargement et affiche « Plugin signature invalid » dans le gestionnaire de plugins lorsqu'elle échoue — une erreur générique qui, en pratique, signifie presque toujours une discordance de clé ou de version du schéma de signature APK.
Les chemins de distribution varient par édition. Les plugins ATAK-CIV se distribuent via le Play Store, tak.gov, ou sideload via le récupérateur d'URL du gestionnaire de plugins. Les plugins ATAK-MIL se distribuent via les magasins d'applications militaires (dépôts NIPRNet/SIPRNet, canaux MDM spécifiques à l'unité) avec des cycles de validation pouvant prendre des semaines. L'épinglage de version est contractuel : un déploiement MDM verrouille typiquement à la fois les versions ATAK et plugin, et une mise à jour de plugin hors-bande n'est pas une option une fois qu'une rotation est déployée.
Réalités de production
La batterie est la première contrainte de production. Un plugin qui réveille le GPS chaque seconde ou maintient un wake-lock partiel videra une batterie EUD avant la fin d'une patrouille de quatre heures. Profilez avec Battery Historian d'Android, préférez les services de localisation existants d'ATAK (qui dédupliquent déjà les fixes à travers les plugins), et ne planifiez jamais de travail d'arrière-plan qui ne dépend pas d'une intention opérateur.
L'opération à faible réseau est la deuxième. ATAK est conçu pour fonctionner déconnecté et de manière intermittente ; tout plugin qui suppose une joignabilité IP échoue dès que l'opérateur quitte la FOB. Mettez en file d'attente sur disque le travail sortant, drainez à la reconnexion, et dégradez gracieusement — les motifs sont les mêmes que ceux des applications militaires offline-first et de la pile cartographique MBTiles/PMTiles hors ligne qu'ATAK lui-même utilise.
La télémétrie est la troisième, et la plus contrainte. L'OPSEC exige que les plugins n'appellent pas à la maison — ni vers votre point de terminaison analytique, ni vers un reporter de crash, ni vers un serveur de licences. Intégrez la télémétrie dans le fichier de log local qu'ATAK maintient déjà, exposez-la par l'export du bundle de debug ATAK, et laissez l'unité décider s'il faut partager. L'instinct de livrer Firebase Crashlytics dans un plugin tactique mettra fin à l'autorisation de déploiement du plugin.
Les cycles de support s'alignent sur la cadence de release d'ATAK, pas sur votre feuille de route. ATAK-CIV sort environ trimestriellement ; ATAK-MIL sort selon des calendriers militaires qui peuvent étendre une seule version pendant 18 mois. Maintenez une fenêtre de support glissante — la version actuelle plus les deux versions mineures précédentes est un contrat soutenable — et traitez les notes de version ATAK comme un intrant obligatoire de votre plan de régression. Une capacité qui s'intègre à des systèmes C2 plus larges ou alimente des liaisons de données tactiques NATO via un plugin n'est fiable qu'à la mesure de votre discipline autour du train de releases ATAK.