cordovaforandroid
Ⅰ ionic3 cordova插件與cordova android版本的兼容性問題
cmdnode -v（檢查是否有node，-g表示全局安裝，否則要配置環境變數。nodejs在官網下載推薦版recommended for most users）npm install -g cordova ionic（如已安裝nodejs，可用npm安裝cordova和ionic）（鏈接不上會報錯，重新下載即可，下載太慢可分2步npm install -g cordova 和 npm install -g ionic 下載）
Ⅱ 運行cordova run android時報錯，如圖所示
g.gradle.wrapper.ExclusiveFileAccessManager.access(ExclusiveFileAccessManager.java:78)
at org.gradle.wrapper.Install.createDist(Install.java:47)
at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:129)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:48)
Caused by: java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:220)
at java.util.zip.ZipFile.(ZipFile.java:150)
at java.util.zip.ZipFile.(ZipFile.java:164)
at org.gradle.wrapper.Install.unzip(Install.java:160)
at org.gradle.wrapper.Install.access$400(Install.java:29)
at org.gradle.wrapper.Install$1.call(Install.java:70)
at org.gradle.wrapper.Install$1.call(Install.java:47)
at org.gradle.wrapper.ExclusiveFileAccessManager.access(ExclusiveFileAccessManager.java:65)
... 3 more
E:\cordova\hello\platforms\android\cordova\node_moles\q\q.js:126
throw e;
^
Error code 1 for command: cmd with args: /s /c "E:\cordova\hello\platforms\android\gradlew cdvBuildDebug -b E:\cordova\hello\platforms\android\build.gradle -PcdvBuildArch=arm -Dorg.gradle.daemon=true"
ERROR running one or more of the platforms: Error: E:\cordova\hello\platforms\android\cordova\run.bat: Command failed with exit code 1
Ⅲ crodova怎麼直接調用android原生方法
crodova直接調用android原生方法的時候要了解一些東西，你可以看下！我發你看下，
一．總體結構
Cordova的目標是用HTML，JS，來完成手機客戶端的開發，並且是只開發一次可以在各種手機平台上跑，所以理想狀態是用JS去控制所有事件。Cordova基於WebView組件。每個繼承自DroidGap的Activity對應一個獨立的CordovaWebView。Cordova提供了一些列的JS介面來訪問Android的native。以插件（Plugin）的形式提供自定義介面給JS端訪問。
二．一些疑問
1. Cordova框架是如何啟動的？
2. 插件是怎麼回事？如何工作的。
3. Cordova的官方文檔都是說JS如何訪問Android的native，那麼在Android的native中是否可以訪問JS的函數？如何訪問？
三．結構解剖
1．Cordova的啟動
1） 如何啟動
Cordova提供了一個Class（DroidGap）和一個interface（CordovaInterface）來讓Android開發者開發Cordova。一般情況下實現DroidGap即可，因為DroidGap類已經做了很多准備工作，可以說DroidGap類是Cordova框架的一個重要部分；如果在必要的情況下實現CordovaInterface介面，那麼這個類中很多DroidGap的功能需要自己去實現。
繼承了DroidGap或者CordovaInterface的Activity就是一個獨立的Cordova模塊，獨立的Cordova模塊指的是每個實現了DroidGap或者CordovaInterface介面的Activity都對應一套獨立的WebView，Plugin，PluginManager，沒有共享的。（我覺得這樣是很不爽的，沒有共享，如果plugin和Activity很多的情況下這樣是相當的耗資源）
當在實現了DroidGap或者CordovaInterface介面的Activity的onCreate方法中調用DroidGap的loadUrl方法即啟動了Cordova框架。
2）啟動過程
public class A extends DroidGap{}
a. 在A的onCreate方法中首先調用super. onCreate()
這一步中創建了一個LinearLayout（.class）布局，以及計算這個Layout的大小及顯示的一些方式。在後面的過程中會將一個WebView加到這個LinearLayout中。
b. 再次調用DroidGap 的loadUrl()方法
DroidGap. loadUrl()中首先判斷A的CordovaWebView是否實例化，如果沒有回實例化一個CordovaWebView對象並將該對象添加到父LinearLayout中去，同時將該LinearLayout添加的ContentView。見以下代碼：
public void onCreate(Bundle savedInstanceState) {
…
root = new (this, width, height);
…
}
public void init() {
CordovaWebView webView = new CordovaWebView(DroidGap.this);
this.init(webView,
new CordovaWebViewClient(this, webView),
new CordovaChromeClient(this, webView));
}
public void init(CordovaWebView webView, CordovaWebViewClient webViewClient, CordovaChromeClient webChromeClient) {
this.appView = webView;
this.appView.setId(100);
…
this.root.addView(this.appView);
setContentView(this.root);
}
public void loadUrl(String url) {
if (this.appView == null) {
this.init();
}
…
}
這樣就完成了我們在一般開發中使用的模式：
public void onCreate(Bundle savedInstanceState) {
super. onCreate(Bundle savedInstanceState);
setContentView(resID);
…
}
在初始化完CordovaWebView後調用CordovaWebView.loadUrl()。此時完成Cordova的啟動。
c. 在實例化CordovaWebView的時候, CordovaWebView對象會去創建一個屬於當前CordovaWebView對象的插件管理器PluginManager對象，一個消息隊列NativeToJsMessageQueue對象，一個JavascriptInterface對象ExposedJsApi，並將ExposedJsApi對象添加到CordovaWebView中，JavascriptInterface名字為：_cordovaNative。
d. Cordova的JavascriptInterface
在創建ExposedJsApi時需要CordovaWebView的PluginManager對象和NativeToJsMessageQueue對象。因為所有的JS端與Android native代碼交互都是通過ExposedJsApi對象的exec方法。
在exec方法中執行PluginManager的exec方法，PluginManager去查找具體的Plugin並實例化然後再執行Plugin的execute方法，並根據同步標識判斷是同步返回給JS消息還是非同步。由NativeToJsMessageQueue統一管理返回給JS的消息。
e. 何時載入Plugin，如何載入
Cordova在啟動每個Activity的時候都會將配置文件中的所有plugin載入到PluginManager。那麼是什麼時候將這些plugin載入到PluginManager的呢？
在b中說了最後會調用CordovaWebView.loadUrl()，對，就在這個時候會去初始化PluginManager並載入plugin。PluginManager在載入plugin的時候並不是馬上實例化plugin對象，而是只是將plugin的Class名字保存到一個hashmap中，用service名字作為key值。
當JS端通過JavascriptInterface介面的ExposedJsApi對象請求Android時，PluginManager會從hashmap中查找到plugin，如果該plugin還未實例化，利用java反射機制實例化該plugin，並執行plugin的execute方法。
2．Cordova插件
在『1』中已經接觸了些Cordova插件的東西，這里總結下Cordova的插件
Cordova插件只是一個普通的java類，沒有什麼特殊之處。插件中的execute方法只是Cordova框架的一個規定。
Cordova為了方便於插件的管理，所以引進了一個PluginManager來管理插件。在ExposedJsApi中，PluginManager起一個代理作用。
在原生態的WebView開發中，我們可以給WebView添加一個JavascriptInterface對象來使JS可以訪問android的代碼；在Cordova也有一個這樣的對象ExposedJsApi。
在ExposedJsApi中，它將請求轉發給我們的PluginManager，這個時候PluginManager會根據給的service的名字來查找具體的Plugin並執行。
所以，我認為Cordova插件是android端的API，提供給JS。
在Cordova雖然有JavascriptInterface對象ExposedJsApi，但在JS端並不是真正通過android提供的window.JavascriptInterface.request這種方式來請求。在JS端，Cordova是通過JS的prompt()函數觸發ChromeClient中的onJsPrompt方法，通過onJsPrompt去獲取到請求，再將請求轉發給ExposedJsApi。
註：在Cordova中，Java端和JavaScript端都准備了代碼來使用特殊URL（'http://cdv_exec/' + service + '#' + action + '#' + callbackId + '#' + argsJson;）的方式交互請求，但並沒有真正使用。
3．Cordova的數據返回
Cordova中通過exec()函數請求android插件，數據的返回可同步也可以非同步於exec()函數的請求。
在開發android插件的時候可以重寫public boolean isSynch(String action)方法來決定是同步還是非同步。
Cordova在android端使用了一個隊列(NativeToJsMessageQueue)來專門管理返回給JS的數據。
1）同步
Cordova在執行完exec()後，android會馬上返回數據，但不一定就是該次請求的數據，可能是前面某次請求的數據；因為當exec()請求的插件是允許同步返回數據的情況下，Cordova也是從NativeToJsMessageQueue隊列頭pop頭數據並返回。然後再根據callbackID反向查找某個JS請求，並將數據返回給該請求的success函數。
2）非同步
Cordova在執行完exec()後並不會同步得到一個返回數據。Cordova在執行exec()的同時啟動了一個XMLHttpRequest對象方式或者prompt()函數方式的循環函數來不停的去獲取NativeToJsMessageQueue隊列中的數據，並根據callbackID反向查找到相對應的JS請求，並將該數據交給success函數。
註：Cordova對本地的HTML文件(file:// 開頭的URL)或者手機設置有代理的情況下使用XMLHttpRequest方式獲取返回數據，其他則使用prompt()函數方式獲取返回數據。
4．Android代碼訪問JS
翻了Cordova的官方文檔和Cordova代碼，發現Cordova並未提供一種方式來讓我們在Android中去訪問JS。現在想來可能是這樣的道理（個人觀點），因為Cordova框架的性質就是一個用HTML+JS來開發APP的，相當於java用的虛擬機層（比喻不是很恰當），所以Cordova未提供Android訪問JS的方式。
如果需要Android訪問JS，只有使用原生態WebView開發的方式
loadUrl(「javascript:xxx」)
因為在Cordova框架中需要訪問JS的時候也是使用的這種方式，如下(Activity的onResume事件)：
public void handleResume(boolean keepRunning, boolean activityResultKeepRunning)
{
// Send resume event to JavaScript
this.loadUrl("javascript:try{cordova.fireDocumentEvent('resume');}catch(e){console.log('exception firing resume event from native');};");
// Forward to plugins
if (this.pluginManager != null) {
this.pluginManager.onResume(keepRunning);
}
// Resume JavaScript timers (including setInterval)
this.resumeTimers();
paused = false;
}
Ⅳ android studio集成cordova和安裝cordova有什麼不同
一般Android項目結構和目錄結構一樣，是這樣的：
MyApp
|--build.gradle
|--settings.gradle
|--app
|-- build.gradle
|-- build
|-- libs
|-- src
|-- main
|--java
| |-- com.package.myapp
|--res
|-- drawable
|-- layout
|-- etc
由Cordova創建的項目的目錄結構是這樣的（項目結構見上圖）
看起來很亂是不是。但是不影響使用，實際上也沒必要非要改成標准格式。因為Gradle已經幫我們在配置腳本中寫好了相關配置，它知道如何找到需要的文件。
按照標準的Gradle教程，項目即使沒有任何模塊(mole)，Android Studio也會為我們生成一個對應於項目的build.gradle腳本文件的。而觀察圖1，Android Studio打開的Cordova項目中卻沒有，編譯構建工作也可以正常進行，說明這個文件不是必須的。
它是在andorid、CordovaLib模塊中的build.gradle腳本中的android任務的sourceSets的main屬性，其中定義了Android Studio項目目錄結構和真實目錄的對應關系。比如android模塊下的build.gradle是這樣的：
sourceSets {
main {
manifest.srcFile 'AndroidManifest.xml'
java.srcDirs = ['src']
resources.srcDirs = ['src']
aidl.srcDirs = ['src']
renderscript.srcDirs = ['src']
res.srcDirs = ['res']
assets.srcDirs = ['assets']
jniLibs.srcDirs = ['libs']
}
}
詳細請參考G文第一篇 '保持舊的Eclipse文件結構' 部分。
可以看到，Android Studio中目錄的邏輯結構和系統中的文件夾結構是分離的，依靠的就是Gradle的配置能力。對比標準的項目目錄結構，Cordova項目把android模塊直接放在了項目的根下，而不是其他模塊那樣(比如CordovaLib模塊)作為子文件夾存在，這也說明了它為什麼不需要項目的build.gradle腳本，因為項目的腳本就是android模塊的腳本。之後添加的模塊，都是作為根目錄的子文件夾存在的。
此外還有一個多出來的cordova.gradle，以及和G文名稱不一致的local.properties。
Gradle腳本的詳細說明
上面部分讓我們對用Android Studio打開的Cordova項目有了些感性了解。它有其自已的獨特性：一方面Cordova創建的項目有自己的Gradle配置腳本，另一方面又保留了自己獨特的結構。接下來讓我們對Gradle腳本的各個部分作較為詳細的了解，同樣的基礎知識請參考G文或《Gradle for Android》一書。
我們看到Gradle腳本相關的文件有build.gradle(CordovaLib模塊)、build.gradle(android模塊)、cordova.gradle(CordovaLib模塊)、settings.gradle(項目)、local.properties(SDK Location)。看起來有些不一樣。
不過沒關系，我們知道Gradle構建時首先要去找build.gradle腳本的。通過上面的項目結構知道，首先執行的應該是邏輯上屬於android模塊，但實際上位於項目根目錄下的build.gradle。就從這里開始。
android模塊的build.gradle腳本
打開build.gradle。首先看到一些Cordova生成的一些注釋。原文就不照抄了，大意是一些授權說明信息。最後的單行注釋很關鍵："生成文件！請不要編輯！"。 雖然不能編輯，但一則其他的文件並沒有這么寫，二則做為入口文件，我們還是需要對它做一個了解。
注釋後緊接著就是buildscript方法。在它裡面首先是repositories方法，它告訴我們使用的庫是mavenCentral。接下來是依照已經在本地安裝的gradle的版本選擇使用的Gradle插件版本，並且語句上面有注釋可以參考，以後幾乎在每條語句上面都有注釋幫助我們理解並告訴我們相關參考資料的位置。
// 列表1-1。
buildscript {
repositories {
mavenCentral()
}
// Switch the Android Gradle plugin version requirement depending on the
// installed version of Gradle. This dependency is documented at
// http://tools.android.com/tech-docs/new-build-system/version-compatibility
// and https://issues.apache.org/jira/browse/CB-8143
if (gradle.gradleVersion >= "2.2") {
dependencies {
classpath 'com.android.tools.build:gradle:1.0.0+'
}
} else if (gradle.gradleVersion >= "2.1") {
dependencies {
classpath 'com.android.tools.build:gradle:0.14.0+'
}
} else {
dependencies {
classpath 'com.android.tools.build:gradle:0.12.0+'
}
}
}
隨後又使用了一個repositories任務。注釋說：允許插件通過build-extras.gradle聲明Maven依賴。通過extra這個名字，以及前面不要編輯的警告，它的作用可能是對這個build.gradle文件的修改或補充。其實在下面的代碼中可以看到更多這方面的信息。
// 列表1-2。
repositories {
mavenCentral()
}
接下來有一個wrapper任務，查閱文檔得知它用於定製Gradle Wrapper的。如果對Wrapper不了解，請參考《G》文的第一篇"使用Gradle Wrapper"部分。
// 列表1-3。
task wrapper(type: Wrapper) {
gradleVersion = '2.2.1'
}
接下來定義了一個ext屬性，其中定義了一些額外屬性。注釋也說明了其中定義的屬性需要通過環境變數、build-extras.gradle或gradle.properties設置。
ext屬性中首先引用了cordova.gradle。這樣就知道項目中這個文件用在哪裡了。但下面並沒有用到它。通過後面的代碼推測它可能是供build-extras.gradle調用的。接下來一系列條件判斷語句分別定義了一些屬性並把它們初為null。這些屬性是都以cdv開頭，表示一些Cordova構建屬性。接下來的代碼中會看到它們的作用。最後定義了一個cdvPluginPostBuildExtras數組變數，用來向裡面追加Gradle插件擴展。
// 列表1-4。
ext {
apply from: 'CordovaLib/cordova.gradle'
// The value for android.compileSdkVersion.
if (!project.hasProperty('cdvCompileSdkVersion')) {
cdvCompileSdkVersion = null;
}
// The value for android.buildToolsVersion.
if (!project.hasProperty('cdvBuildToolsVersion')) {
cdvBuildToolsVersion = null;
}
// Sets the versionCode to the given value.
if (!project.hasProperty('cdvVersionCode')) {
cdvVersionCode = null
}
// Sets the minSdkVersion to the given value.
if (!project.hasProperty('cdvMinSdkVersion')) {
cdvMinSdkVersion = null
}
// Whether to build architecture-specific APKs.
if (!project.hasProperty('cdvBuildMultipleApks')) {
cdvBuildMultipleApks = null
}
// .properties files to use for release signing.
if (!project.hasProperty('')) {
= null
}
// .properties files to use for debug signing.
if (!project.hasProperty('cdvDebugSigningPropertiesFile')) {
cdvDebugSigningPropertiesFile = null
}
// Set by build.js script.
if (!project.hasProperty('cdvBuildArch')) {
cdvBuildArch = null
}
// Plugin gradle extensions can append to this to have code run at the end.
cdvPluginPostBuildExtras = []
}
接下來這部分代碼，首先判斷build-extras.gradle文件是否存在，如果存在則把它應用到構建腳本中。下面的判斷語句檢查build-extras.gradle是否定義了列表1-4的屬性。如果有就使用build-extras.gradle中的，如果沒有，則按下面語句設置：
// 列表1-5。
// Set property defaults after extension .gradle files.
if (ext.cdvCompileSdkVersion == null) {
ext.cdvCompileSdkVersion = privateHelpers.getProjectTarget()
}
if (ext.cdvBuildToolsVersion == null) {
ext.cdvBuildToolsVersion = privateHelpers.findLatestInstalledBuildTools()
}
if (ext.cdvDebugSigningPropertiesFile == null && file('debug-signing.properties').exists()) {
ext.cdvDebugSigningPropertiesFile = 'debug-signing.properties'
}
if (ext. == null && file('release-signing.properties').exists()) {
ext. = 'release-signing.properties'
}
// Cast to appropriate types.
ext.cdvBuildMultipleApks = cdvBuildMultipleApks == null ? false : cdvBuildMultipleApks.toBoolean();
ext.cdvMinSdkVersion = cdvMinSdkVersion == null ? null : Integer.parseInt('' + cdvMinSdkVersion)
ext.cdvVersionCode = cdvVersionCode == null ? null : Integer.parseInt('' + cdvVersionCode)
上述代碼表示如果沒有設置列表1-4中的屬性時設置它們，其中調用了cordova.gradle腳本中的方法。如前所述之後會說明這些變數的作用。
接下來這段代碼，注釋告訴我們，要讓cdvBuild的任務依賴於debug/arch-specific，即平台相關，解決的是不同平台構建的問題。首先分成debug和release版，然後根據前面遇到過的cdvBuildMultipleApks和cdvBuildArch的變數判斷是否是跨平台構建，如果是則返回一個根據架構名生成的結果。注意到這個cdvBuildArch變數，在上面列表1-4的注釋中標明它由build.js設置。這個腳本位於項目目錄的cordova/lib/文件夾中，沒有納入到構建中，是cordova cli構建腳本，在這里先不做探討。
def computeBuildTargetName(debugBuild) {
def ret = 'assemble'
if (cdvBuildMultipleApks && cdvBuildArch) {
def arch = cdvBuildArch == 'arm' ? 'armv7' : cdvBuildArch
ret += '' + arch.toUpperCase().charAt(0) + arch.substring(1);
}
return ret + (debugBuild ? 'Debug' : 'Release')
}
// Make cdvBuild a task that depends on the debug/arch-sepecific task.
task cdvBuildDebug
cdvBuildDebug.dependsOn {
return computeBuildTargetName(true)
}
task cdvBuildRelease
cdvBuildRelease.dependsOn {
return computeBuildTargetName(false)
}
接下來定義了一個任務，顯然作用是輸出列表1-4以及後面定義過的屬性值。
task cdvPrintProps << {
println('cdvCompileSdkVersion=' + cdvCompileSdkVersion)
println('cdvBuildToolsVersion=' + cdvBuildToolsVersion)
println('cdvVersionCode=' + cdvVersionCode)
println('cdvMinSdkVersion=' + cdvMinSdkVersion)
println('cdvBuildMultipleApks=' + cdvBuildMultipleApks)
println('=' + )
println('cdvDebugSigningPropertiesFile=' + cdvDebugSigningPropertiesFile)
println('cdvBuildArch=' + cdvBuildArch)
println('computedVersionCode=' + android.defaultConfig.versionCode)
android.proctFlavors.each { flavor ->
println('computed' + flavor.name.capitalize() + 'VersionCode=' + flavor.versionCode)
}
}
接下來就是構建的核心部分，每個使用android插件構建都會有的android方法。裡面對android的構建定義了一些配置。這些配置的做用可以參考相關文章，這里就不贅述了。之後是在任務准備就緒後，對需要驗證的任務進行驗證。再下來定義的addSigningProps函數被android方法調用，用來在需要驗證時，為屬性文件添加驗證配置。最後配置了構建後要執行的方法，並且添加了在自定義配置文件build-extras.gradle中配置的構建後執行方法的入口。
總結
綜上，在Cordova項目中的android文件夾中的默認兩個模塊的內容作為容器和插件的源代碼，有其相對於普通Gradle Android特殊的目錄結構。android模塊把CordovaLib和web內容結合在一起生成Crodova應用，android模塊和CordovaLib通過使用共同的配置變數，保證了包括編譯SDK版本在內的一致性，並提供了額外配置的入口。但萬變不離其宗，這一切都是建立在了解Gradle構建工具的基礎上的。
望採納，謝謝
Ⅳ Android高版本http網路請求失敗的Cordova配置處理
問題出現的原因是因為Android高版本（Android 6.0）以上默認使用TLS保護用戶信息，詳見以下文檔：
Transport Layer Security
摘錄關鍵信息如下：
簡單地說，在Android高版本對非加密的明文傳輸有要求，也即默認啟用了TLS保護，使得該應用無法進行http網路請求，而https則不會受影響，同樣地，如果應用嵌套了webview也會受這限制。
針對這種情況，有以下解決方案：
然後在AnroidManifest.xml中的application添加指向該文件的設置項：
android:networkSecurityConfig="@xml/network_security_config"
綜合考量，第3種方案個人認為會好點，Cordova配合其使用也很簡單：
在config.xml文件中，在 <platform name="android"/> 節點內添加配置項即可：
這樣Cordova build的時候就會把上面配置合並到AnroidManifest.xml中。