[jira] [Created] (CB-14209) Focus restoration failure in onResume()
Michael Goffioul created CB-14209: - Summary: Focus restoration failure in onResume() Key: CB-14209 URL: https://issues.apache.org/jira/browse/CB-14209 Project: Apache Cordova Issue Type: Bug Components: cordova-android Reporter: Michael Goffioul I have a Cordova app running on a keyboard-driven device: it's a TV set-top box without any touchscreen, with Android 7.1.2. The app can launch other activities. Whenever the Cordova app resumes, the focus is moved to another DOM element, the DOM element that had the focus before the app was paused is lost. The order of precedence seems to be: - element with tabIndex="0" (or anything !="-1") - natively focusable elements, like - This seems to be caused by the fix for CB-7172. If I comment the fix, the focus is correctly restored to the element that had the focus before pausing. This is particularly annoying if the app contains an element, as this will trigger softkeyboard by default when the app is resumed. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13690) Change audio stream src in platform-browser
[ https://issues.apache.org/jira/browse/CB-13690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16408941#comment-16408941 ] Michael Goffioul commented on CB-13690: --- Same problem here, running Chrome 65. This is particularly annoying when the audio stream that was started is a live radio stream: the browser will keep downloading data forever. > Change audio stream src in platform-browser > --- > > Key: CB-13690 > URL: https://issues.apache.org/jira/browse/CB-13690 > Project: Apache Cordova > Issue Type: Bug > Components: cordova-plugin-media >Affects Versions: 4.0.0 > Environment: Browser >Reporter: Frank Owusu >Priority: Critical > Labels: Audio, browser, easyfix, patch, stream > Fix For: 4.0.0 > > > h2. Media object change src method for Browser. > when node is released stream src is still being downloaded. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13801) Fail to restore plugins with relative path
[
https://issues.apache.org/jira/browse/CB-13801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16387102#comment-16387102
]
Michael Goffioul commented on CB-13801:
---
FYI, there's quite a list of similar problems reported (CB-13637, CB-13503,
CB-13589, CB-12918) going back as far as June 2017. Unfortunately, it doesn't
look like it'll be fixed anytime soon. A (dirty) workaround that works for me
with cordova@8 is to define the plugin specs in config.xml (without 'file:'
prefix), but not in package.json.
> Fail to restore plugins with relative path
> --
>
> Key: CB-13801
> URL: https://issues.apache.org/jira/browse/CB-13801
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-lib
>Reporter: Michael Goffioul
>Priority: Major
>
> 1. Create a cordova project
> 2. Add android platform
> 3. Add a local plugin using a relative path: {{cordova plugin add
> myplugins/testplugin}}
> 4. Delete directories platforms/ and plugins/
> 5. Prepare android: {{cordova prepare android}}
> Cordova will fail to restore the local plugin. The plugin has been added to
> {{package.json}} using the spec {{file:myplugins/testplugin}} and the
> restoration utility is unable to handle such URL. Note that {{config.xml}}
> contains the spec {{myplugins/testplugin}} (that is, without the file:
> scheme), but the one in {{package.json}} takes precedence.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-13801) Fail to restore plugins with relative path
Michael Goffioul created CB-13801:
-
Summary: Fail to restore plugins with relative path
Key: CB-13801
URL: https://issues.apache.org/jira/browse/CB-13801
Project: Apache Cordova
Issue Type: Bug
Components: cordova-lib
Reporter: Michael Goffioul
1. Create a cordova project
2. Add android platform
3. Add a local plugin using a relative path: {{cordova plugin add
myplugins/testplugin}}
4. Delete directories platforms/ and plugins/
5. Prepare android: {{cordova prepare android}}
Cordova will fail to restore the local plugin. The plugin has been added to
{{package.json}} using the spec {{file:myplugins/testplugin}} and the
restoration utility is unable to handle such URL. Note that {{config.xml}}
contains the spec {{myplugins/testplugin}} (that is, without the file: scheme),
but the one in {{package.json}} takes precedence.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13647) Incomplete plugin restoration
[
https://issues.apache.org/jira/browse/CB-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16329302#comment-16329302
]
Michael Goffioul commented on CB-13647:
---
When will plugins be ported to use new paths? I've checked a couple of them and
they're still using legacy paths?
> Incomplete plugin restoration
> -
>
> Key: CB-13647
> URL: https://issues.apache.org/jira/browse/CB-13647
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-android
>Affects Versions: 7.0.0
>Reporter: Michael Goffioul
>Assignee: Joe Bowser
>Priority: Major
> Labels: android-next
>
> I'm having a problem with plugin restoration since cordova-android 7.0.0,
> when plugins use a mix of config-file and edit-config on the same file (e.g.
> AndroidManifest.xml) and only edit-config uses the real path to the file.
> I've tried both cordova-cli 6.5.0 and 7.1.0 with the same result.
> 1) Create a new corodva project and enter top-level direcotyr
> 2) Create subfolder to contain a local plugin: mkdir -p
> localplugins/testplugin1
> 3) Create the following files to define the local plugin:
> - plugin.xml (adds an attribute to and a category to
> )
> {code}
>
> http://apache.org/cordova/ns/plugins/1.0;
> id="com.example.testplugin1" version="1.0.0">
> Test Plugin 1
>
> parent="/manifest/application/activity/intent-filter">
>
>
> target="/manifest/application" mode="merge">
>
>
>
>
> {code}
> - package.json
> {code}
> {
> "name": "com.example.testplugin1",
> "version": "1.0.0"
> }
> {code}
> 4) Add android platform: cordova platform add android@7.0.0 --save
> 5) Add local plugin: cordova plugin add localplugins/testplugin1 --save
> At this point, if you check
> platforms/android/app/src/main/AndroidManifest.xml, it'll contain the 2
> changes defined in the plugin.
> Now attempt to use platform/plugin restoration with thw following:
> {code}
> cordova platform rm android
> cordova prepare android
> {code}
> If you check again AndroidManifest.xml, it will only contain one of the
> changes defined in the plugin (the attribute to ). The other
> change is missing.
> If you use the real path to AndroidManifest.xml for the definition of
> , then the problem does not occur. BUT, the problem can also
> occur when changes to AndroidManifest.xml are coming from multiple plugins,
> including the standard cordova plugin, most of which do not use the real path
> to AndroidManifest.xml yet.
> The problem can affect other files too. For instance I experienced incomplete
> restoration of plugins trying to register themselves in res/xml/config.xml.
> Only one plugin, out of 7, was using the real path
> app/src/main/res/xml/config.xml and I ended up with only one plugin defined
> in res/xml/config.xml, causing the application to fail to start.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13637) Unable to handle local plugins properly
[
https://issues.apache.org/jira/browse/CB-13637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16283763#comment-16283763
]
Michael Goffioul commented on CB-13637:
---
After some digging, it appears that although npm can handle relative "file:"
URLs, plugman cannot.
The problem seems to start around this location:
https://github.com/apache/cordova-lib/blob/master/src/plugman/fetch.js#L115
The variable "plugin_src" contains a relative file URL, like
"file:localplugins/testplugin". But the use of that URL in node's fs module
fails, for instance to code fails to detect that it's a local path and handle
it accordingly. I could verify that adding this code just above referenced line
fix the problem for me:
{code}
if (uri.protocol === 'file:' && uri.pathname && uri.pathname[0] !==
'/') {
plugin_src = plugin_src.substring(5);
}
{code}
> Unable to handle local plugins properly
> ---
>
> Key: CB-13637
> URL: https://issues.apache.org/jira/browse/CB-13637
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-lib
>Reporter: Michael Goffioul
>
> 1) create a new cordova project
> 2) inside the project directory, create folder "localplugins/testplugin"
> containing the file:
> - package.json
> {code}
> {
> "name": "com.example.cordova.plugin",
> "version": "1.0.0"
> }
> {code}
> - plugin.xml
> {code}
>
> http://apache.org/cordova/ns/plugins/1.0;
> id="com.example.cordova.plugin" version="1.0.0">
> Test Plugin
>
>
>
>
>
>
> {code}
> 3) add android patform: cordova platform add android
> 4) prepare android: cordova prepare android
> At this point, both package.json and config.xml contain a reference to the
> plugin using "file:localplugins/testplugin". The problem is that it's
> impossible to use the same plugin reference in both files, and still having
> plugin restoration and/or "npm install" to work.
> If I delete platforms/ and plugins/ subdir (these are typically not under git
> revision control) and run "cordova prepare android" to restore the platforms
> and the plugins, it fails with error:
> {code}
> Discovered plugin "com.example.cordova.plugin" in config.xml. Adding it to
> the project
> Failed to restore plugin "com.example.cordova.plugin" from config.xml. You
> might need to try adding it again. Error: Failed to fetch plugin
> file:localplugins/testplugin via registry.
> Probably this is either a connection problem, or plugin spec is incorrect.
> Check your connection and plugin name/version/URL.
> Failed to get absolute path to installed module
> {code}
> If I edit package.json and config.xml, and remove the prefix "file:" in the
> plugin spec, then restoration works ok. But then, it's "npm install" that
> fails.
> What works is to use the "file:" prefix in package.json and not use it in
> "config.xml". But that's not possible as preparation will make sure both are
> identical.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-13637) Unable to handle local plugins properly
[
https://issues.apache.org/jira/browse/CB-13637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Goffioul updated CB-13637:
--
Component/s: (was: cordova-cli)
> Unable to handle local plugins properly
> ---
>
> Key: CB-13637
> URL: https://issues.apache.org/jira/browse/CB-13637
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-lib
>Reporter: Michael Goffioul
>
> 1) create a new cordova project
> 2) inside the project directory, create folder "localplugins/testplugin"
> containing the file:
> - package.json
> {code}
> {
> "name": "com.example.cordova.plugin",
> "version": "1.0.0"
> }
> {code}
> - plugin.xml
> {code}
>
> http://apache.org/cordova/ns/plugins/1.0;
> id="com.example.cordova.plugin" version="1.0.0">
> Test Plugin
>
>
>
>
>
>
> {code}
> 3) add android patform: cordova platform add android
> 4) prepare android: cordova prepare android
> At this point, both package.json and config.xml contain a reference to the
> plugin using "file:localplugins/testplugin". The problem is that it's
> impossible to use the same plugin reference in both files, and still having
> plugin restoration and/or "npm install" to work.
> If I delete platforms/ and plugins/ subdir (these are typically not under git
> revision control) and run "cordova prepare android" to restore the platforms
> and the plugins, it fails with error:
> {code}
> Discovered plugin "com.example.cordova.plugin" in config.xml. Adding it to
> the project
> Failed to restore plugin "com.example.cordova.plugin" from config.xml. You
> might need to try adding it again. Error: Failed to fetch plugin
> file:localplugins/testplugin via registry.
> Probably this is either a connection problem, or plugin spec is incorrect.
> Check your connection and plugin name/version/URL.
> Failed to get absolute path to installed module
> {code}
> If I edit package.json and config.xml, and remove the prefix "file:" in the
> plugin spec, then restoration works ok. But then, it's "npm install" that
> fails.
> What works is to use the "file:" prefix in package.json and not use it in
> "config.xml". But that's not possible as preparation will make sure both are
> identical.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13647) Incomplete plugin restoration
[
https://issues.apache.org/jira/browse/CB-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16283474#comment-16283474
]
Michael Goffioul commented on CB-13647:
---
[~bowserj] I admit that 2 entries with different path types is
more theoretical. The more practical problem I faced was with my own plugin,
using both and . The cordova-android@7.0.0 release
notes only states to modify , it doesn't say anything about
, and more importantly it doesn't state that if you use both, they
MUST refer to the same path type.
I'm using cordova-common@2.2.0
On a side but related note, I also faced inconsistencies when using
, because path translation is enforced, meaning you can't (and
must not) use the prefix "app/src/main" in the target attribute. For instance,
with the following plugin.xml, you end up with a file in
platforms/android/app/src/main/app/src/main/res/drawable/image.png and that's
not what you want:
{code}
http://apache.org/cordova/ns/plugins/1.0;
id="com.example.testplugin1" version="1.0.0">
Test Plugin 1
{code}
So at the moment, the rules I've figured out are (new == with prefix
"app/src/main", legacy == without prefix):
- : you may use new or legacy paths
- : you may only use new paths
- : you may use new or legacy paths for *.java files; for other
files you may only use new paths
- : you may only use legacy paths
It would be easier to have a consistent behavior for all of them.
> Incomplete plugin restoration
> -
>
> Key: CB-13647
> URL: https://issues.apache.org/jira/browse/CB-13647
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-android
>Affects Versions: 7.0.0
>Reporter: Michael Goffioul
>Assignee: Joe Bowser
>
> I'm having a problem with plugin restoration since cordova-android 7.0.0,
> when plugins use a mix of config-file and edit-config on the same file (e.g.
> AndroidManifest.xml) and only edit-config uses the real path to the file.
> I've tried both cordova-cli 6.5.0 and 7.1.0 with the same result.
> 1) Create a new corodva project and enter top-level direcotyr
> 2) Create subfolder to contain a local plugin: mkdir -p
> localplugins/testplugin1
> 3) Create the following files to define the local plugin:
> - plugin.xml (adds an attribute to and a category to
> )
> {code}
>
> http://apache.org/cordova/ns/plugins/1.0;
> id="com.example.testplugin1" version="1.0.0">
> Test Plugin 1
>
> parent="/manifest/application/activity/intent-filter">
>
>
> target="/manifest/application" mode="merge">
>
>
>
>
> {code}
> - package.json
> {code}
> {
> "name": "com.example.testplugin1",
> "version": "1.0.0"
> }
> {code}
> 4) Add android platform: cordova platform add android@7.0.0 --save
> 5) Add local plugin: cordova plugin add localplugins/testplugin1 --save
> At this point, if you check
> platforms/android/app/src/main/AndroidManifest.xml, it'll contain the 2
> changes defined in the plugin.
> Now attempt to use platform/plugin restoration with thw following:
> {code}
> cordova platform rm android
> cordova prepare android
> {code}
> If you check again AndroidManifest.xml, it will only contain one of the
> changes defined in the plugin (the attribute to ). The other
> change is missing.
> If you use the real path to AndroidManifest.xml for the definition of
> , then the problem does not occur. BUT, the problem can also
> occur when changes to AndroidManifest.xml are coming from multiple plugins,
> including the standard cordova plugin, most of which do not use the real path
> to AndroidManifest.xml yet.
> The problem can affect other files too. For instance I experienced incomplete
> restoration of plugins trying to register themselves in res/xml/config.xml.
> Only one plugin, out of 7, was using the real path
> app/src/main/res/xml/config.xml and I ended up with only one plugin defined
> in res/xml/config.xml, causing the application to fail to start.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13647) Incomplete plugin restoration
[
https://issues.apache.org/jira/browse/CB-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16282828#comment-16282828
]
Michael Goffioul commented on CB-13647:
---
I understand the problem with edit-config is known and documented. The problem
is when mixing config-file/edit-config with new and legacy paths. And it
doesn't have to include edit-config. For instance, if you change the plugin.xml
with the following (notice how the 2 config-file target the same file, but with
different paths):
{code}
http://apache.org/cordova/ns/plugins/1.0;
id="com.example.testplugin1" version="1.0.0">
Test Plugin 1
{code}
If you add the plugin with "cordova plugin add localplugins/testplugin1", then
only 1 of the changes is applied (note that it does not even involve plugin
restoration anymore).
> Incomplete plugin restoration
> -
>
> Key: CB-13647
> URL: https://issues.apache.org/jira/browse/CB-13647
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-android
>Affects Versions: 7.0.0
>Reporter: Michael Goffioul
>Assignee: Joe Bowser
>Priority: Critical
>
> I'm having a problem with plugin restoration since cordova-android 7.0.0,
> when plugins use a mix of config-file and edit-config on the same file (e.g.
> AndroidManifest.xml) and only edit-config uses the real path to the file.
> I've tried both cordova-cli 6.5.0 and 7.1.0 with the same result.
> 1) Create a new corodva project and enter top-level direcotyr
> 2) Create subfolder to contain a local plugin: mkdir -p
> localplugins/testplugin1
> 3) Create the following files to define the local plugin:
> - plugin.xml (adds an attribute to and a category to
> )
> {code}
>
> http://apache.org/cordova/ns/plugins/1.0;
> id="com.example.testplugin1" version="1.0.0">
> Test Plugin 1
>
> parent="/manifest/application/activity/intent-filter">
>
>
> target="/manifest/application" mode="merge">
>
>
>
>
> {code}
> - package.json
> {code}
> {
> "name": "com.example.testplugin1",
> "version": "1.0.0"
> }
> {code}
> 4) Add android platform: cordova platform add android@7.0.0 --save
> 5) Add local plugin: cordova plugin add localplugins/testplugin1 --save
> At this point, if you check
> platforms/android/app/src/main/AndroidManifest.xml, it'll contain the 2
> changes defined in the plugin.
> Now attempt to use platform/plugin restoration with thw following:
> {code}
> cordova platform rm android
> cordova prepare android
> {code}
> If you check again AndroidManifest.xml, it will only contain one of the
> changes defined in the plugin (the attribute to ). The other
> change is missing.
> If you use the real path to AndroidManifest.xml for the definition of
> , then the problem does not occur. BUT, the problem can also
> occur when changes to AndroidManifest.xml are coming from multiple plugins,
> including the standard cordova plugin, most of which do not use the real path
> to AndroidManifest.xml yet.
> The problem can affect other files too. For instance I experienced incomplete
> restoration of plugins trying to register themselves in res/xml/config.xml.
> Only one plugin, out of 7, was using the real path
> app/src/main/res/xml/config.xml and I ended up with only one plugin defined
> in res/xml/config.xml, causing the application to fail to start.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13646) Unable to compile native code (android.useDeprecated.Ndk not supported anymore)
[
https://issues.apache.org/jira/browse/CB-13646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16282774#comment-16282774
]
Michael Goffioul commented on CB-13646:
---
Another workaround is to disable the automatic native code build step by
setting the jni.srcDirs to an empty list:
{code}
android.sourceSets.main {
jni.srcDirs = []
}
{code}
> Unable to compile native code (android.useDeprecated.Ndk not supported
> anymore)
> ---
>
> Key: CB-13646
> URL: https://issues.apache.org/jira/browse/CB-13646
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-android
>Affects Versions: 7.0.0
>Reporter: Michael Goffioul
>Assignee: Joe Bowser
>Priority: Critical
>
> A cordova project that contains native/jni code fails to compile, because
> android.useDeprecatedNdk is not supported anymore.
> Steps to reproduce:
> 1) create a new cordova project
> 2) add android platform
> 3) mkdir platforms/android/app/src/main/jni
> 4) touch platforms/android/app/src/main/jni/Android.mk
> 5) cordova build android
> It fails with the following error:
> {code}
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':app:compileDebugNdk'.
> > Error: Flag android.useDeprecatedNdk is no longer supported and will be
> > removed in the next version of Android Studio. Please switch to a
> > supported build system.
> Consider using CMake or ndk-build integration. For more information, go to:
>https://d.android.com/r/studio-ui/add-native-code.html#ndkCompile
>To get started, you can use the sample ndk-build script the Android
>plugin generated for you at:
> .../testnative/platforms/android/app/build/intermediates/ndk/debug/Android.mk
> Alternatively, you can use the experimental plugin:
>https://developer.android.com/r/tools/experimental-plugin.html
> To continue using the deprecated NDK compile for another 60 days, set
> android.deprecatedNdkCompileLease=1512654767567 in gradle.properties
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-13647) Incomplete plugin restoration
Michael Goffioul created CB-13647:
-
Summary: Incomplete plugin restoration
Key: CB-13647
URL: https://issues.apache.org/jira/browse/CB-13647
Project: Apache Cordova
Issue Type: Bug
Components: cordova-android
Affects Versions: 7.0.0
Reporter: Michael Goffioul
Assignee: Joe Bowser
Priority: Critical
I'm having a problem with plugin restoration since cordova-android 7.0.0, when
plugins use a mix of config-file and edit-config on the same file (e.g.
AndroidManifest.xml) and only edit-config uses the real path to the file. I've
tried both cordova-cli 6.5.0 and 7.1.0 with the same result.
1) Create a new corodva project and enter top-level direcotyr
2) Create subfolder to contain a local plugin: mkdir -p localplugins/testplugin1
3) Create the following files to define the local plugin:
- plugin.xml (adds an attribute to and a category to
)
{code}
http://apache.org/cordova/ns/plugins/1.0;
id="com.example.testplugin1" version="1.0.0">
Test Plugin 1
{code}
- package.json
{code}
{
"name": "com.example.testplugin1",
"version": "1.0.0"
}
{code}
4) Add android platform: cordova platform add android@7.0.0 --save
5) Add local plugin: cordova plugin add localplugins/testplugin1 --save
At this point, if you check platforms/android/app/src/main/AndroidManifest.xml,
it'll contain the 2 changes defined in the plugin.
Now attempt to use platform/plugin restoration with thw following:
{code}
cordova platform rm android
cordova prepare android
{code}
If you check again AndroidManifest.xml, it will only contain one of the changes
defined in the plugin (the attribute to ). The other change is
missing.
If you use the real path to AndroidManifest.xml for the definition of
, then the problem does not occur. BUT, the problem can also occur
when changes to AndroidManifest.xml are coming from multiple plugins, including
the standard cordova plugin, most of which do not use the real path to
AndroidManifest.xml yet.
The problem can affect other files too. For instance I experienced incomplete
restoration of plugins trying to register themselves in res/xml/config.xml.
Only one plugin, out of 7, was using the real path
app/src/main/res/xml/config.xml and I ended up with only one plugin defined in
res/xml/config.xml, causing the application to fail to start.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13646) Unable to compile native code (android.useDeprecated.Ndk not supported anymore)
[
https://issues.apache.org/jira/browse/CB-13646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16282091#comment-16282091
]
Michael Goffioul commented on CB-13646:
---
One possible workaround is to user gradleArg to override the property set by
GradleBuilder:
{code}
cordova build android -- --gradleArg=-Pandroid.useDeprecatedNdk=false
{code}
> Unable to compile native code (android.useDeprecated.Ndk not supported
> anymore)
> ---
>
> Key: CB-13646
> URL: https://issues.apache.org/jira/browse/CB-13646
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-android
>Affects Versions: 7.0.0
>Reporter: Michael Goffioul
>Assignee: Joe Bowser
>Priority: Critical
>
> A cordova project that contains native/jni code fails to compile, because
> android.useDeprecatedNdk is not supported anymore.
> Steps to reproduce:
> 1) create a new cordova project
> 2) add android platform
> 3) mkdir platforms/android/app/src/main/jni
> 4) touch platforms/android/app/src/main/jni/Android.mk
> 5) cordova build android
> It fails with the following error:
> {code}
> FAILURE: Build failed with an exception.
> * What went wrong:
> Execution failed for task ':app:compileDebugNdk'.
> > Error: Flag android.useDeprecatedNdk is no longer supported and will be
> > removed in the next version of Android Studio. Please switch to a
> > supported build system.
> Consider using CMake or ndk-build integration. For more information, go to:
>https://d.android.com/r/studio-ui/add-native-code.html#ndkCompile
>To get started, you can use the sample ndk-build script the Android
>plugin generated for you at:
> .../testnative/platforms/android/app/build/intermediates/ndk/debug/Android.mk
> Alternatively, you can use the experimental plugin:
>https://developer.android.com/r/tools/experimental-plugin.html
> To continue using the deprecated NDK compile for another 60 days, set
> android.deprecatedNdkCompileLease=1512654767567 in gradle.properties
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-13646) Unable to compile native code (android.useDeprecated.Ndk not supported anymore)
Michael Goffioul created CB-13646:
-
Summary: Unable to compile native code (android.useDeprecated.Ndk
not supported anymore)
Key: CB-13646
URL: https://issues.apache.org/jira/browse/CB-13646
Project: Apache Cordova
Issue Type: Bug
Components: cordova-android
Affects Versions: 7.0.0
Reporter: Michael Goffioul
Assignee: Joe Bowser
Priority: Critical
A cordova project that contains native/jni code fails to compile, because
android.useDeprecatedNdk is not supported anymore.
Steps to reproduce:
1) create a new cordova project
2) add android platform
3) mkdir platforms/android/app/src/main/jni
4) touch platforms/android/app/src/main/jni/Android.mk
5) cordova build android
It fails with the following error:
{code}
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':app:compileDebugNdk'.
> Error: Flag android.useDeprecatedNdk is no longer supported and will be
> removed in the next version of Android Studio. Please switch to a supported
> build system.
Consider using CMake or ndk-build integration. For more information, go to:
https://d.android.com/r/studio-ui/add-native-code.html#ndkCompile
To get started, you can use the sample ndk-build script the Android
plugin generated for you at:
.../testnative/platforms/android/app/build/intermediates/ndk/debug/Android.mk
Alternatively, you can use the experimental plugin:
https://developer.android.com/r/tools/experimental-plugin.html
To continue using the deprecated NDK compile for another 60 days, set
android.deprecatedNdkCompileLease=1512654767567 in gradle.properties
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Updated] (CB-13637) Unable to handle local plugins properly
[
https://issues.apache.org/jira/browse/CB-13637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Goffioul updated CB-13637:
--
Component/s: cordova-lib
> Unable to handle local plugins properly
> ---
>
> Key: CB-13637
> URL: https://issues.apache.org/jira/browse/CB-13637
> Project: Apache Cordova
> Issue Type: Bug
> Components: cordova-cli, cordova-lib
>Reporter: Michael Goffioul
>
> 1) create a new cordova project
> 2) inside the project directory, create folder "localplugins/testplugin"
> containing the file:
> - package.json
> {code}
> {
> "name": "com.example.cordova.plugin",
> "version": "1.0.0"
> }
> {code}
> - plugin.xml
> {code}
>
> http://apache.org/cordova/ns/plugins/1.0;
> id="com.example.cordova.plugin" version="1.0.0">
> Test Plugin
>
>
>
>
>
>
> {code}
> 3) add android patform: cordova platform add android
> 4) prepare android: cordova prepare android
> At this point, both package.json and config.xml contain a reference to the
> plugin using "file:localplugins/testplugin". The problem is that it's
> impossible to use the same plugin reference in both files, and still having
> plugin restoration and/or "npm install" to work.
> If I delete platforms/ and plugins/ subdir (these are typically not under git
> revision control) and run "cordova prepare android" to restore the platforms
> and the plugins, it fails with error:
> {code}
> Discovered plugin "com.example.cordova.plugin" in config.xml. Adding it to
> the project
> Failed to restore plugin "com.example.cordova.plugin" from config.xml. You
> might need to try adding it again. Error: Failed to fetch plugin
> file:localplugins/testplugin via registry.
> Probably this is either a connection problem, or plugin spec is incorrect.
> Check your connection and plugin name/version/URL.
> Failed to get absolute path to installed module
> {code}
> If I edit package.json and config.xml, and remove the prefix "file:" in the
> plugin spec, then restoration works ok. But then, it's "npm install" that
> fails.
> What works is to use the "file:" prefix in package.json and not use it in
> "config.xml". But that's not possible as preparation will make sure both are
> identical.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-13637) Unable to handle local plugins properly
Michael Goffioul created CB-13637:
-
Summary: Unable to handle local plugins properly
Key: CB-13637
URL: https://issues.apache.org/jira/browse/CB-13637
Project: Apache Cordova
Issue Type: Bug
Components: cordova-cli
Reporter: Michael Goffioul
1) create a new cordova project
2) inside the project directory, create folder "localplugins/testplugin"
containing the file:
- package.json
{code}
{
"name": "com.example.cordova.plugin",
"version": "1.0.0"
}
{code}
- plugin.xml
{code}
http://apache.org/cordova/ns/plugins/1.0;
id="com.example.cordova.plugin" version="1.0.0">
Test Plugin
{code}
3) add android patform: cordova platform add android
4) prepare android: cordova prepare android
At this point, both package.json and config.xml contain a reference to the
plugin using "file:localplugins/testplugin". The problem is that it's
impossible to use the same plugin reference in both files, and still having
plugin restoration and/or "npm install" to work.
If I delete platforms/ and plugins/ subdir (these are typically not under git
revision control) and run "cordova prepare android" to restore the platforms
and the plugins, it fails with error:
{code}
Discovered plugin "com.example.cordova.plugin" in config.xml. Adding it to the
project
Failed to restore plugin "com.example.cordova.plugin" from config.xml. You
might need to try adding it again. Error: Failed to fetch plugin
file:localplugins/testplugin via registry.
Probably this is either a connection problem, or plugin spec is incorrect.
Check your connection and plugin name/version/URL.
Failed to get absolute path to installed module
{code}
If I edit package.json and config.xml, and remove the prefix "file:" in the
plugin spec, then restoration works ok. But then, it's "npm install" that fails.
What works is to use the "file:" prefix in package.json and not use it in
"config.xml". But that's not possible as preparation will make sure both are
identical.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13634) Allow to keep the splashscreen window in onPause on Android
[ https://issues.apache.org/jira/browse/CB-13634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16277364#comment-16277364 ] Michael Goffioul commented on CB-13634: --- > Oh ok, so because of the `removeSplashScreen` call on pause of the app the > app can flicker if the splashscreen is still showing, correct? Yes. In my case, I want to keep the splashscreen while switching to another app. But because my app is being paused, the splashscreen window gets removed. > Do you know what the original comment "hide the splash screen to avoid > leaking a window" refers to above that call? I'm not sure, but I would say it might be because there is (or used to be) no guarantee that Android calls any other activity lifecycle method after onPause. I'm not sure whether that would leave a visible window on screen, I've never experienced it, but I would assume that when Android kills an app, all associated windows are also automatically removed. There might be some traces in the logs (like a backtrace), but no other visible effects. In all cases, the proposed PR just allow an app to change the default behavior, keeping things backward compatible. > Allow to keep the splashscreen window in onPause on Android > --- > > Key: CB-13634 > URL: https://issues.apache.org/jira/browse/CB-13634 > Project: Apache Cordova > Issue Type: Improvement > Components: cordova-plugin-splashscreen >Reporter: Michael Goffioul >Priority: Minor > > I have a use case whereby my webapp is launching another app while the > splashscreen is visible, and I want to keep the splashscreen window visible > to prevent unfriendly transient update during the app switching animation on > Android. It would be handy to allow an app to override the default behavior > of removing the splashscreen window in onPause. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-13634) Allow to keep the splashscreen window in onPause on Android
[ https://issues.apache.org/jira/browse/CB-13634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16277320#comment-16277320 ] Michael Goffioul commented on CB-13634: --- > What exactly does that mean? Can you illustrate? The removal of the splashscreen reveals the WebView component and whatever content is loaded at that time. This is happening during the app switching transition, and it looks like the screen is flickering, giving a bad user experience. > Allow to keep the splashscreen window in onPause on Android > --- > > Key: CB-13634 > URL: https://issues.apache.org/jira/browse/CB-13634 > Project: Apache Cordova > Issue Type: Improvement > Components: cordova-plugin-splashscreen >Reporter: Michael Goffioul >Priority: Minor > > I have a use case whereby my webapp is launching another app while the > splashscreen is visible, and I want to keep the splashscreen window visible > to prevent unfriendly transient update during the app switching animation on > Android. It would be handy to allow an app to override the default behavior > of removing the splashscreen window in onPause. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-13634) Allow to keep the splashscreen window in onPause on Android
Michael Goffioul created CB-13634: - Summary: Allow to keep the splashscreen window in onPause on Android Key: CB-13634 URL: https://issues.apache.org/jira/browse/CB-13634 Project: Apache Cordova Issue Type: Improvement Components: cordova-plugin-splashscreen Reporter: Michael Goffioul Priority: Minor I have a use case whereby my webapp is launching another app while the splashscreen is visible, and I want to keep the splashscreen window visible to prevent unfriendly transient update during the app switching animation on Android. It would be handy to allow an app to override the default behavior of removing the splashscreen window in onPause. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-13633) Report info/warning events on Android
Michael Goffioul created CB-13633: - Summary: Report info/warning events on Android Key: CB-13633 URL: https://issues.apache.org/jira/browse/CB-13633 Project: Apache Cordova Issue Type: Improvement Components: cordova-plugin-media Reporter: Michael Goffioul Priority: Minor In order to get notified of buffering events, it is handy to report info/warning events (MediaPlayer.OnInfoListener) up to the web application. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-13632) UDP not handled as streaming on Android
Michael Goffioul created CB-13632: - Summary: UDP not handled as streaming on Android Key: CB-13632 URL: https://issues.apache.org/jira/browse/CB-13632 Project: Apache Cordova Issue Type: Improvement Components: cordova-plugin-media Reporter: Michael Goffioul Priority: Minor When using a UDP multicast URL as media source, it is not handled as a streaming content by AudioPlayer.isStreaming(). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Created] (CB-13565) Splashscreen does not work when reloading content
Michael Goffioul created CB-13565: - Summary: Splashscreen does not work when reloading content Key: CB-13565 URL: https://issues.apache.org/jira/browse/CB-13565 Project: Apache Cordova Issue Type: Bug Components: cordova-windows Reporter: Michael Goffioul Assignee: Jesse MacFadyen If the app content is reloaded (e.g. calling "location.reload()"), the splashscreen does not work anymore and generate errors (variable "extendedSplashScreen" is not defined). This is because the "acivated" event has already been fired and "splashscreen.firstShow()" is not called. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
