Plugin.xml

Файл Plugin.xml определяет структуру и настройки, необходимые для вашего плагина. Он содержит несколько элементов для предоставления подробной информации о вашем плагине.

plugin

Элемент plugin является корневым элементом манифеста плагина.

Пример:

<?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="my-plugin-id"
    version="1.0.2">

engines и engine

Дочерние элементы элемента <engines> указывают версии фреймворков Apache Cordova, которые поддерживает этот плагин. CLI прерывает установку с ненулевым кодом для любого плагина, целевой проект которого не соответствует ограничениям движка. Если теги не указаны, CLI пытается установить плагин в указанный каталог проекта Cordova без проверки.

ПРИМЕЧАНИЕ: В Cordova 6.1.0+ рекомендуется указывать зависимости платформы, плагина и CLI в файле package.json. См. указание зависимостей Cordova для получения дополнительной информации.

Примеры:

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

Элементы движка также могут указывать приблизительные соответствия, используя '>', '>=' и т.д., чтобы избежать повторений и уменьшить поддержку при обновлении базовой платформы.

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

Теги <engine> также поддерживают все основные платформы, на которых существует Cordova. Указание тега cordova engine означает, что все версии Cordova на любой платформе должны соответствовать атрибуту версии движка. Вы также можете перечислить определенные платформы и их версии, чтобы переопределить универсальный тег 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>

Пример пользовательских фреймворков:

<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>

name

Элемент name используется для указания имени плагина. Этот элемент (пока) не поддерживает локализации.

Пример:

<name>Foo</name>

description

Элемент description используется для указания описания плагина. Этот элемент (пока) не поддерживает локализации.

Пример:

<description>Foo plugin description</description>

author

Содержимое элемента author содержит имя автора плагина.

Пример:

<author>Foo plugin author</author>

keywords

Содержимое элемента keywords содержит разделенные запятыми ключевые слова для описания плагина.

Пример:

<keywords>foo,bar</keywords>

license

Этот элемент используется для указания лицензии плагина.

Пример:

<license>Apache 2.0 License</license>

asset

Этот элемент используется для перечисления файлов или каталогов, которые необходимо скопировать в каталог www приложения Cordova. Любые элементы <asset> , вложенные в элементы <platform> , указывают платформозависимые веб-активы.

Примеры:

<!-- 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" />

Активы могут быть направлены в подкаталоги. Это создаст каталог js/experimental в каталоге www, если он не существует, и скопирует файл new-foo.js, переименовав его в foo.js.

<asset src="www/new-foo.js" target="js/experimental/foo.js" />

js-module

Большинство плагинов содержат один или несколько JavaScript-файлов. Каждый тег <js-module> соответствует JavaScript-файлу и избавляет пользователей от необходимости добавлять тег <script> для каждого файла. Не заключайте файл в cordova.define, так как он добавляется автоматически. Модуль обернут в закрытие с модулем, экспортом и require в области видимости, как это обычно бывает для AMD-модулей. Вложение элементов <js-module> внутри <platform> объявляет платформозависимые привязки JavaScript-модулей.

Пример:

При установке плагина с примером ниже, socket.js копируется в www/plugins/my-plugin-id/socket.js, и добавляется как запись в www/cordova_plugins.js. Во время загрузки код в cordova.js использует XHR для чтения каждого файла и вставляет тег <script> в HTML.

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

Также для этого примера, с идентификатором плагина chrome-socket, имя модуля будет chrome-socket.Socket.

clobbers

Разрешено внутри элемента <js-module>. Используется для указания пространства имен в объекте window, куда вставляется module.exports. Вы можете иметь любое количество тегов <clobbers>. Любой объект, отсутствующий в window , создаётся.

Пример:

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

Здесь module.exports вставляется в объект window как window.chrome.socket.

merges

Разрешено внутри элемента <js-module>. Используется для указания пространства имен в объекте window, куда module.exports объединяется с любым существующим значением. Если какой-либо ключ уже существует, версия модуля переопределяет исходное значение. Вы можете иметь любое количество тегов <merges> . Любой объект, отсутствующий в window , создаётся.

Пример:

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

Здесь module.exports объединяется с любым существующим значением в window.chrome.socket.

runs

Разрешено внутри элемента <js-module>. Это подразумевает, что ваш код должен быть указан с cordova.require, но не установлен в объект window. Это полезно при инициализации модуля, привязывании обработчиков событий или других операциях. Вы можете иметь не более одного тега <runs/>. Обратите внимание, что включение тега <runs/> с тегами <clobbers/> или <merges/> избыточно, так как они также cordova.require ваш модуль.

Пример:

<js-module src="socket.js" name="Socket">
  <runs/>
</js-module>

dependency

Тег <dependency> позволяет указывать другие плагины, от которых зависит текущий плагин. Плагины ссылаются на них по уникальным идентификаторам npm или URL github.

Примеры:

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

платформа

Определяет платформы, которые имеют ассоциированный код нативном языке или требуют модификаций файлов конфигурации. Инструменты, использующие данную спецификацию, могут определить поддерживаемые платформы и установить код в проекты Cordova. Плагины без тегов <platform> предполагаются только JavaScript и, следовательно, установленные на всех платформах.

Пример:

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

файл-источник

Определяет исполняемый исходный код, который должен быть установлен в проект.

Примеры:

<!-- 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" />

файл-заголовок

Это как элемент <source-file>, но специально для платформ, таких как iOS и Android, которые различают исходные файлы, заголовки и ресурсы. Это не поддерживается Windows.

Пример:

Для iOS:

<header-file src="CDVFoo.h" />
<header-file src="CDVSomeHeader.h" type="BridgingHeader" />

файл-ресурс

Это как элемент <source-file>, но специально для платформ, таких как iOS и Android, которые различают исходные файлы, заголовки и ресурсы.

Примеры:

Для Android:

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

Для Windows:

<resource-file src="src/windows/win81/MobServices.pri" target="win81\MobServices.pri" device-target="windows" versions="8.1" arch="x64"/>

<!-- Example of referencing  -->
<resource-file src="x86/foo.dll" target="foo.dll" arch="x86" reference="true" />
<resource-file src="x64/foo.dll" target="foo.dll" arch="x64" reference="true" />

ПРИМЕЧАНИЕ: target должен использовать обратные слэши, чтобы избежать ошибки развертывания DEP2100 в Visual Studio.

файл-конфигурации

Определяет файл конфигурации на основе XML, который должен быть изменён, в какой части документа должно произойти изменение и что должно быть изменено. Два типа файлов, которые были протестированы для изменения с помощью этого элемента, это xml и plist файлы. Элемент config-file позволяет только добавлять новые дочерние элементы в дерево документа XML. Дочерние элементы являются литералами XML, которые должны быть вставлены в целевой документ.

Примеры:

Для 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>

Для plist:

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

Для атрибутов, специфичных для Windows:

<config-file target="package.appxmanifest" parent="/Package/Capabilities" versions="&lt;8.1.0">
    <Capability Name="picturesLibrary" />
    <DeviceCapability Name="webcam" />
</config-file>
<config-file target="package.appxmanifest" parent="/Package/Capabilities" versions=">=8.1.0" device-target="phone">
    <DeviceCapability Name="webcam" />
</config-file>

В приведенном выше примере будут установлены платформы до версии 8.1 (Windows 8, конкретно) для требования функции устройства webcam и общей функции picturesLibrary, а функция устройства webcam будет применена только к проектам Windows 8.1, которые собираются для Windows Phone. Windows настольные системы 8.1 не изменены.

edit-config

Подобно config-file, edit-config определяет файл XML-конфигурации для изменения, указывая, где в этом документе должно произойти изменение и что должно быть изменено. Вместо добавления новых дочерних элементов в дерево документа XML, edit-config вносит изменения в атрибуты элементов XML. Существует два режима, определяющие тип изменения атрибута: merge или overwrite. edit-config имеет один дочерний элемент, и этот дочерний элемент будет содержать добавляемые атрибуты.

Пример:

<!-- plugin-1 -->
<edit-config file="AndroidManifest.xml" target="/manifest/uses-sdk" mode="merge">
    <uses-sdk android:minSdkVersion="16" android:maxSdkVersion="23" />
</edit-config>
<edit-config file="AndroidManifest.xml" target="/manifest/application/activity[@android:name='MainActivity']" mode="overwrite">
    <activity android:name="MainActivity" android:label="NewLabel" android:configChanges="orientation|keyboardHidden" />
</edit-config>

AndroidManifest.xml до добавления плагина plugin-1:

<manifest android:hardwareAccelerated="true" android:versionCode="1" android:versionName="0.0.1" package="io.cordova.hellocordova" xmlns:android="http://schemas.android.com/apk/res/android">
    ...
        <activity android:configChanges="orientation|keyboardHidden|keyboard|screenSize|locale" android:label="@string/activity_name" android:launchMode="singleTop" android:name="MainActivity" android:theme="@android:style/Theme.DeviceDefault.NoActionBar" android:windowSoftInputMode="adjustResize">
            ...
        </activity>
    ...
    <uses-sdk android:minSdkVersion="14" android:targetSdkVersion="23" />
</manifest>

AndroidManifest.xml после добавления плагина plugin-1:

<manifest android:hardwareAccelerated="true" android:versionCode="1" android:versionName="0.0.1" package="io.cordova.hellocordova" xmlns:android="http://schemas.android.com/apk/res/android">
    ...
        <activity android:configChanges="orientation|keyboardHidden" android:label="NewLabel" android:name="MainActivity">
            ...
        </activity>
    ...
    <uses-sdk android:maxSdkVersion="23" android:minSdkVersion="16" android:targetSdkVersion="23" />
</manifest>

Управление конфликтами edit-config

Несколько плагинов не могут изменять одни и те же атрибуты, так как это может вызвать проблемы с приложением. Будет выброшено исключение, и установка плагина завершится ошибкой. Конфликтующие edit-config теги необходимо разрешить перед добавлением плагина. Внесите изменения в конфликтующие теги, чтобы разрешить конфликт, затем удалите и повторно добавьте обновленные плагины.

Существует возможность для тех, кто уверен, что плагин необходимо установить, несмотря на конфликты. Флаг --force может использоваться с cordova plugin add. Принудительное добавление плагина вернёт конфликтующие изменения других плагинов, чтобы его можно было добавить без проблем. --force следует использовать с осторожностью, так как откат изменений других плагинов может привести к тому, что приложение не будет работать должным образом.

Если плагины окажутся в странном состоянии, удалите все плагины и добавьте их заново.

Пример:

Предположим, что плагин plugin-1 из примера уже установлен. Попытка установить плагин plugin-2 ниже вызовет ошибку, потому что plugin-1 уже изменил uses-sdk элемент в AndroidManifest.xml.

<!-- plugin-2 -->
<edit-config file="AndroidManifest.xml" target="/manifest/uses-sdk" mode="merge">
    <uses-sdk android:minSdkVersion="15" />
</edit-config>

Существует несколько способов добавления plugin-2:

Одним из возможных способов разрешения конфликта является удаление edit-config тега из plugin-2 и объединение его с тегом edit-config плагина plugin-1 (предполагая, что plugin-1 не имеет проблем с этим изменением). Удалите оба плагина и повторно добавьте их с этими изменениями. В этот раз плагин plugin-2 должен быть добавлен без проблем.

Удаление edit-config из plugin-2 и объединение его с plugin-1:

<!-- plugin-1 -->
<edit-config file="AndroidManifest.xml" target="/manifest/uses-sdk" mode="merge">
    <uses-sdk android:minSdkVersion="15" android:maxSdkVersion="23" />
</edit-config>
<edit-config file="AndroidManifest.xml" target="/manifest/application/activity[@android:name='MainActivity']" mode="overwrite">
    <activity android:name="MainActivity" android:label="NewLabel" android:configChanges="orientation|keyboardHidden" />
</edit-config>

Результат AndroidManifest.xml после удаления и повторного добавления обоих плагинов:

<manifest android:hardwareAccelerated="true" android:versionCode="1" android:versionName="0.0.1" package="io.cordova.hellocordova" xmlns:android="http://schemas.android.com/apk/res/android">
    ...
        <activity android:configChanges="orientation|keyboardHidden" android:label="NewLabel" android:name="MainActivity">
            ...
        </activity>
    ...
    <uses-sdk android:maxSdkVersion="23" android:minSdkVersion="15" android:targetSdkVersion="23" />
</manifest>

Второй способ добавления plugin-2 заключается в добавлении плагина с использованием --force. Конфликтное изменение edit-config плагина plugin-1 будет отменено, и будет применено изменение плагина plugin-2. Результирующий AndroidManifest.xml будет содержать изменение uses-sdk из плагина plugin-2 и изменение activity из плагина plugin-1. Обратите внимание, что только изменение uses-sdk из плагина plugin-1 исчезло, так как это было единственное конфликтующее изменение.

Результат AndroidManifest.xml после принудительного добавления plugin-2:

<manifest android:hardwareAccelerated="true" android:versionCode="1" android:versionName="0.0.1" package="io.cordova.hellocordova" xmlns:android="http://schemas.android.com/apk/res/android">
    ...
        <activity android:configChanges="orientation|keyboardHidden" android:label="NewLabel" android:name="MainActivity">
            ...
        </activity>
    ...
    <uses-sdk android:minSdkVersion="15" android:targetSdkVersion="23" />
</manifest>

Примечание: Отменённые изменения из --force окончательно удалены. Они не появятся после удаления плагина, который был добавлен принудительно. Если отменённые изменения необходимы, все связанные плагины должны быть удалены и повторно добавлены.

plugins-plist

Указывает ключ и значение, которые нужно добавить к соответствующему AppInfo.plist файлу в проекте Cordova для iOS. Этот параметр устарел, так как применяется только к cordova-ios 2.2.0 и ниже. Для более новых версий Cordova используйте тег <config-file>.

Пример:

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

lib-file

Как файлы исходного кода, ресурсов и заголовков, но специально для таких платформ, как BlackBerry 10, которые используют библиотеки, созданные пользователем. Для платформы Windows элемент <lib-file> позволяет включить <SDKReference> в сгенерированные файлы проекта Windows.

Для Android элемент <lib-file> используется для установки файлов .jar в libs-каталоге проекта. Он поддерживает только атрибут src, который содержит относительный путь к файлу .jar.

Примеры:

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

Для Windows:

<lib-file src="Microsoft.WinJS.2.0, Version=1.0" arch="x86" />
<lib-file src="Microsoft.WinJS.2.0, Version=1.0" versions=">=8.1" />
<lib-file src="Microsoft.WinJS.2.0, Version=1.0" target="phone" />
<lib-file src="Microsoft.WinJS.2.0, Version=1.0" target="win" versions="8.0" arch="x86" />

framework

Идентифицирует фреймворк (обычно часть ОС/платформы), от которого зависит плагин.

Примеры:

Для iOS:

<framework src="libsqlite3.dylib" />
<framework src="social.framework" weak="true" />
<framework src="relative/path/to/my.framework" custom="true" />
<framework src="GoogleCloudMessaging" type="podspec" spec="~> 1.2.0" />

В Android (по состоянию на cordova-android@4.0.0), теги framework используются для включения зависимостей Maven или для включения связанных проектов библиотек.

<!-- Depend on latest version of GCM from play services -->
<framework src="com.google.android.gms:play-services-gcm:+" />
<!-- Depend on v21 of appcompat-v7 support library -->
<framework src="com.android.support:appcompat-v7:21+" />
<!-- Depend on library project included in plugin -->
<framework src="relative/path/FeedbackLib" custom="true" />

Framework также можно использовать для включения пользовательских .gradle файлов в основной файл проекта build.gradle.

<framework src="relative/path/rules.gradle" custom="true" type="gradleReference" />

В Windows, использование custom='true' и type='projectReference' добавит ссылку на проект, которая будет добавлена к шагам компиляции и компоновки проекта Cordova. По существу, это единственный способ в настоящее время, чтобы пользовательский фреймворк мог работать с несколькими архитектурами, так как они явно строятся как зависимость ссылающимся приложением Cordova.

<framework src="path/to/project/LibProj.csproj" custom="true" type="projectReference"/>

Примеры использования этих специфичных для Windows атрибутов:

<framework src="src/windows/example.dll" arch="x64" />
<framework src="src/windows/example.dll" versions=">=8.0" />
<framework src="src/windows/example.vcxproj" type="projectReference" target="win" />
<framework src="src/windows/example.vcxproj" type="projectReference" target="all" versions="8.1" arch="x86" />
<framework src="src/windows/example.dll" target-dir="bin/x64" arch="x64" custom="true"/>

Еще один пример использования специфичных для Windows атрибутов для добавления ссылки на компоненты WinMD, написанные на C# и C++, чьи API будут доступны во время выполнения:

<!-- C# component that consists of one .winmd file -->
<framework src="lib\windows\component.winmd" versions="<10.0" />
<!-- C++ component with separated metadata and implementation-->
<framework src="lib\windows\x86\cppcomponent.winmd"
           implementation="lib\windows\x86\cppcomponent.dll"
           target-dir="component\x86" arch="x86" versions=">=10.0" />

podspec (iOS)

Идентифицирует CocoaPods Podfile, предоставляющий зависимости, от которых зависит плагин.

Этот элемент содержит теги <config> и <pods>.

config

Элемент <config> определяет URL-адреса источников, из которых извлекаются спецификации CocoaPods.

Этот элемент содержит один или несколько тегов <source>.

source

pods

Элемент <pods> определяет библиотеки CocoaPods.

Этот элемент содержит тег <pod> для каждой библиотеки CocoaPods.

pod

Примеры:

<podspec>
  <config>
    <source url="https://github.com/brightcove/BrightcoveSpecs.git" />
    <source url="https://github.com/CocoaPods/Specs.git"/>
  </config>
  <pods use-frameworks="true">
    <pod name="AFNetworking" spec="~> 3.2" />
    <pod name="SDWebImage" spec="~> 4.0" />
    <pod name="Eureka" swift-version="3.3" />
    <pod name="AcknowList" />
    <pod name="Brightcove-Player-Core" spec="~> 6.3.4" />
    <pod name="Foobar1" git="git@github.com:hoge/foobar1.git" configurations="Debug"/>
    <pod name="Foobar2" git="git@github.com:hoge/foobar2.git" branch="next" configurations="Debug,Release"/>
    <pod name="FoobarSwift" swift-version="4.1" />
  </pods>
</podspec>

Этот пример приводит к Podfile

# DO NOT MODIFY -- auto-generated by Apache Cordova
source 'https://github.com/brightcove/BrightcoveSpecs.git'
source 'https://github.com/CocoaPods/Specs.git'
platform :ios, '9.0'
use_frameworks!
target 'HelloCordova' do
    project 'HelloCordova.xcodeproj'
    pod 'AFNetworking', '~> 3.2'
    pod 'SDWebImage', '~> 4.0'
    pod 'Eureka'
    pod 'AcknowList'
    pod 'Brightcove-Player-Core', '~> 6.3.4'
    pod 'Foobar1', :git => 'git@github.com:hoge/foobar1.git', :configurations => ['Debug']
    pod 'Foobar2', :branch => 'next', :git => 'git@github.com:hoge/foobar2.git', :configurations => ['Debug','Release']
    pod 'FoobarSwift'
end

info

Дополнительная информация для пользователей. Это полезно, когда вам нужны дополнительные шаги, которые нельзя легко автоматизировать или которые выходят за рамки возможностей командной строки. Содержимое этого тега выводится при установке плагина с помощью командной строки.

Пример:

<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>

hook

Представляет ваш пользовательский скрипт, который будет вызываться Cordova при возникновении определённого действия (например, после добавления плагина или вызова логики подготовки платформы). Это полезно, когда необходимо расширить стандартную функциональность Cordova. См. Руководство по хукам для получения дополнительной информации.

Пример:

<hook type="after_plugin_install" src="scripts/afterPluginInstall.js" />

uses-permission

В некоторых случаях плагину может потребоваться внести изменения в конфигурацию целевого приложения. Например, для регистрации C2DM на Android, приложение с идентификатором пакета my-app-id потребует разрешения, например:

<uses-permission android:name="my-app-id.permission.C2D_MESSAGE"/>

В таких случаях, когда содержимое, вставленное из файла plugin.xml неизвестно заранее, переменные могут быть указаны символом доллара, за которым следуют несколько заглавных букв, цифр или символов подчеркивания. Для приведенного выше примера, файл plugin.xml будет содержать этот тег:

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

Командная строка заменяет ссылки на переменные указанным значением или пустой строкой, если значение не найдено. Значение ссылки на переменную может быть обнаружено (в данном случае, из файла AndroidManifest.xml ) или указано пользователем инструмента; точный процесс зависит от конкретного инструмента.

Plugman может запросить у пользователя указание необходимых переменных плагина. Например, ключи API для C2M и Google Maps можно указать в качестве аргумента командной строки:

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

Некоторые имена переменных должны быть зарезервированы, например, $PACKAGE_NAME. Это уникальный идентификатор доменного имени обратного порядка для пакета, соответствующий CFBundleIdentifier на iOS или атрибуту package верхнего уровня элемента manifest в файле AndroidManifest.xml.

preference

Как видно из предыдущего раздела, иногда плагину может потребоваться, чтобы пользователь указал значения для своих переменных. Чтобы сделать эти переменные обязательными, тег <platform> должен содержать тег <preference>. Командная строка проверяет, что эти необходимые параметры переданы. Если нет, она должна предупредить пользователя о том, как передать переменную, и завершить работу с ненулевым кодом. К переменным можно обратиться в других частях plugin.xml с помощью синтаксиса $PREFERENCE_NAME.

Пример:

<preference name="MY_CUSTOM_STRING" default="default-value" />

<!--
    The preference may be referenced elsewhere in plugin.xml like so:
-->
<config-file target="./res/values/strings.xml" parent="/resources">
    <string name="custom">$MY_CUSTOM_STRING</string>
</config-file>