license: Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
Die plugin.xml Datei ist ein XML‑Dokument in den plugins Namespace: http://apache.org/cordova/ns/plugins/1.0 . Es enthält eine Top-Level- plugin Element, das das Plugin definiert, und Kinder, die die Struktur des Plugins zu definieren.
Ein Beispiel-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">
Das plugin Element ist das Plugin Manifest Element der obersten Ebene. Es verfügt über die folgenden Attribute:
xmlns(erforderlich): die Plugin-Namespace http://apache.org/cordova/ns/plugins/1.0 . Enthält das Dokument XML aus anderen Namespaces, z. B. Tags hinzugefügt werden die AndroidManifest.xml -Datei, diese Namespaces sollten auch in Element der obersten Ebene enthalten sein.
id(erforderlich): eine Reverse-Domain style Bezeichner für das Plugin, wiecom.alunny.foo
version(erforderlich): eine Versionsnummer für das Plugin, das den folgende reguläre Ausdruck der Major-Minor-Patch Stil entspricht:
^\d+[.]\d+[.]\d+$
Die untergeordneten Elemente der <engines> Element angeben Versionen von Apache-Cordova-basierten Frameworks, die dieses Plugin unterstützt. Ein Beispiel:
<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>
Ähnlich wie die <plugin> des Elements version Attribut, die angegebenen Versionszeichenfolge sollte eine Major-Minor-Patch-Zeichenfolge, die dem regulären Ausdruck entsprechen entsprechen:
^\d+[.]\d+[.]\d+$
Motor-Elemente können auch angeben, fuzzy-Treffer um Wiederholung zu vermeiden und Wartung zu verringern, wenn die zugrunde liegende Plattform aktualisiert wird. Supporttools sollte mindestens > , >= , < und <= , zum Beispiel:
<engines>
<engine name="cordova" version=">=1.7.0" />
<engine name="cordova" version="<1.8.1" />
</engines>
Die <engine> Markierungen hat auch Standardunterstützung für alle die Hauptplattformen Cordova ist vorhanden. Angabe der cordova Motor Tag bedeutet, dass alle Versionen von Cordova auf jeder Plattform das Motor-Version-Attribut genügen müssen. Sie können auch eine Liste bestimmte Plattformen und ihre Versionen um die CatchAll-überschreiben cordova Motor:
<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>
Hier ist eine Liste der Standard-Suchmaschinen, die die “”-Tag unterstützt: * ‘Cordoba’ * ‘Cordova-Plugman’ * ‘Cordova-Amazon-Fireos’ * ‘Cordova-Android’ * ‘Cordova-Ios’ * ‘Cordova-blackberry10’ * ‘Cordova-wp8’ * ‘Cordova-windows8’
Benutzerdefinierte Apache Cordova-basierten Frameworks sollte aufgeführt sein, unter dem Motor-Tag angeben, etwa 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>
Ein benutzerdefinierter Apache Cordova-basiertes Framework erfordert, dass ein Motor-Element die folgenden Attribute enthält: name , version , scriptSrc , undplatform.
name(erforderlich): einen lesbaren Namen für Ihre benutzerdefinierte Rahmen.
version(erforderlich): die Version, die Ihr Framework verfügen muss, um zu installieren.
scriptSrc(erforderlich): der Skript-Datei, die Plugman sagt, welche Version von benutzerdefinierten Rahmen ist. Im Idealfall sollte diese Datei innerhalb des Verzeichnisses der obersten Ebene für Ihr Pluginverzeichnis.
platform(erforderlich): Welche Plattformen, Ihr Framework unterstützt. Sie können den Platzhalter * um zu sagen, für alle Plattformen unterstützt, geben Sie mehrere durch ein Pipezeichen wie android|ios|blackberry10 oder nur eine einzelne Plattform wieandroid.
Plugman bricht mit einem NULL-Code für jedes Plugin, dessen Ziel-Projekt des Motors Einschränkungen nicht erfüllt.
Wenn keine <engine> Markierungen angegeben ist, Plugman blind in das Projektverzeichnis angegebenen Cordova zu installieren versucht.
Ein lesbarer Name für das Plugin, dessen Textinhalt den Namen des plugins enthält. Zum Beispiel:
<name>Foo</name>
Dieses Element nicht (noch) Lokalisierung zu behandeln.
Eine Klartextbeschreibung für das Plugin. Der Textinhalt des Elements enthält die Beschreibung des Plugins. Ein Beispiel:
<description>Foo plugin description</description>
Dieses Element nicht (noch) Lokalisierung zu behandeln.
Plugin-Autor-Namen. Der Textinhalt des Elements enthält den Namen des Autors Plugin. Ein Beispiel:
<author>Foo plugin description</author>
Plugin-Schlüsselwörter. Der Textinhalt des Elements enthält eine durch Kommas getrennte Stichwörter, um das Plugin zu beschreiben. Ein Beispiel:
<keywords>foo,bar</keywords>
Plugin-Lizenz. Der Textinhalt des Elements enthält das Plugin-Lizenz. Ein Beispiel:
<license>Apache 2.0 License</license>
Ein oder mehrere Elemente Auflisten der Dateien oder Verzeichnisse in einer Cordova app kopieren www Verzeichnis. Beispiele:
<!-- 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" />
Alle <asset> Tags erfordern beide src und target Attribute. Nur Web-Plugins enthält meist <asset> Elemente. Alle <asset> Elemente, die geschachtelt sind <platform> Elemente geben plattformspezifische Web Vermögenswerte, wie unten beschrieben. Attribute enthalten:
src(erforderlich): wo die Datei oder das Verzeichnis befindet sich in das Plugin-Paket, bezogen auf das plugin.xml Dokument. Wenn eine Datei nicht, an der angegebenen vorhanden ist src Lage, Plugman beendet und kehrt den Installationsvorgang, gibt eine Benachrichtigung über den Konflikt und beendet mit einem NULL-Code.
target(erforderlich):
Wo die Datei oder das Verzeichnis sollte gefunden werden in der app Cordova bezogen auf das www Verzeichnis. Vermögenswerte können z. B. auf Unterverzeichnisse, eingesetzt werden:
<asset src="www/new-foo.js" target="js/experimental/foo.js" />
erstellt die js/experimental Verzeichnis innerhalb der www Verzeichnis, sofern bereits vorhanden, dann Kopien der new-foo.js Datei und benennt es foo.js . Existiert eine Datei schon am Zielort, Plugman beendet und kehrt den Installationsvorgang, gibt eine Benachrichtigung über den Konflikt und beendet mit einem NULL-Code.
Die meisten Plugins enthalten eine oder mehrere JavaScript-Dateien. Jeder <js-module> Tag entspricht einer JavaScript-Datei, und verhindert, dass das Plugin Benutzer hinzufügen ein <script> Tag für jede Datei. Während <asset> Markierungen kopieren Sie einfach eine Datei aus dem Plugin-Unterverzeichnis in www , <js-module> Markierungen sind viel komplexer. Sie sieht wie folgt:
<js-module src="socket.js" name="Socket">
<clobbers target="chrome.socket" />
</js-module>
Wenn Sie eine Plugin mit dem obigen Beispiel installieren socket.js wird kopiert www/plugins/my.plugin.id/socket.js , und als einen Eintrag hinzugefügt www/cordova_plugins.js . Einloggen zur Ladezeit cordova.js XHR verwendet, um jede Datei zu lesen und injizieren ein <script> Tag in HTML. Es fügt eine Zuordnung zum verprügeln oder gegebenenfalls zusammenführen, wie unten beschrieben.
Wickeln Sie nicht die Datei mit cordova.define , automatisch hinzugefügt wird. Das Modul ist verpackt in einen Verschluss mit module , exports , und require im Bereich, ist als normal, dass AMD-Module.
Details für den <js-module> Tag:
Der src verweist auf eine Datei in das Pluginverzeichnis bezogen auf die plugin.xml Datei.
Die name stellt den letzten Teil den Namen des Moduls. Es kann in der Regel sein, was du willst, und es nur wichtig, wenn Sie verwenden möchten cordova.require anderen Teilen Ihrer plugins in Ihrem JavaScript-Code importieren. Der Modulname für eine <js-module> ist Ihr Plugins id gefolgt vom Wert der name . Für das obige Beispiel mit einer id von chrome.socket , den Namen des Moduls istchrome.socket.Socket.
Drei Tags sind erlaubt, innerhalb <js-module> :
<clobbers target="some.value"/>Gibt an, dass die module.exports eingefügt ist die window -Objekts als window.some.value . Kann man so viele <clobbers> wie du willst. Jedes Objekt nicht verfügbar auf window wird erstellt.
<merges target="some.value"/>Gibt an, dass das Modul mit bereits vorhandene Werte bei zusammengeführt werden sollen window.some.value . Wenn alle Schlüssel bereits vorhanden ist, überschreibt das Modul Version das Original. Kann man so viele <merges> wie du willst. Jedes Objekt nicht verfügbar auf window wird erstellt.
<runs/>Mittel, die Ihr Code mit angegeben werden sollte cordova.require , aber nicht auf installiert das window Objekt. Dies ist nützlich, wenn das Modul, das Anfügen von Ereignishandlern zu initialisieren oder auf andere Weise. Nur kann man bis zu einem <runs/> Tag. Beachten Sie, dass auch ein <runs/> mit <clobbers/> oder <merges/> ist überflüssig, da sie auch cordova.require Ihr Modul.
Eine leere <js-module> noch lädt und in anderen Modulen über zugegriffen werden kanncordova.require.
Wenn src , löst nicht an eine vorhandene Datei Plugman beendet und kehrt die Installation, gibt eine Benachrichtigung des Problems und beendet mit einem NULL-Code.
Schachteln <js-module> Elemente im <platform> deklariert plattformspezifische JavaScript-Modul Bindungen.
Die <dependency> Tag können Sie andere Plugins angeben, von denen das aktuelle Plugin abhängig ist. Während sie zukünftige Versionen von Plugin-Repositories zugreifen werden, kurzfristig Plugins direkt verwiesen als URLs von <dependency> Markierungen. Sie werden wie folgt formatiert:
<dependency id="com.plugin.id" url="https://github.com/myuser/someplugin" commit="428931ada3891801" subdir="some/path/here" />
id: stellt die ID des Plugins. Es sollte weltweit einzigartig und in Reverse Domain-Stil zum Ausdruck. Obwohl keiner von diesen Einschränkungen derzeit erzwungen wird, können sie in Zukunft sein.
url: Eine URL für das Plugin. Dies sollte ein Git-Repository verweisen, welche Plugman versucht zu klonen.
commit: Dies ist Git-Referenz von verstanden git checkout : einen Zweig oder eine Marke-Namen (z.B. master , 0.3.1 ), oder eine Commit hash (z.B.975ddb228af811dd8bb37ed1dfd092a3d05295f9).
subdir: Gibt an, dass die gezielte Plugin Abhängigkeit als ein Unterverzeichnis des Git Repository vorhanden ist. Dies hilfreich ist, da so das Repository für mehrere verwandte Plugins enthalten, festgelegt jeweils individuell.
In Zukunft Version Einschränkungen eingeführt werden, und ein Plugin Repository ist vorhanden, um abrufen nach Namen statt explizite URLs zu unterstützen.
Setzen Sie die url der ein <dependency> tag zu "." und bieten ein subdir , das abhängige Plugin installiert ist, aus der gleichen lokalen oder entfernten Git Repository als das übergeordnete Plugin angibt die <dependency> Tag.
Beachten Sie, dass die subdir immer gibt einen Pfad relativ zum Stammverzeichnis das Git Repository, nicht das übergeordnete-Plugin. Dies gilt auch dann, wenn Sie das Plugin mit einem lokalen Pfad direkt darauf installiert. Plugman findet die Wurzel das Git Repository und dann findet die anderen Plugin von dort.
Die <platform> Tag identifiziert Plattformen, die erfordern Änderungen an den Konfigurationsdateien oder systemeigenen Code zugeordnet. Tools, die unter Verwendung dieser Spezifikation können unterstützte Plattformen zu identifizieren und installieren Sie das Programm in Cordova Projekte.
Plugins ohne <platform> sind davon ausgegangen, dass die Tags nur JavaScript- und daher auf allen Plattformen installiert werden.
Ein Beispiel-Plattform-Tag:
<platform name="android">
<!-- android-specific elements -->
</platform>
<platform name="ios">
<!-- ios-specific elements -->
</platform>
Die erforderlichen name -Attribut identifiziert eine Plattform unterstützt, diese Plattform des Elements Kinder zuordnen.
Plattformnamen sollten Kleinbuchstaben sein. Plattformnamen, so willkürlich gewählt, sind aufgeführt:
Die <source-file> Element identifiziert ausführbare Quellcodes, die in ein Projekt installiert werden soll. Beispiele:
<!-- 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" />
Es unterstützt die folgenden Attribute:
src(erforderlich): Speicherort der Datei relativ zum plugin.xml . Wenn die src Datei nicht gefunden, Plugman beendet und kehrt die Installation, gibt eine Benachrichtigung über das Problem und beendet mit einem NULL-Code.
target-dir: Ein Verzeichnis, in dem die Dateien sollen, relativ zum Stammverzeichnis des Projektes Cordova kopiert werden. In der Praxis ist das wichtigste für Java-basierte Plattformen, wo eine Datei in die com.alunny.foo Paket muss in das com/alunny/foo Verzeichnis. Für Plattformen, wo das Quellverzeichnis nicht wichtig ist, sollte dieses Attribut weggelassen werden.
Wie bei Papieren, wenn die target von einer source-file würde die vorhandene Datei überschreiben, Plugman beendet und kehrt die Installation, gibt eine Benachrichtigung über das Problem und beendet mit einem NULL-Code.
framework(nur iOS): Wenn legen Sie auf true , auch die angegebene Datei als Rahmen dem Projekt hinzugefügt.
compiler-flags(nur iOS): Wenn festgelegt ist, weist der angegebenen Compiler-Flags für die bestimmten Quelldatei.
Bezeichnet eine XML-basierte Konfiguration-Datei, die geändert werden, wo in diesem Dokument die Änderung stattfinden sollen, und was geändert werden sollte.
Zwei Dateitypen, die auf die Änderung mit diesem Element getestet wurden sind xml und plist Dateien.
Die config-file Element nur können Sie neue Kinder an eine XML-Dokumentstruktur anhängen. Die Kinder sind XML-Literale im Zieldokument eingefügt werden soll.
Beispiel für 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>
Beispiel für plist :
<config-file target="*-Info.plist" parent="CFBundleURLTypes">
<array>
<dict>
<key>PackageName</key>
<string>$PACKAGE_NAME</string>
</dict>
</array>
</config-file>
Es unterstützt die folgenden Attribute:
target:
Die Datei geändert werden, und der Pfad relativ zum Stammverzeichnis des Projektes Cordova.
Das Ziel kann Platzhalter enthalten ( * ) Elemente. In diesem Fall Plugman rekursiv durchsucht die Verzeichnisstruktur des Projekts und verwendet die erste Übereinstimmung.
Auf iOS, der Speicherort der Konfigurationsdateien relativ zum Stammverzeichnis des Projekt-Verzeichnis ist nicht bekannt, also ein Ziel angeben config.xml löst incordova-ios-project/MyAppName/config.xml.
Wenn die angegebene Datei nicht vorhanden ist, wird das Tool ignoriert die Konfigurationsänderung und wird die Installation fortgesetzt.
parent: Eine XPath-Selector, verweisen auf das übergeordnete Element der Elemente der Config-Datei hinzugefügt werden. Wenn Sie absolute Selektoren verwenden, können Sie einen Platzhalter ( * ) an das Root-Element, z.B./*/plugins.
Für plist Dateien, die parent bestimmt, unter welchen übergeordneten Schlüssel der angegebene XML-Code eingefügt werden soll.
Wenn die Auswahl auf ein untergeordnetes Element des angegebenen Dokuments nicht behoben wird, das Tool beendet und kehrt des Installationsvorgangs gibt eine Warnung aus und beendet mit einem NULL-Code.
after: Eine priorisierte Liste der akzeptierten Geschwister nach dem den XML-Ausschnitt hinzugefügt. Nützlich für die Angabe von Änderungen in Dateien, die erfordern strikte Reihenfolge von XML-Elementen wie http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff769509%28v=vs.105%29.aspx#BKMK _EXTENSIONSelement
Die Windows-Plattform unterstützt zwei zusätzliche Attribute (beide optional) Wenn die meta name package.appxmanifestbeeinflussen:
Das device-target -Attribut angibt, der sollte nur aufgenommen werden, wenn für den angegebenen Zieltyp Gerät erstellen. Unterstützte Werte sind, win, phoneoder all.
Das versions -Attribut gibt an, dass die app Manifeste für bestimmte Windows-Versionen nur für Versionen geändert werden sollte, die die angegebene Zeichenfolge entsprechen. Wert kann semantische Versionszeichenfolge des Bereichs gültigen Knoten sein.
Beispiele für die Verwendung dieser Windows-spezifische Attribute:
<config-file target="package.appxmanifest" parent="/Package/Capabilities" versions="<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>
Das obige Beispiel setzt Pre-8.1-Plattformen (Windows 8 speziell) erfordern die Gerätefunktion Webcam und die allgemeine PicturesLibrary -Fähigkeit und Anwenden der Gerätefunktion Webcam nur auf Windows-8.1-Projekte, die für Windows Phone erstellen. Windows Desktop 8.1-Systemen sind unverändert.
Dies ist veraltet , da es nur Cordova-Ios 2.2.0 und unterhalb gilt. Verwenden Sie das <config-file> -Tag, neuere Versionen von Cordova.
Beispiel:
<config-file target="config.xml" parent="/widget/plugins">
<feature name="ChildBrowser">
<param name="ios-package" value="ChildBrowserCommand"/>
</feature>
</config-file>
Gibt einen Schlüssel und Wert auf die richtige AppInfo.plist -Datei in einem iOS-Cordova-Projekt anfügen. Zum Beispiel:
<plugins-plist key="Foo" string="CDVFoo" />
Wie Quelldateien, aber speziell für Plattformen wie iOS unterscheiden, die Quelldateien, Kopf- und Ressourcen. iOS Beispiele:
<resource-file src="CDVFoo.bundle" /> <resource-file src="CDVFooViewController.xib" /> <header-file src="CDVFoo.h" />
Android-Beispiel:
<resource-file src="FooPluginStrings.xml" target="res/values/FooPluginStrings.xml" />
Wie Quelle, Ressourcen- und Header-Dateien, aber speziell für Plattformen wie BlackBerry 10 User generated Bibliotheken verwenden. Beispiele:
<lib-file src="src/BlackBerry10/native/device/libfoo.so" arch="device" /> <lib-file src="src/BlackBerry10/native/simulator/libfoo.so" arch="simulator" />
Unterstützte Attribute:
src(erforderlich): der Speicherort der Datei relativ zum plugin.xml . Wenn src nicht auffindbar, Plugman beendet und kehrt die Installation Probleme eine Warnung über das Problem und beendet mit einem NULL-Code.
arch: Die Architektur, für die die .so Datei erstellt wurde, entweder device odersimulator.
Für die Windows-Plattform erlaubt das Element <lib-file> die Einbeziehung von einem < SDKReference > in die generierten Windows-Projektdateien.
Unterstützte Attribute:
src (erforderlich): der Name des SDK enthalten (die wird als Wert des Attributs Include des generierten < SDKReference >-Elements verwendet werden).
arch: gibt an, dass der < SDKReference > nur eingeschlossen werden soll, wenn für die angegebene Architektur erstellen. Unterstützte Werte sind x86, x64 oder ARM.
device-target: gibt an, dass der < SDKReference > nur eingeschlossen werden sollen, wenn für den angegebenen Zieltyp Gerät erstellen. Unterstützte Werte sind zu win (oder windows), phone oder all.
versions: gibt an, dass die < SDKReference > nur eingeschlossen werden soll, wenn für Versionen zu erstellen, die die angegebene Zeichenfolge entsprechen. Wert kann semantische Versionszeichenfolge des Bereichs gültigen Knoten sein.
Beispiele:
<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" />
Bezeichnet einen Rahmen (in der Regel Teil der OS/Plattform), von denen das Plugin abhängig ist.
Beispiele:
<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"/>
Das src -Attribut identifiziert Rahmen, welche Plugman versucht die Cordova-Projekt in der richtigen Weise für eine bestimmte Plattform hinzu.
Das optionale weak -Attribut ist ein boolescher Wert, der angibt, ob das Framework schwach verbunden sein sollte. Der Standardwert ist false.
Das optional custom Attribut ist ein boolescher Wert, der angibt, ob im Rahmen einer ist, als Teil Ihrer Plugin-Dateien enthalten ist (so ist es kein System-Rahmen). Der Standardwert ist false. Auf Android gibt es wie srczu behandeln. Wenn man true src der relative Pfad von der Application Project-Verzeichnis, sonst--aus dem Android SDK-Verzeichnis.
Das optionale type -Attribut ist eine Zeichenfolge, die den Typ des Rahmens hinzu. Derzeit nur projectReference wird unterstützt und nur für Windows. Mit custom='true' und type='projectReference' wird, fügen einen Verweis auf das Projekt, das die Kompilierung gutgeschrieben + Schritte des Projektes Cordova zu verknüpfen. Dies ist im Grunde die einzige Möglichkeit derzeit ein ‘custom’ Rahmen mehrere Architekturen angesprochen werden kann, da sie explizit als eine Abhängigkeit von der verweisenden Cordova-Anwendung erstellt werden.
Das optionale parent Attribut wird derzeit nur auf Android unterstützt. Er legt den relativen Pfad auf das Verzeichnis, in das Teilprojekt, der den Verweis hinzugefügt. Der Standardwert ist ., d. h. das Anwendungsprojekt. Es ermöglicht das Hinzufügen von Verweisen zwischen Teilprojekte wie in diesem Beispiel:
<framework src="FeedbackLib" custom="true" /> <framework src="extras/android/support/v7/appcompat" custom="false" parent="FeedbackLib" />
Die Windows-Plattform unterstützt drei zusätzliche Attribute (optional) zur Verfeinerung beim Rahmen eingeschlossen werden sollen:
Das arch -Attribut gibt an, dass Rahmen nur eingeschlossen werden soll, wenn für die angegebene Architektur erstellen. Unterstützte Werte sind x86, x64 oder ARM.
Das device-target -Attribut gibt an, dass Rahmen nur eingeschlossen werden soll, wenn für den angegebenen Zieltyp Gerät erstellen. Unterstützte Werte sind zu win (oder windows), phone oder all.
Das versions -Attribut gibt an, dass der Rahmen nur eingeschlossen werden soll, wenn für Versionen zu erstellen, die die angegebene Zeichenfolge entsprechen. Wert kann semantische Versionszeichenfolge des Bereichs gültigen Knoten sein.
Beispiele für die Verwendung dieser Windows-spezifische Attribute:
<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" />
Zusätzliche Informationen für die Nutzer. Dies ist nützlich, wenn Sie zusätzliche Schritte erforderlich, die können nicht einfach automatisiert werden oder Plugman den Rahmen sprengen. Beispiele:
<info> You need to install __Google Play Services__ from the `Android Extras` section using the Android SDK manager (run `android`). Sie müssen die 'local.properties' die folgende Zeile hinzu: android.library.reference.1=PATH_TO_ANDROID_SDK/sdk/extras/google/google_play_services/libproject/google-play-services_lib < / Info >
In bestimmten Fällen kann eine Plugin müssen Änderungen an der Konfiguration der Zielanwendung abhängig zu machen. Beispielsweise würde zur Anmeldung für C2DM auf Android eine app, die dessen Paket-Id com.alunny.message ist eine Berechtigung wie erforderlich:
<uses-permission android:name="com.alunny.message.permission.C2D_MESSAGE"/>
In solchen Fällen, wo aus der Datei plugin.xml eingefügte Inhalt nicht vor der Zeit bekannt ist, können durch ein Dollar-Zeichen, gefolgt von einer Reihe von Großbuchstaben, Ziffern und Unterstriche Variablen angegeben werden. Für das obige Beispiel würde die Datei plugin.xml diesem Tag gehören:
<uses-permission android:name="$PACKAGE_NAME.permission.C2D_MESSAGE"/>
Plugman Variablenreferenzen mit dem angegebenen Wert oder eine leere Zeichenfolge ersetzt, wenn keine gefunden. Der Wert der Variable Referenz kann erkannt (in diesem Fall aus der AndroidManifest.xml -Datei) oder vom Benutzer des Tools angegeben werden; der genaue Vorgang ist abhängig von der speziellen Werkzeug.
Plugman kann Benutzer ein Plugin erforderlichen Variablen angeben anfordern. API-Schlüssel für C2M und Google Maps können beispielsweise als Befehlszeilenargument angegeben werden:
plugman --platform android --project /path/to/project --plugin name|git-url|path --variable API_KEY=!@CFATGWE%^WGSFDGSDFW$%^#$%YTHGsdfhsfhyer56734
Um die Variable obligatorisch zu machen, muss das < Plattform > Tag ein < Präferenz > -Tag enthalten. Zum Beispiel:
<preference name="API_KEY" />
Plugman überprüft, ob diese erforderlichen Einstellungen in übergeben werden. Wenn dies nicht der Fall ist, sollte es den Benutzer warnen, übergeben Sie die Variable in und Ausfahrt mit einem NULL-Code veranschaulicht.
Bestimmten Variablennamen sollte reserviert werden, wie unten aufgeführt.
Der Reverse-Domäne Stil eindeutige Bezeichner für das Paket, CFBundleIdentifier in iOS oder das Paket -Attribut des Elements auf der obersten Ebene manifestieren in einer Datei AndroidManifest.xml entspricht.