Building an ATAK plugin: SDK versions, signing and compatibility

What an ATAK plugin is

An ATAK plugin is a separate Android app that loads inside ATAK and adds new capability to it. It can add toolbar buttons, side panes, map layers, new message types and connections to outside devices and systems, all without changing ATAK itself. If you are new to the TAK ecosystem, start with our guide What is ATAK?.

On the surface a plugin looks like any other Android project. The difference is that it does not stand on its own: it runs inside someone else's app. That means ATAK decides which plugins it will load, and it is strict about three things.

1. Which ATAK it was built for: CIV or MIL.
2. Who signed it: a developer key for testing, or an approved signature for the field.
3. Which ATAK release it was built against: 4.x, 5.0, 5.8 and so on.

Building the plugin itself takes real work with the ATAK SDK. With that work done well, these three are what carry a plugin from a working build to devices in the field, and planning for them early keeps a plugin on schedule.

CIV and MIL: two separate worlds

At its core, ATAK exists in two lines. ATAK-CIV is the civilian build that anyone can download. ATAK-MIL includes military-controlled capability and is only distributed to authorized users. They look alike on screen, but to a plugin they are different platforms.

Each line has its own developer kit, published through tak.gov. The Standard SDK targets CIV. The Military SDK targets MIL and is only available to developers who are authorized to work with military-controlled software.

Knowing which side your users are on is the first question to settle in any plugin project. It decides which SDK your developers need, who is allowed to work on the code, and how the plugin gets signed and delivered.

Developer builds and release builds

Each SDK comes with a developer build of ATAK. It is a special version of the app, marked with a “Development Build” watermark across the map, that loads plugins signed with a developer's own key. That is where a plugin is built, debugged and demonstrated.

So in practice there are four places a plugin can run: CIV dev, CIV release, MIL dev and MIL release.

Signing: how a plugin gets onto real devices

Every Android app is signed, but ATAK adds its own layer on top. Release builds of ATAK only load plugins whose signature they trust, which keeps unknown code off devices that carry sensitive information. Getting that signature is a separate step from building the plugin.

• The TAK Product Center signs plugins through its build pipeline. Submitted code goes through a review before it is signed.
• A third-party signing service is also available. Plugins signed that way show a visual indicator so users can tell how the plugin was signed.
• MIL devices need a MIL signature. A plugin headed for fielded military devices has to be signed for MIL ATAK specifically. A CIV signature does not carry over.

A plugin is not finished when the code works. It is finished when it is signed for the ATAK your users actually carry.

For a program team, the practical effect is on the schedule. Signing involves submission and review by someone outside your team, so it needs a place in the timeline, and it has to happen again for every new version of the plugin.

Versions: why every ATAK release matters

A plugin is built against one specific ATAK release and only loads into that release. When users move to a newer ATAK, the plugin has to be rebuilt against the new SDK, retested, re-signed and redistributed. A plugin that is not updated simply stops being available to anyone who upgrades.

The jump from ATAK 4 to ATAK 5

Major versions are where this matters most. The move from ATAK 4.x to 5.0 brought wide-ranging changes to ATAK and to the SDK that plugins are built on. Plugins written for 4.x generally needed real rework to run on 5, not just a rebuild, and teams that had put off upgrades found themselves with several releases of changes to absorb at once.

From 5.0 to 5.8 and beyond

ATAK did not stand still after 5.0. Each release from 5.0 through today's 5.8 has added capability and changed parts of the platform, and a plugin has to keep pace with each step. The underlying Android versions on devices keep moving too, which brings its own requirements.

Supporting more than one version

Organizations rarely move every device at once. During a transition, some users may be on one release and some on the next, and CIV and MIL users may be on different releases altogether. Each combination you support is another build to sign and test, so decide early which versions you will support and for how long.

What this means for your plugin project

None of this is a reason not to build a plugin. It is a reason to plan for the whole life of one. Before a project starts, get answers to these questions:

1. Who are the users? CIV, MIL or both. This decides the SDK, the signing route and how many builds you need.
2. Which ATAK release are they on now, and which will they be on when the plugin ships?
3. Who is authorized to do the work? MIL development needs developers with access to the Military SDK.
4. How will it be signed and delivered? Who submits it, how long that is expected to take, and how it reaches devices.
5. Who keeps it current? Every future ATAK release your users adopt means another update, test and signing cycle.
6. Who owns the code? Make sure you can keep the plugin alive even if the original developer moves on.

A development partner who works in TAK every day will already know the answers for your situation. That is the work we do on our ATAK plugin development team, from first build through signing and every release after.