TAK data packages and mission packages: structure and distribution

The TAK ecosystem moves a lot of content that is not a Cursor on Target track: overlays, imagery, geofences, route plans, plugin updates, and certificate bundles. The mechanism that carries all of it is the data package — a plain zip file with a manifest. Understanding the package format is the difference between a fleet that shares a common operating picture cleanly and one that drowns in stale overlays and mismatched map layers. This is an engineering walkthrough of how data packages and mission packages are structured, how TAK Server synchronizes them, and how to generate them in a pipeline.

1. what a data package is

A TAK data package is a zip archive containing a single required file — MANIFEST.xml — and an arbitrary set of payload files referenced by that manifest. That is the entire definition. The zip is the transport container; the manifest is the index that tells ATAK, WinTAK, or iTAK what is inside and how to handle each item on receipt. Because the format is just zip plus an XML descriptor, a data package is the universal unit of content exchange across the whole TAK family: anything a client can render or install can be wrapped in one.

When a client imports a package, it unzips into the application's working directory, parses the manifest, and dispatches each content entry to the subsystem that owns it. A KML goes to the overlay manager, a CoT XML goes to the map as map items, an imagery file goes to the data store, an APK goes to the plugin installer. The package itself is ephemeral — once imported, the client keeps the extracted artifacts, not the zip. This single design decision (manifest-driven dispatch) is what lets one container carry a heterogeneous bundle and have every piece land in the right place.

2. the MANIFEST.xml

The manifest is a small XML document with two top-level sections under the root <MissionPackageManifest> element. The first is <Configuration>, a list of <Parameter> elements that describe the package as a whole. The two that always appear are uid (a unique identifier, conventionally a UUID, that the client uses to deduplicate and replace prior imports) and name (the human-readable label shown in the package importer). A third common parameter is onReceiveDelete — a boolean that, when true, tells the receiving client to delete the package's content automatically when the package is removed, rather than leaving its artifacts behind.

The second section is <Contents>, a list of <Content> entries. Each entry has a zipEntry attribute giving the path of the payload file inside the zip, and an ignore attribute that controls whether the client treats the file as imported content or merely as a supporting resource. Content entries may also carry nested parameters — for example a CoT file can declare its own uid so the client maps it to a specific map item. A minimal manifest looks like this:

<MissionPackageManifest version="2"><Configuration><Parameter name="uid" value="b3f1…"/><Parameter name="name" value="OP GRANITE overlay"/><Parameter name="onReceiveDelete" value="true"/></Configuration><Contents><Content ignore="false" zipEntry="overlay.kml"/><Content ignore="false" zipEntry="aoi.cot"/></Contents></MissionPackageManifest>

The version="2" attribute matters: it selects the manifest schema the client parses against, and getting it wrong is the most common reason a hand-built package silently fails to import.

3. data packages vs mission packages

The terms are used loosely, but the distinction is real and architectural. A data package is the generic zip-plus-manifest artifact — an ad-hoc bundle you hand to another operator. A mission package is that same artifact when it is bound to a persistent, server-backed mission on TAK Server. The container format is identical; what differs is lifecycle and ownership.

An ad-hoc data package is fire-and-forget: you build it, you send it, the recipient imports it, and there is no further relationship between the sender's copy and the receiver's copy. A mission package lives inside a mission — a named, access-controlled collection on the server that clients subscribe to. When the mission changes, every subscriber is notified and pulls the delta. Use an ad-hoc data package when you need a one-time transfer between two or three operators in the field. Use a mission when you need a unit-wide, continuously updated shared picture that new joiners can pull in full and that survives a client reinstall.

4. package contents

A package can carry essentially any artifact the TAK clients understand. The common payloads:

CoT events. Static Cursor on Target XML — points, areas, routes — that materialize as map items on import. This is how you ship a pre-planned set of control measures or a fixed laydown of friendly positions.

KML/KMZ overlays. Vector overlays for boundaries, phase lines, no-fire areas, and corridors. KMZ bundles its own referenced imagery and styling, so it travels well inside a package.

Imagery and basemaps. GeoTIFF, MBTiles, and GeoPackage tile sets for offline map coverage of an area of operations — frequently the largest item in a package by far, and the reason package size discipline matters.

Geofences. A CoT event with geofence attributes that the client arms as an alerting boundary — breach and entry notifications fire locally on the device. A geofence package is a standard way to push standing alert zones to a squad.

Certificates. Client enrollment and trust-store bundles, used to onboard a device to a TAK Server with the right CA chain and client certificate in one import.

Plugin APKs. ATAK plugin binaries, shipped so an operator can install or update a capability without an app store. Building those plugins is its own discipline — see our note on ATAK/WinTAK plugin engineering — but distributing them is just another content entry in a manifest.

5. TAK Server data sync

On the server side, the machinery behind missions is the Enterprise Sync store — a content-addressed object store keyed by the file's hash. Every artifact uploaded to the server is stored once under its hash; missions then reference those hashes rather than holding copies. A mission is metadata plus a list of content references and a stream of changes.

Clients interact through a small set of mission APIs. A client subscribes to a mission, then receives change-feed events — content added, content removed, mission detail updated — as CoT messages over its existing server connection. When a relevant change arrives, the client pulls the new content from Enterprise Sync by hash. Because the store is content-addressed, a file already present on the device is never re-downloaded: the hash match short-circuits the transfer. This is what makes a mission scale to a full unit — only deltas move, and identical artifacts are deduplicated end to end.

6. distribution paths

There are three practical ways content reaches a device. The first is peer transfer — the QuickPic / "send to contact" path, where one client zips a package and pushes it directly to another client over the TAK mesh or through the server as a relay. This is the field-expedient route: no mission, no subscription, just an operator handing a bundle to the operator next to them.

The second is server upload and download. An operator or an external system uploads a package to TAK Server; other clients download it on demand from the data-package list. This decouples producer from consumer in time — the package waits on the server until someone pulls it.

The third is mission auto-import. A subscriber to a mission receives new mission packages automatically: the change feed notifies the client, the client pulls the content, and it appears on the map without operator action. For a unit running a shared mission, this is the path that keeps everyone current without anyone manually sending files. Federated servers extend this further — see TAK Server federation for how missions and their content propagate across a federation boundary.

7. versioning and integrity

The hash that backs Enterprise Sync is also the integrity guarantee: a package's content is identified by its hash, so a corrupted or tampered file simply will not match the reference and will not be accepted. On the client, the package uid is the versioning handle. Re-import a package with the same uid and the client replaces the prior import rather than stacking a duplicate — this is how you push an updated overlay without leaving the old one behind.

That replacement behavior is only reliable if you use it deliberately. The classic field failure is stale-overlay sprawl: every revision of a plan shipped as a fresh uid, so the device accumulates twelve slightly different boundary overlays and the operator cannot tell which is current. The disciplines that prevent it are simple — keep a stable uid per logical artifact across revisions, set onReceiveDelete="true" so removing a package cleans up its content, and treat the manifest's uid namespace as a managed asset, not a random UUID per export.

8. building packages programmatically

Generating packages by hand in the client is fine for one operator; it does not scale to a pipeline that has to push planning products to a hundred devices on a schedule. The good news is that the format is trivially automatable. Building a package programmatically is three steps: assemble the payload files, write a MANIFEST.xml with the correct version, a stable uid, and one <Content> entry per payload, then zip them together with the manifest at the path the client expects (conventionally under a MANIFEST/ directory).

For server-side automation, the mission and Enterprise Sync APIs let a pipeline upload content by hash, create or update a mission, and attach content to it — all without a human in the loop. A planning system can generate an overlay, package it, upload it to a mission, and have every subscribed device update within seconds. The pattern that works is to treat package generation as a build step: deterministic manifests, stable UIDs keyed to the logical product, and content-addressed upload so re-runs that produce identical bytes are no-ops on the wire.

The architectural lesson mirrors what we say about every TAK integration: keep the package generator out of your core domain model. Your planning system should own plans; a thin adapter should translate a plan into a manifest and a zip. When the manifest schema rev changes or a new content type is added, you update the adapter, not the planner — and the rest of the distribution chain, from Enterprise Sync to the device, never needs to know.