Plugin Specification

Plugin Specification

The plugin.xml file is an XML document in the plugins namespace: http://apache.org/cordova/ns/plugins/1.0. It contains a top-level plugin element that defines the plugin, and children that define the structure of the plugin.

A sample plugin element:

<?xml version="1.0" encoding="UTF-8"?>
<plugin xmlns="http://apache.org/cordova/ns/plugins/1.0"
    xmlns:android="http://schemas.android.com/apk/res/android"
    id="com.alunny.foo"
    version="1.0.2">

plugin Element

The plugin element is the plugin manifest's top-level element. It features the following attributes:

engines and engine Elements

The child elements of the <engines> element specify versions of Apache Cordova-based frameworks that this plugin supports. An example:

<engines>
    <engine name="cordova" version="1.7.0" />
    <engine name="cordova" version="1.8.1" />
    <engine name="worklight" version="1.0.0" platform="android" scriptSrc="worklight_version"/>
</engines>

Similar to the <plugin> element's version attribute, the specified version string should match a major-minor-patch string conforming to the regular expression:

    ^\d+[.]\d+[.]\d+$

Engine elements may also specify fuzzy matches to avoid repetition, and to reduce maintenance when the underlying platform is updated. Tools should support a minimum of >, >=, < and <=, for example:

<engines>
    <engine name="cordova" version=">=1.7.0" />
    <engine name="cordova" version="<1.8.1" />
</engines>

The <engine> tags also has default support for all of the main platforms Cordova exists on. Specifying the cordova engine tag means that all versions of Cordova on any platform must satisfy the engine version attribute. You may also list specific platforms and their versions in order to override the catch-all cordova engine:

<engines>
    <engine name="cordova" version=">=1.7.0" />
    <engine name="cordova-android" version=">=1.8.0" />
    <engine name="cordova-ios" version=">=1.7.1" />
</engines>

Here's a list of the default engines that the '' tag supports: * 'cordova' * 'cordova-plugman' * 'cordova-amazon-fireos' * 'cordova-android' * 'cordova-ios' * 'cordova-blackberry10' * 'cordova-wp8' * 'cordova-windows8'
* 'android-sdk' // returns the highest Android api level installed * 'apple-xcode' // returns the xcode version * 'apple-ios' // returns the highest iOS version installed * 'apple-osx' // returns the OSX version * 'blackberry-ndk' // returns the native blackberry SDK version

Specifying custom Apache Cordova-based frameworks should be listed under the engine tag like so:

<engines>
    <engine name="my_custom_framework" version="1.0.0" platform="android" scriptSrc="path_to_my_custom_framework_version"/>
    <engine name="another_framework" version=">0.2.0" platform="ios|android" scriptSrc="path_to_another_framework_version"/>
    <engine name="even_more_framework" version=">=2.2.0" platform="*" scriptSrc="path_to_even_more_framework_version"/>
</engines>

A custom Apache Cordova-based framework requires that an engine element includes the following attributes: name, version, scriptSrc, and platform.

plugman aborts with a non-zero code for any plugin whose target project does not meet the engine's constraints.

If no <engine> tags are specified, plugman attempts to install into the specified cordova project directory blindly.

name Element

A human-readable name for the plugin, whose text content contains the name of the plugin. For example:

<name>Foo</name>

This element does not (yet) handle localization.

description Element

A human-readable description for the plugin. The text content of the element contains the description of the plugin. An example:

<description>Foo plugin description</description>

This element does not (yet) handle localization.

author Element

Plugin author name. The text content of the element contains the name of the plugin author. An example:

<author>Foo plugin description</author>

keywords Element

Plugin keywords. The text content of the element contains comma separated keywords to describe the plugin. An example:

<keywords>foo,bar</keywords>

license Element

Plugin license. The text content of the element contains the plugin license. An example:

<license>Apache 2.0 License</license>

asset Element

One or more elements listing the files or directories to be copied into a Cordova app's www directory. Examples:

<!-- a single file, to be copied in the root directory -->
<asset src="www/foo.js" target="foo.js" />
<!-- a directory, also to be copied in the root directory -->
<asset src="www/foo" target="foo" />

All <asset> tags require both src and target attributes. Web-only plugins contains mostly <asset> elements. Any <asset> elements that are nested within <platform> elements specify platform-specific web assets, as described below. Attributes include:

js-module Element

Most plugins include one or more JavaScript files. Each <js-module> tag corresponds to a JavaScript file, and prevents the plugin's users from having to add a <script> tag for each file. While <asset> tags simply copy a file from the plugin subdirectory into www, <js-module> tags are much more sophisticated. They look like this:

<js-module src="socket.js" name="Socket">
    <clobbers target="chrome.socket" />
</js-module>

When installing a plugin with the example above, socket.js is copied to www/plugins/my.plugin.id/socket.js, and added as an entry to www/cordova_plugins.js. At load time, code in cordova.js uses XHR to read each file and inject a <script> tag into HTML. It adds a mapping to clobber or merge as appropriate, as described below.

Do not wrap the file with cordova.define, as it is added automatically. The module is wrapped in a closure, with module, exports, and require in scope, as is normal for AMD modules.

Details for the <js-module> tag:

If src does not resolve to an existing file, plugman stops and reverses the installation, issues a notification of the problem, and exits with a non-zero code.

Nesting <js-module> elements within <platform> declares platform-specific JavaScript module bindings.

dependency Element

The <dependency> tag allows you to specify other plugins on which the current plugin depends. While future versions will access them from plugin repositories, in the short term plugins are directly referenced as URLs by <dependency> tags. They are formatted as follows:

<dependency id="com.plugin.id" url="https://github.com/myuser/someplugin" commit="428931ada3891801" subdir="some/path/here" />

In the future, version constraints will be introduced, and a plugin repository will exist to support fetching by name instead of explicit URLs.

Relative Dependency Paths

If you set the url of a <dependency> tag to "." and provide a subdir, the dependent plugin is installed from the same local or remote git repository as the parent plugin that specifies the <dependency> tag.

Note that the subdir always specifies a path relative to the root of the git repository, not the parent plugin. This is true even if you installed the plugin with a local path directly to it. Plugman finds the root of the git repository and then finds the other plugin from there.

platform Element

The <platform> tag identifies platforms that have associated native code or require modifications to their configuration files. Tools using this specification can identify supported platforms and install the code into Cordova projects.

Plugins without <platform> tags are assumed to be JavaScript-only, and therefore installable on any and all platforms.

A sample platform tag:

<platform name="android">
    <!-- android-specific elements -->
</platform>
<platform name="ios">
    <!-- ios-specific elements -->
</platform>

The required name attribute identifies a platform as supported, associating the element's children with that platform.

Platform names should be lowercase. Platform names, as arbitrarily chosen, are listed:

source-file Element

The <source-file> element identifies executable source code that should be installed into a project. Examples:

<!-- android -->
<source-file src="src/android/Foo.java"
                target-dir="src/com/alunny/foo" />
<!-- ios -->
<source-file src="src/ios/CDVFoo.m" />
<source-file src="src/ios/someLib.a" framework="true" />
<source-file src="src/ios/someLib.a" compiler-flags="-fno-objc-arc" />

It supports the following attributes:

config-file Element

Identifies an XML-based configuration file to be modified, where in that document the modification should take place, and what should be modified.

Two file types that have been tested for modification with this element are xml and plist files.

The config-file element only allows you to append new children to an XML document tree. The children are XML literals to be inserted in the target document.

Example for XML:

<config-file target="AndroidManifest.xml" parent="/manifest/application">
    <activity android:name="com.foo.Foo" android:label="@string/app_name">
        <intent-filter>
        </intent-filter>
    </activity>
</config-file>

Example for plist:

<config-file target="*-Info.plist" parent="CFBundleURLTypes">
    <array>
        <dict>
            <key>PackageName</key>
            <string>$PACKAGE_NAME</string>
        </dict>
    </array>
</config-file>

It supports the following attributes:

plugins-plist Element

This is outdated as it only applies to cordova-ios 2.2.0 and below. Use the <config-file> tag for newer versions of Cordova.

Example:

<config-file target="config.xml" parent="/widget/plugins">
    <feature name="ChildBrowser">
        <param name="ios-package" value="ChildBrowserCommand"/>
    </feature>
</config-file>

Specifies a key and value to append to the correct AppInfo.plist file in an iOS Cordova project. For example:

<plugins-plist key="Foo" string="CDVFoo" />

resource-file and header-file Elements

Like source files, but specifically for platforms such as iOS that distinguish between source files, headers, and resources. iOS Examples:

<resource-file src="CDVFoo.bundle" />
<resource-file src="CDVFooViewController.xib" />
<header-file src="CDVFoo.h" />

Android example:

<resource-file src="FooPluginStrings.xml" target="res/values/FooPluginStrings.xml" />

lib-file Element

Like source, resource, and header files, but specifically for platforms such as BlackBerry 10 that use user-generated libraries. Examples:

<lib-file src="src/BlackBerry10/native/device/libfoo.so" arch="device" />
<lib-file src="src/BlackBerry10/native/simulator/libfoo.so" arch="simulator" />

Supported attributes:

framework Element

Identifies a framework (usually part of the OS/platform) on which the plugin depends.

Examples:

<framework src="libsqlite3.dylib" />
<framework src="social.framework" weak="true" />
<framework src="relative/path/to/my.framework" custom="true" />
<framework src="path/to/project/LibProj.csproj" custom="true" type="projectReference"/>

The src attribute identifies the framework, which plugman attempts to add to the Cordova project, in the correct fashion for a given platform.

The optional weak attribute is a boolean indicating whether the framework should be weakly linked. The default is false.

The optional custom attribute is a boolean indicating whether the framework is one that is included as part of your plugin files (thus it is not a system framework). The default is false. On Android it specifies how to treat src. If true src is a relative path from the application project's directory, otherwise -- from the Android SDK directory.

The optional type attribute is a string indicating the type of framework to add. Currently only projectReference is supported and only on Windows 8. Using custom='true' and type='projectReference' will add a reference to the project which will be added to the compile+link steps of the cordova project. This essentially is the only way currently that a 'custom' framework can target multiple architectures as they are explicitly built as a dependency by the referencing cordova application.

The optional parent attribute is currently supported only on Android. It sets the relative path to the directory containing the sub-project to which to add the reference. The default is ., i.e. the application project. It allows to add references between sub projects like in this example:

<framework src="FeedbackLib" custom="true" />
<framework src="extras/android/support/v7/appcompat" custom="false" parent="FeedbackLib" />

info Element

info Element

Additional information provided to users. This is useful when you require extra steps that can't be easily automated or are beyond plugman's scope. Examples:

<info>
You need to install __Google Play Services__ from the `Android Extras` section using the Android SDK manager (run `android`).

You need to add the following line to the `local.properties`:

android.library.reference.1=PATH_TO_ANDROID_SDK/sdk/extras/google/google_play_services/libproject/google-play-services_lib
</info>

Variables

In certain cases, a plugin may need to make configuration changes dependent on the target application. For example, to register for C2DM on Android, an app whose package id is com.alunny.message would require a permission such as:

<uses-permission
android:name="com.alunny.message.permission.C2D_MESSAGE"/>

In such cases where the content inserted from the plugin.xml file is not known ahead of time, variables can be indicated by a dollar-sign followed by a series of capital letters, digits, or underscores. For the above example, the plugin.xml file would include this tag:

<uses-permission
android:name="$PACKAGE_NAME.permission.C2D_MESSAGE"/>

plugman replaces variable references with the specified value, or the empty string if not found. The value of the variable reference may be detected (in this case, from the AndroidManifest.xml file) or specified by the user of the tool; the exact process is dependent on the particular tool.

plugman can request users to specify a plugin's required variables. For example, API keys for C2M and Google Maps can be specified as a command-line argument:

plugman --platform android --project /path/to/project --plugin name|git-url|path --variable API_KEY=!@CFATGWE%^WGSFDGSDFW$%^#$%YTHGsdfhsfhyer56734

To make the variable mandatory, the <platform> tag needs to contain a <preference> tag. For example:

<preference name="API_KEY" />

plugman checks that these required preferences are passed in. If not, it should warn the user how to pass the variable in and exit with a non-zero code.

Certain variable names should be reserved, as listed below.

$PACKAGE_NAME

The reverse-domain style unique identifier for the package, corresponding to the CFBundleIdentifier on iOS or the package attribute of the top-level manifest element in an AndroidManifest.xml file.