AndroidManifest.xml
or MonacaApp-Info.plist
file respectively. However, for Cordova 6.2 or higher, both AndroidManifest.xml
and MonacaApp-Info.plist
files are removed from Monaca framework.config.xml
file that are not supported out-of-the-box by Cordova.<config-file>
=> <custom-config-file>
<preference>
=> <custom-preference>
<resource>
=> <custom-resource>
<config-file>
blocks in the config.xml, so <config-file>
blocks intended for this plugin to parse will be picked up by Cordova and can cause build errors (see #135) for an example.parse_unprefixed
preferenceConfigure → Cordova Plugin Settings
.Custom Config
plugin and click Enable
button.config.xml
file of the project to the relevant platform config files. Therefore, in order to use this plugin, you need to include the relevant keys in your config.xml
and the scripts will take care of the rest when you build your project.<widget>
element of your config.xml
:<preference>
element in the config.xml
file. For example:<platform>
element will apply<platform>
element will apply only toname="ios-somepref"
) and be defined inside a <platform>
<config-file>
blocks allow platform-specific chunks of the configuration to be defined as an XML subtree in the config.xml
file, which is then applied to the appropriate platform configuration file by the plugin.<config-file>
elements must be defined inside a <platform>
target
attributes specify the target file to update.AndroidManifest.xml
or *-Info.plist
)parent
attributes specify the parent elementAndroidManifest.xml
) or parent key (*-Info.plist
) that the<config-file>
elements are uniquely indexed by target and parent<uses-permission>
elements which are selected by byname
attribute), the last defined element willplatforms/android/AndroidManifest.xml
. For a list of possible manifest values, please refer to App Manifest. All Android-specific config should be placed inside the <platform name="android">
in config.xml
file.<preference>
elements in config.xml
are used to set attributes on elements in the AndroidManifest.xml
. For example, if you add the following element to the config.xml
:AndroidManifest.xml
:AndroidManifest.xml
. You can do delete them by using the delete="true"
attribute of the <preference>
element. For example, if you add the following line in config.xml
, it will delete the existing node <uses-permission android:name="android.permission.WRITE_CONTACTS" />
within AndroidManifest.xml
:android:
namespace in preferences within your config.xml
, you must include the android namespace attribute on the root <widget>
element.<widget>
element should look something like this:android-manifest
then follow with an XPath which specifies the element and attribute to apply the value to. For example,launchMode
attribute should be given a value of singleTask
which will be resulted as:CordovaApp
whereas Cordova 4.3.0 and above is MainActivity
.<manifest>
element, just omit the element name and specify the attribute. For example:<config-file>
blocks are used to define chunks of configuration of an XML subtree which will be inserted into AndroidManifest.xml
. The child elements inside the <config-file>
block will be inserted under the parent element.<config-file>
element has two attributes such as:target
: must be set to AndroidManifest.xml
.parent
: defines an Xpath to the parent element in the AndroidManifest.xml
under which the XML subtree block should be inserted:<manifest>
element, use parent="/*"
.<manifest>
, use an Xpath prefixed with ./
. For example, parent="./application/activity"
will insert the block under /manifest/application/activity
.AndroidManifest.xml
with:<application>
element. In this case, it would be better to use a preference:config.xml
file for Android configuration:*-Info.plist
) using config blocks, and project settings (project.pbxproj
) using preference elements. All iOS-specific config should be placed inside the <platform name="ios">
in config.xml
file.<preference>
elements in config.xml
are used to set preferences in the *-Info.plist
. Preferences should be defined in the format: <preference name="ios-SOME_BLOCK_TYPE-SOME_KEY" value="SOME_VALUE" />
. For example:XCBuildConfiguration
is the only supported block type in the project.pbxproj
. However, there is no constraint on the list of keys for which values may be set.XCBuildConfiguration
block for the specified key, the existing value will be overwritten with the specified value. If no entry exists in any XCBuildConfiguration
block for the specified key, a new key entry will be created in each XCBuildConfiguration
block with the specified value.XCBuildConfiguration
blocks. However, the block type can be specified by adding a buildType
attribute to the <preference>
element in the config.xml
. The value can be either debug
or release
. For example:XCBuildConfiguration
block. For example:project.pbxproj
as:quote
attribute on the <preference>
element. The valid values are:none
: don't quote key or valuekey
: quote key but not valuevalue
: quote value but not keyboth
: quote both key and valueproject.pbxproj
as:.xcconfig
files in /platforms/ios/cordova/
to override Xcode project settings in project.pbxproj
with build-type specific values. build.xcconfig
is overridden by settings in build-debug.xcconfig
and build-release.xcconfig
for the corresponding build type..xcconfig
file that corresponds to the buildType attribute.debug
or release
, the plugin willbuild-debug.xcconfig
or build-release.xcconfig
none
, the plugin willbuild.xcconfig
..xcconfig
file which corresponds to the custom preference name in the config.xml
, the value in the .xcconfig
file will be overwritten with the value in the config.xml
. To prevent the plugin from overwriting the value of a specific preference in the corresponding .xcconfig
file, set the preference attribute xcconfigEnforce="false"
. For example:.xcconfig
file, you can force its addition by setting the preference attribute xcconfigEnforce="true"
. This will append it to the corresponding .xcconfig
file. For example:.xcconfig
file will be made in plugins/cordova-custom-config/backup/ios
. By default, these backups will be restored prior to the next prepare operation. Auto-restore of the backups can be disabled by setting <preference name="cordova-custom-config-autorestore" value="false" />
in the config.xml
..xcconfig
files, so the quote
attribute has no effect on them.build-release.xcconfig
but for Debug builds in build.xcconfig
.config.xml
with buildType="release"
, the plugin will overwrite the defaults in build-release.xcconfig
. For example:config.xml
with buildType="debug"
, the plugin will overwrite the defaults in build.xcconfig
. For example:xcconfigEnforce="false"
. For example:buildType="debug"
to build-debug.xcconfig
, rather than overwriting the defaults in build.xcconfig
by setting xcconfigEnforce="true"
. This will still override the defaults in build.xcconfig
, because build-debug.xcconfig
overrides build.xcconfig
. For example:<config-file>
elements are currently only used to set preferences in the project .plist
file (platforms/ios/{PROJECT_NAME}/{PROJECT_NAME}-Info.plist
). This element has 3 attributes such as:target
: should be set to *-Info.plist
.platform
: should be set to ios
.parent
: is used to determine which key name to use for the custom{PROJECT_NAME}-Info.plist
as:<config-file>
element. These will appear directly below the preference <key>
in the .plist
file.plist
file as:config.xml
file for iOS configuration:cordova-custom-config
to avoid name clashes. For example:cordova-custom-config-autorestore
: (set to false
by default) if set to true
, the plugin will restore a backup of platform configuration files taken at plugin installation time.cordova-custom-config-stoponerror
: (set to false
by default) if set to true
and an error occurs while updating config for a given platform during a prepare
operation, the error will cause the prepare
operation to fail. If false, the plugin will log the error but will proceed and attempt to update any other platforms, before allowing the prepare operation to continue.