[jira] [Commented] (CB-7499) Cordova dialogs should support BIDI text
[
https://issues.apache.org/jira/browse/CB-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14169876#comment-14169876
]
Mike Billau commented on CB-7499:
-
Thanks Andrew for checking this out.
Agree about the tag.
To answer your question, yes plugins should check the API level.
I see you've already pulled in a fix to do this check:
https://github.com/apache/cordova-plugin-dialogs/commit/4cfe290b2a3e8f0aafb71a1ff4fbee4b710c8749
Tested on 2.3.3, looks great. Thanks.
> Cordova dialogs should support BIDI text
>
>
> Key: CB-7499
> URL: https://issues.apache.org/jira/browse/CB-7499
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, Plugin Dialogs
>Affects Versions: Master
>Reporter: Mike Billau
>Assignee: Mike Billau
>Priority: Minor
> Labels: bidirectional, globalization
> Fix For: 3.7.0
>
>
> Since API 19, Andorid has had the facilities to deal with bidirectional text,
> however, current Cordova notification implementation does not correctly
> handle bidirectional text in dialogs.
> We can see this is the case by first setting the language to Hebrew and then
> launching the following dialogs:
> navigator.notification.confirm("Pure English !!!", function(){}, "7");
> navigator.notification.confirm("עברית היא שפה מדוברת בIsrael !",
> function(){}, "8");
> Since we are in Hebrew, the base text direction will be RTL. This means that
> when we see the second notification with the Hebrew text, it will be
> right-justified. When we click and see the "Pure English !!!" notication,
> because locale is RTL, we should expect to see: "!!! Pure English" and it
> should be right-justified, however, we still see "Pure English !!!", left
> justified.
> http://w3-03.ibm.com/globalization/page/publish/4353
> Ideally you should be able to just add android:supportsRtl="true" to the
> manifest, however, this is doesn't seem to ne enough without setting the text
> direction to the locale for all of the dialogs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
[jira] [Commented] (CB-7499) Cordova dialogs should support BIDI text
[
https://issues.apache.org/jira/browse/CB-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14135355#comment-14135355
]
Mike Billau commented on CB-7499:
-
Hmmm, this plugin now depends on a specific version of Android (at least for
this feature to work) so maybe I need add in the engine tag to plugin.xml?
> Cordova dialogs should support BIDI text
>
>
> Key: CB-7499
> URL: https://issues.apache.org/jira/browse/CB-7499
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, Plugin Dialogs
>Affects Versions: Master
>Reporter: Mike Billau
>Assignee: Mike Billau
>Priority: Minor
> Labels: bidirectional, globalization
> Fix For: 3.7.0
>
>
> Since API 19, Andorid has had the facilities to deal with bidirectional text,
> however, current Cordova notification implementation does not correctly
> handle bidirectional text in dialogs.
> We can see this is the case by first setting the language to Hebrew and then
> launching the following dialogs:
> navigator.notification.confirm("Pure English !!!", function(){}, "7");
> navigator.notification.confirm("עברית היא שפה מדוברת בIsrael !",
> function(){}, "8");
> Since we are in Hebrew, the base text direction will be RTL. This means that
> when we see the second notification with the Hebrew text, it will be
> right-justified. When we click and see the "Pure English !!!" notication,
> because locale is RTL, we should expect to see: "!!! Pure English" and it
> should be right-justified, however, we still see "Pure English !!!", left
> justified.
> http://w3-03.ibm.com/globalization/page/publish/4353
> Ideally you should be able to just add android:supportsRtl="true" to the
> manifest, however, this is doesn't seem to ne enough without setting the text
> direction to the locale for all of the dialogs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CB-7499) Cordova dialogs should support BIDI text
[
https://issues.apache.org/jira/browse/CB-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Billau resolved CB-7499.
-
Resolution: Fixed
Fix Version/s: 3.7.0
> Cordova dialogs should support BIDI text
>
>
> Key: CB-7499
> URL: https://issues.apache.org/jira/browse/CB-7499
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, Plugin Dialogs
>Affects Versions: Master
>Reporter: Mike Billau
>Assignee: Mike Billau
>Priority: Minor
> Labels: bidirectional, globalization
> Fix For: 3.7.0
>
>
> Since API 19, Andorid has had the facilities to deal with bidirectional text,
> however, current Cordova notification implementation does not correctly
> handle bidirectional text in dialogs.
> We can see this is the case by first setting the language to Hebrew and then
> launching the following dialogs:
> navigator.notification.confirm("Pure English !!!", function(){}, "7");
> navigator.notification.confirm("עברית היא שפה מדוברת בIsrael !",
> function(){}, "8");
> Since we are in Hebrew, the base text direction will be RTL. This means that
> when we see the second notification with the Hebrew text, it will be
> right-justified. When we click and see the "Pure English !!!" notication,
> because locale is RTL, we should expect to see: "!!! Pure English" and it
> should be right-justified, however, we still see "Pure English !!!", left
> justified.
> http://w3-03.ibm.com/globalization/page/publish/4353
> Ideally you should be able to just add android:supportsRtl="true" to the
> manifest, however, this is doesn't seem to ne enough without setting the text
> direction to the locale for all of the dialogs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CB-4822) globalization.getLocaleName does not always return the real country setting
[ https://issues.apache.org/jira/browse/CB-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau resolved CB-4822. - Resolution: Fixed > globalization.getLocaleName does not always return the real country setting > --- > > Key: CB-4822 > URL: https://issues.apache.org/jira/browse/CB-4822 > Project: Apache Cordova > Issue Type: Improvement > Components: Plugin Globalization >Affects Versions: 2.7.0 >Reporter: Ingmar Bode > > Due to the documentation "globalization.getLocaleName" returns the locale > identifier of the browser. Unfortunately on some devices (e.g. iOS) the > browsers seem to return some kind of "fake" locale. For example, when I go in > my iPhone's settings and set language: en and region: uk, > globalization.getLocaleName returns "en_US" though I would expect "en_UK". > Is there any way you guys can make Cordova return the "real region" set in > the phones settings - and not what the phone's browser thinks? > Btw: We are using Telerik's Icenium. They are currently working with Cordova > 2.7., so maybe this issue has already been improved/fixed in later Cordova > versions? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CB-4822) globalization.getLocaleName does not always return the real country setting
[ https://issues.apache.org/jira/browse/CB-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128886#comment-14128886 ] Mike Billau commented on CB-4822: - Android returns "en-GB" when I set the language to English (United Kingdom), so this looks right for Android. > globalization.getLocaleName does not always return the real country setting > --- > > Key: CB-4822 > URL: https://issues.apache.org/jira/browse/CB-4822 > Project: Apache Cordova > Issue Type: Improvement > Components: Plugin Globalization >Affects Versions: 2.7.0 >Reporter: Ingmar Bode > > Due to the documentation "globalization.getLocaleName" returns the locale > identifier of the browser. Unfortunately on some devices (e.g. iOS) the > browsers seem to return some kind of "fake" locale. For example, when I go in > my iPhone's settings and set language: en and region: uk, > globalization.getLocaleName returns "en_US" though I would expect "en_UK". > Is there any way you guys can make Cordova return the "real region" set in > the phones settings - and not what the phone's browser thinks? > Btw: We are using Telerik's Icenium. They are currently working with Cordova > 2.7., so maybe this issue has already been improved/fixed in later Cordova > versions? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CB-6490) getLocaleName does not return consistent results depending on the platform
[ https://issues.apache.org/jira/browse/CB-6490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau resolved CB-6490. - Resolution: Fixed Fix Version/s: 3.6.0 Assignee: Mike Billau (was: Jesse MacFadyen) > getLocaleName does not return consistent results depending on the platform > -- > > Key: CB-6490 > URL: https://issues.apache.org/jira/browse/CB-6490 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin Globalization, WP8 > Environment: Windows Phone 8 >Reporter: Pascale Dardailler >Assignee: Mike Billau > Fix For: 3.6.0 > > > getLocaleName does not return consistent results depending on the platform. > The documentation should be changed to state that it should return a BCP 47 > representation of Unicode locale identifier (see > http://www.unicode.org/reports/tr35/#Unicode_locale_identifier - section > "3.3.1 BCP 47 tag conversion") to identify the culture of the user, and > disambiguate the region as a place. > Implementation should be changed accordingly. > WindowsPhone 8 implementation is incorrect. Returning country code is not > enough. It should use CultureInfo.CurrentCulture.Name. > Android and iOS should use "dashes" instead of "underscores". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CB-6490) getLocaleName does not return consistent results depending on the platform
[ https://issues.apache.org/jira/browse/CB-6490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14128814#comment-14128814 ] Mike Billau commented on CB-6490: - Android uses a dash. > getLocaleName does not return consistent results depending on the platform > -- > > Key: CB-6490 > URL: https://issues.apache.org/jira/browse/CB-6490 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin Globalization, WP8 > Environment: Windows Phone 8 >Reporter: Pascale Dardailler >Assignee: Jesse MacFadyen > > getLocaleName does not return consistent results depending on the platform. > The documentation should be changed to state that it should return a BCP 47 > representation of Unicode locale identifier (see > http://www.unicode.org/reports/tr35/#Unicode_locale_identifier - section > "3.3.1 BCP 47 tag conversion") to identify the culture of the user, and > disambiguate the region as a place. > Implementation should be changed accordingly. > WindowsPhone 8 implementation is incorrect. Returning country code is not > enough. It should use CultureInfo.CurrentCulture.Name. > Android and iOS should use "dashes" instead of "underscores". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CB-7499) Cordova dialogs should support BIDI text
Mike Billau created CB-7499:
---
Summary: Cordova dialogs should support BIDI text
Key: CB-7499
URL: https://issues.apache.org/jira/browse/CB-7499
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin Dialogs
Affects Versions: Master
Reporter: Mike Billau
Assignee: Mike Billau
Priority: Minor
Since API 19, Andorid has had the facilities to deal with bidirectional text,
however, current Cordova notification implementation does not correctly handle
bidirectional text in dialogs.
We can see this is the case by first setting the language to Hebrew and then
launching the following dialogs:
navigator.notification.confirm("Pure English !!!", function(){}, "7");
navigator.notification.confirm("עברית היא שפה מדוברת בIsrael !",
function(){}, "8");
Since we are in Hebrew, the base text direction will be RTL. This means that
when we see the second notification with the Hebrew text, it will be
right-justified. When we click and see the "Pure English !!!" notication,
because locale is RTL, we should expect to see: "!!! Pure English" and it
should be right-justified, however, we still see "Pure English !!!", left
justified.
http://w3-03.ibm.com/globalization/page/publish/4353
Ideally you should be able to just add android:supportsRtl="true" to the
manifest, however, this is doesn't seem to ne enough without setting the text
direction to the locale for all of the dialogs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CB-677) Docs/Getting Started Guides
[ https://issues.apache.org/jira/browse/CB-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14095534#comment-14095534 ] Mike Billau commented on CB-677: [~adamcmiel] I think you should ask that question on the dev list. We have been having discussions about the docs and doc generation on and off for a while now. > Docs/Getting Started Guides > --- > > Key: CB-677 > URL: https://issues.apache.org/jira/browse/CB-677 > Project: Apache Cordova > Issue Type: Improvement > Components: Docs >Affects Versions: Master >Reporter: Andrew Trice >Assignee: Michael Brooks >Priority: Minor > Fix For: Master > > > I have gotten a lot of feedback from Adobe customers and developers at > conferences on this... In general, the getting started guides are great at > getting people's environments configured, but many end up wondering "what do > I do next". It would be great to have docs/guidance on "next steps", > including strategies to make your apps feel more like "apps" and less like > "the web", performance optimizations, and possibly case studies on how > showcase apps were created. This JIRA issue is intended for tracking > purposes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-5294) File input element not opening file picker in Android 4.4
[ https://issues.apache.org/jira/browse/CB-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14029618#comment-14029618 ] Mike Billau commented on CB-5294: - I tested with Firefox and Chrome and both of them upload an image with the exact same filename as the one you select, so we are doing something different somewhere. At least the data gets transferred. > File input element not opening file picker in Android 4.4 > - > > Key: CB-5294 > URL: https://issues.apache.org/jira/browse/CB-5294 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 3.1.0 > Environment: Android 4.4.2, partially fixed in Android 4.4.3 >Reporter: Paul Kane >Assignee: Ian Clelland > > The file input field doesn't respond when clicked/tapped in Android 4.4. > Works fine in previous Android versions. This is regardless of whether the > Target Level is set to 18 or 19. > To reproduce, I created a fresh Cordova 3.1.0 project for Android. The only > modification I made to the default (placeholder) index.html file was adding a > element with a single element inside. Clicking the > "Choose File" button does nothing. No Logcat output or errors. Normally at > this point a dialogue would open allowing me to select an image from the > gallery or take a picture, which is what happens in older Android versions. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CB-5469) Document how to run npm without sudo
[ https://issues.apache.org/jira/browse/CB-5469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau resolved CB-5469. - Resolution: Fixed Resolved here: https://github.com/apache/cordova-docs/commit/7115ca4155e32ab49d7ebcecbe82f486056b76a6 > Document how to run npm without sudo > > > Key: CB-5469 > URL: https://issues.apache.org/jira/browse/CB-5469 > Project: Apache Cordova > Issue Type: Bug > Components: Docs >Reporter: Mike Billau >Assignee: Mike Billau >Priority: Minor > Fix For: 3.6.0 > > > We ask users to install npm globally. Whether or not we are going to continue > to suggest this is a different debate, but in the mean time we should talk > about how they can set up npm to run without requiring sudo/Administrator. > There is a wiki page here that talks about it: > https://wiki.apache.org/cordova/npm_rc > We need to build out this wiki page and then link to it in the docs. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-5294) File input element not opening file picker in Android 4.4
[ https://issues.apache.org/jira/browse/CB-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14019848#comment-14019848 ] Mike Billau commented on CB-5294: - Seems mostly fixed for me on Nexus 5 running 4.4.3. The button opens the file chooser dialog. No matter what source I select, the asset does seem to be uploaded. However, if you select from "Recent" or "Images", the file will be renamed from something like IMG_234234.jpg --> image%3A24. If you select from "Downloads", or "Gallery", the image will be renamed from: IMG_23432423.jpg --> 24 > File input element not opening file picker in Android 4.4 > - > > Key: CB-5294 > URL: https://issues.apache.org/jira/browse/CB-5294 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 3.1.0 > Environment: Android 4.4.2, partially fixed in Android 4.4.3 >Reporter: Paul Kane >Assignee: Ian Clelland > > The file input field doesn't respond when clicked/tapped in Android 4.4. > Works fine in previous Android versions. This is regardless of whether the > Target Level is set to 18 or 19. > To reproduce, I created a fresh Cordova 3.1.0 project for Android. The only > modification I made to the default (placeholder) index.html file was adding a > element with a single element inside. Clicking the > "Choose File" button does nothing. No Logcat output or errors. Normally at > this point a dialogue would open allowing me to select an image from the > gallery or take a picture, which is what happens in older Android versions. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-5398) Pick image from Library or Photo album on android 4.4
[ https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14011109#comment-14011109 ] Mike Billau commented on CB-5398: - [~roy_lecare], I was unable to reproduce the error with your code on Cordova 3.5, Camera 0.2.9 What "source" were you using to select the picture from? > Pick image from Library or Photo album on android 4.4 > - > > Key: CB-5398 > URL: https://issues.apache.org/jira/browse/CB-5398 > Project: Apache Cordova > Issue Type: Bug > Components: Android, Plugin Camera >Affects Versions: 2.9.0, 3.2.0 > Environment: android 4.4 >Reporter: julio cesar >Assignee: Mike Billau > Fix For: 3.5.0 > > > An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or > pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI. > Now android 4.4, when you select the above options, it opens an "open from" > dialog that let you choose from new places as "Recent", "Drive", "Images" > and "Downloads" (the names might not be the same as I use the device in > spanish and translated it). > If you choose any of them, you get an error, AndroidProtocolHandler, unable > to open content URL: the url here with a content://com.android.providers > format. > I've tested on phonegap 2.9 because this is the version I use, but I suppose > it affects all of them. (in fact I use 2.9.1) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CB-5470) Document differences between CLI and shell workflows
[ https://issues.apache.org/jira/browse/CB-5470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau resolved CB-5470. - Resolution: Won't Fix I don't think we need to be per scribing a certain workflow over the other, which is what this would turn into. > Document differences between CLI and shell workflows > > > Key: CB-5470 > URL: https://issues.apache.org/jira/browse/CB-5470 > Project: Apache Cordova > Issue Type: Bug > Components: Docs >Affects Versions: Master >Reporter: Mike Billau >Assignee: Mike Billau >Priority: Minor > Fix For: 3.6.0 > > > After CB-5122, we have documented the two different workflows, the CLI and > the shell scripts. > However, we should further document the advantages and disadvantages to each > workflow. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-2179) Warn developers about including third-party content in their apps.
[ https://issues.apache.org/jira/browse/CB-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14003838#comment-14003838 ] Mike Billau commented on CB-2179: - Added a new Security guide, documented that they should use InAppBrowser for any and all third party content and explained that otherwise, those third party pages will have access to the bridge. https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=7e6d5b9bc51c5249f20f7c3f2493923d609c7418 > Warn developers about including third-party content in their apps. > -- > > Key: CB-2179 > URL: https://issues.apache.org/jira/browse/CB-2179 > Project: Apache Cordova > Issue Type: Bug > Components: Docs >Affects Versions: 2.4.0, 2.5.0, 2.6.0 >Reporter: Andrew Grieve >Assignee: Andrew Grieve >Priority: Minor > Fix For: 3.5.0 > > > We expose our native APIs to iframes as well as top-level content, so we > should warn against using iframes for third-party code. > Might make sense to change "Domain Whitelist Guide" -> "Security & Whitelist > Guide" and then add a section to it about the dangers of embedding untrusted > content. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CB-2179) Warn developers about including third-party content in their apps.
[ https://issues.apache.org/jira/browse/CB-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau resolved CB-2179. - Resolution: Fixed > Warn developers about including third-party content in their apps. > -- > > Key: CB-2179 > URL: https://issues.apache.org/jira/browse/CB-2179 > Project: Apache Cordova > Issue Type: Bug > Components: Docs >Affects Versions: 2.4.0, 2.5.0, 2.6.0 >Reporter: Andrew Grieve >Assignee: Andrew Grieve >Priority: Minor > Fix For: 3.5.0 > > > We expose our native APIs to iframes as well as top-level content, so we > should warn against using iframes for third-party code. > Might make sense to change "Domain Whitelist Guide" -> "Security & Whitelist > Guide" and then add a section to it about the dangers of embedding untrusted > content. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CB-5786) document security best practices
[ https://issues.apache.org/jira/browse/CB-5786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau closed CB-5786. --- Resolution: Fixed Fix Version/s: 3.5.0 Added the first draft. Thanks everybody for the help. https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=commit;h=7e6d5b9bc51c5249f20f7c3f2493923d609c7418 Will continue to iterate on it as we go alone. > document security best practices > > > Key: CB-5786 > URL: https://issues.apache.org/jira/browse/CB-5786 > Project: Apache Cordova > Issue Type: Improvement > Components: Docs >Reporter: Marcel Kinard >Priority: Minor > Fix For: 3.5.0 > > > Would be nice if cordova-docs included a section on security in general. > Potential content could include: > - in general how does Cordova work > - common areas where devs may shoot themselves in the foot > - what the whitelist does and doesn't do > - when to consider InAppBrowser -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-677) Docs/Getting Started Guides
[ https://issues.apache.org/jira/browse/CB-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13986549#comment-13986549 ] Mike Billau commented on CB-677: Ray has started working on this here: https://docs.google.com/document/d/1uJ5qXqQxK2oh1eZPgMdYuhK2rQTB7QMHXUHbkcomWgk/edit# Looking awesome so far, thanks Ray! > Docs/Getting Started Guides > --- > > Key: CB-677 > URL: https://issues.apache.org/jira/browse/CB-677 > Project: Apache Cordova > Issue Type: Improvement > Components: Docs >Affects Versions: Master >Reporter: Andrew Trice >Assignee: Michael Brooks >Priority: Minor > Fix For: Master > > > I have gotten a lot of feedback from Adobe customers and developers at > conferences on this... In general, the getting started guides are great at > getting people's environments configured, but many end up wondering "what do > I do next". It would be great to have docs/guidance on "next steps", > including strategies to make your apps feel more like "apps" and less like > "the web", performance optimizations, and possibly case studies on how > showcase apps were created. This JIRA issue is intended for tracking > purposes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-4602) getPreferredLanguage platform inconsistencies
[
https://issues.apache.org/jira/browse/CB-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13984618#comment-13984618
]
Mike Billau commented on CB-4602:
-
I'm not sure what the difference between getPreferredLanguage() and
getLocaleName() is. Should one return the BCP-47 language tag ("en-US") while
the other return the actual text representation of the language ("English")?
Based on some older docs:
http://cordova.apache.org/docs/en/3.1.0/cordova_globalization_globalization.md.html#globalization.getPreferredLanguage,
it seems like getPreferredLanguage should return the textual representation
while getLocaleName should return the language tag.
That means I should revert the changes to getPreferredLanguage and make them to
getLocaleName() instead. This also means that WP8 and iOS will have to change
their implementation of getPreferredLanguage since they both return tags and
not string representations.
> getPreferredLanguage platform inconsistencies
> -
>
> Key: CB-4602
> URL: https://issues.apache.org/jira/browse/CB-4602
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, Plugin Globalization
>Affects Versions: 2.6.0, 3.0.0
> Environment: Android
>Reporter: Jon Whitlock
>Assignee: Mike Billau
>Priority: Minor
>
> In;
> https://github.com/apache/cordova-docs/blob/master/docs/en/edge/cordova/globalization/globalization.getPreferredLanguage.md
> "Returns the language identifier string to the successCallback with a
> properties object as a parameter. That object should have a value property
> with a String value."
> navigator.globalization.getPreferredLanguage(
>function (language) {alert('language: ' + language.value + '\n');},
>function () {alert('Error getting language\n');}
> );
> On Android the function doesn't seem to return an identifier as such, it
> returns *a string describing the language localised to that language*, e.g.
> "English" for English or "中文" for Japanese. Naturally this is less than ideal
> for subsequent string operations, furthermore on that page "Windows Phone 8
> Quirks - Returns the ISO 639-1 two-letter code for the current language"
> which is an identifier, and also what I would expect (or an ISO 639-2 code,
> as per http://www.loc.gov/standards/iso639-2/php/code_list.php)
> Android seems to support 639-2
> http://developer.android.com/reference/java/util/Locale.html#getISO3Language()
> I have no idea what it returns on other platforms, but to keep client code
> consistent I guess it would good if this could be normalised in the API.
> Have tested this on v3.0 and 2.6, is the same.
> As an aside, the locale is not really what I want here, as the user may be in
> the US but have Japanese as their preferred language.
> Thanks,
> jon
> (first go at using Jira, apols if I got something wrong!)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-4602) getPreferredLanguage platform inconsistencies
[
https://issues.apache.org/jira/browse/CB-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13984437#comment-13984437
]
Mike Billau commented on CB-4602:
-
I made some changes to the implementation above. I found out that Java 7
implements a method called Locale#toLanguageTag(), so I followed that as much
as possible. I pushed up a new branch to the globalization plugin because there
are a few other changes that we are in the process of making, so we will just
commit to that branch and then bump the major version once.
https://github.com/apache/cordova-plugin-globalization/commit/baea8a295daebdb6cc2bfcdcb612d6c988a8e08a
Somehow git reverted some of the previous changes (changing new Long() to
Long.valueOf), so I'll figure out why and fix that.
> getPreferredLanguage platform inconsistencies
> -
>
> Key: CB-4602
> URL: https://issues.apache.org/jira/browse/CB-4602
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, Plugin Globalization
>Affects Versions: 2.6.0, 3.0.0
> Environment: Android
>Reporter: Jon Whitlock
>Assignee: Mike Billau
>Priority: Minor
>
> In;
> https://github.com/apache/cordova-docs/blob/master/docs/en/edge/cordova/globalization/globalization.getPreferredLanguage.md
> "Returns the language identifier string to the successCallback with a
> properties object as a parameter. That object should have a value property
> with a String value."
> navigator.globalization.getPreferredLanguage(
>function (language) {alert('language: ' + language.value + '\n');},
>function () {alert('Error getting language\n');}
> );
> On Android the function doesn't seem to return an identifier as such, it
> returns *a string describing the language localised to that language*, e.g.
> "English" for English or "中文" for Japanese. Naturally this is less than ideal
> for subsequent string operations, furthermore on that page "Windows Phone 8
> Quirks - Returns the ISO 639-1 two-letter code for the current language"
> which is an identifier, and also what I would expect (or an ISO 639-2 code,
> as per http://www.loc.gov/standards/iso639-2/php/code_list.php)
> Android seems to support 639-2
> http://developer.android.com/reference/java/util/Locale.html#getISO3Language()
> I have no idea what it returns on other platforms, but to keep client code
> consistent I guess it would good if this could be normalised in the API.
> Have tested this on v3.0 and 2.6, is the same.
> As an aside, the locale is not really what I want here, as the user may be in
> the US but have Japanese as their preferred language.
> Thanks,
> jon
> (first go at using Jira, apols if I got something wrong!)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-4602) getPreferredLanguage platform inconsistencies
[
https://issues.apache.org/jira/browse/CB-4602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979803#comment-13979803
]
Mike Billau commented on CB-4602:
-
According to http://docs.oracle.com/javase/7/docs/api/java/util/Locale.html,
the Locale object "implements identifiers interchangeable with BCP 47." This
means that for Android, we can simply return `Locale.getDefault()` and it
should be BCP47 compliant. I tried this:
locale = "SIMPLIFIED_CHINESE", getDefault = zh_CN
locale = "CHINESE", getDefault = zh
locale = "TAIWAN", getDefault = zh_TW
locale= "English", getDefault = en_US
These results match up with what [~pdardailler] mentioned above, execpt for the
underscore instead of the dash. I'm not sure why "CHINESE" locale only returned
"zh." There also might be issues since according to
http://developer.android.com/reference/java/util/Locale.html, "Java uses
several deprecated two-letter codes. The Hebrew ("he") language code is
rewritten as "iw", Indonesian ("id") as "in", and Yiddish ("yi") as "ji". This
rewriting happens even if you construct your own Locale object, not just for
instances returned by the various lookup methods. "
Finally, since this is changing the return value of an API, we should probably
create a new method, like getPreferredLanguageCode() or something, instead of
just changing getPreferredLanguage().
> getPreferredLanguage platform inconsistencies
> -
>
> Key: CB-4602
> URL: https://issues.apache.org/jira/browse/CB-4602
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, Plugin Globalization
>Affects Versions: 2.6.0, 3.0.0
> Environment: Android
>Reporter: Jon Whitlock
>Assignee: Martin Gonzalez
>Priority: Minor
>
> In;
> https://github.com/apache/cordova-docs/blob/master/docs/en/edge/cordova/globalization/globalization.getPreferredLanguage.md
> "Returns the language identifier string to the successCallback with a
> properties object as a parameter. That object should have a value property
> with a String value."
> navigator.globalization.getPreferredLanguage(
>function (language) {alert('language: ' + language.value + '\n');},
>function () {alert('Error getting language\n');}
> );
> On Android the function doesn't seem to return an identifier as such, it
> returns *a string describing the language localised to that language*, e.g.
> "English" for English or "中文" for Japanese. Naturally this is less than ideal
> for subsequent string operations, furthermore on that page "Windows Phone 8
> Quirks - Returns the ISO 639-1 two-letter code for the current language"
> which is an identifier, and also what I would expect (or an ISO 639-2 code,
> as per http://www.loc.gov/standards/iso639-2/php/code_list.php)
> Android seems to support 639-2
> http://developer.android.com/reference/java/util/Locale.html#getISO3Language()
> I have no idea what it returns on other platforms, but to keep client code
> consistent I guess it would good if this could be normalised in the API.
> Have tested this on v3.0 and 2.6, is the same.
> As an aside, the locale is not really what I want here, as the user may be in
> the US but have Japanese as their preferred language.
> Thanks,
> jon
> (first go at using Jira, apols if I got something wrong!)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CB-6466) WP8 filetransfer.download() should auto mkdir missing folders
Mike Billau created CB-6466: --- Summary: WP8 filetransfer.download() should auto mkdir missing folders Key: CB-6466 URL: https://issues.apache.org/jira/browse/CB-6466 Project: Apache Cordova Issue Type: Bug Components: Plugin File Transfer, WP8 Affects Versions: 3.4.0 Reporter: Mike Billau Assignee: Jesse MacFadyen Windows Phone 8 implementation of FileTransfer.download() does not automatically create any missing directories when saving a file. The iOS and Android implementations do. If target = /foo/bar.jpg and /foo/ doesn't exist, WP8 should create it to bring the platform in line with iOS and Android. This mail thread shows that we've decided that FileTransfer should be "slightly more than" a thin wrapper on the File plugin (which has an API.) http://markmail.org/message/cxy66pe23oyguoal -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-4096) Android - Unify Whitelist Implemenations
[ https://issues.apache.org/jira/browse/CB-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13941840#comment-13941840 ] Mike Billau commented on CB-4096: - [~iclelland], yes that was the thread I was reading but somehow missed Andrew's argument against using subdomains attribute. Fail. I didn't realize that the attribute was never documented, I assumed that since it was in the instructions for setting up mobile-spec that it'd be in the Whitelist guide, but the only mention of it in the official docs seems to be under the Blackberry section. In light of this I agree, we should axe the subdomains=true attribute. Since it hasn't been documented, I think it's fine to completely take it out instead of belatedly deprecating. I'll withdrawal my pull request -- thanks a lot for the comments anyway. > Android - Unify Whitelist Implemenations > > > Key: CB-4096 > URL: https://issues.apache.org/jira/browse/CB-4096 > Project: Apache Cordova > Issue Type: Sub-task > Components: Android >Affects Versions: 3.0.0 >Reporter: Andrew Grieve >Assignee: Ian Clelland > Fix For: 3.1.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-4096) Android - Unify Whitelist Implemenations
[ https://issues.apache.org/jira/browse/CB-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940819#comment-13940819 ] Mike Billau commented on CB-4096: - https://github.com/apache/cordova-android/pull/95 I can merge this in myself if nobody comments in the next few days. > Android - Unify Whitelist Implemenations > > > Key: CB-4096 > URL: https://issues.apache.org/jira/browse/CB-4096 > Project: Apache Cordova > Issue Type: Sub-task > Components: Android >Affects Versions: 3.0.0 >Reporter: Andrew Grieve >Assignee: Ian Clelland > Fix For: 3.1.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-4096) Android - Unify Whitelist Implemenations
[
https://issues.apache.org/jira/browse/CB-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13940696#comment-13940696
]
Mike Billau commented on CB-4096:
-
[~iclelland], what are the plans for the 'subdomains="true"' flag? There was
nothing in the ML thread. The android code still parses out this attribute from
the XML and passes the flag around to all of the whitelist methods, it just
never utilizes it. It seems trivial to add code in
https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/Whitelist.java#L139
like this:
{code}
if( subdomains ){
if( scheme == null) scheme = "";
String sub = scheme + "*." + host; // generate *.host subdomain
addWhiteListEntry(sub, false);
}
{code}
This would ensure back-compatibility for anyone still using the subdomains
flag. I think we might as well use this since so much of the code still passes
around the subdomain flag. We could add a deprecation notice here.
> Android - Unify Whitelist Implemenations
>
>
> Key: CB-4096
> URL: https://issues.apache.org/jira/browse/CB-4096
> Project: Apache Cordova
> Issue Type: Sub-task
> Components: Android
>Affects Versions: 3.0.0
>Reporter: Andrew Grieve
>Assignee: Ian Clelland
> Fix For: 3.1.0
>
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CB-6311) Document developer-centeric CLI commands
Mike Billau created CB-6311: --- Summary: Document developer-centeric CLI commands Key: CB-6311 URL: https://issues.apache.org/jira/browse/CB-6311 Project: Apache Cordova Issue Type: Bug Components: CLI, Docs Affects Versions: 3.4.0 Reporter: Mike Billau Assignee: Mike Billau Priority: Minor There are a few CLI commands and parameters that are only useful for cordova developers and are thus not documented on our main docs site. It would be nice to document this information in the Cordova wiki. Some topics: Platform-specific preferences: http://markmail.org/thread/7kalpsmw7rcvsbo7 Creating myProject/.cordova/config.json to specify where the platforms should be installed from: https://github.com/apache/cordova-mobile-spec/blob/master/createmobilespec.sh#L57 Parameters in create, like --link-to: https://github.com/apache/cordova-mobile-spec/blob/master/createmobilespec.sh#L43 I'm sure there are others out there... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-5175) Fix core plugins that incorrectly run on main thread
[ https://issues.apache.org/jira/browse/CB-5175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13913522#comment-13913522 ] Mike Billau commented on CB-5175: - Started working on this, I'm just planning on going down the list of plugins as they appear in mobile spec. If somebody can give this a spot check, I'd appreciate it: https://github.com/mbillau/cordova-plugin-device-motion/commit/1cb25b6a8f7ca2e6bd0e5bb23d8838db3df0719c > Fix core plugins that incorrectly run on main thread > > > Key: CB-5175 > URL: https://issues.apache.org/jira/browse/CB-5175 > Project: Apache Cordova > Issue Type: Bug > Components: Docs, Plugin Device Orientation, Plugin File, Plugin > Media >Reporter: Mike Billau >Assignee: Mike Billau >Priority: Minor > > After CB-4133 we are able to detect and log when a plugin incorrectly does > work on the UI thread instead of a worker thread. We should go back and > verify that all of our plugins follow this practice - eat your own dogfood > type of thing. > We know there are problems with: > Android: file, compass > iOS: media > Docs: Need to verify plugin author guide is still valid -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CB-5175) Fix core plugins that incorrectly run on main thread
[ https://issues.apache.org/jira/browse/CB-5175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau reassigned CB-5175: --- Assignee: Mike Billau > Fix core plugins that incorrectly run on main thread > > > Key: CB-5175 > URL: https://issues.apache.org/jira/browse/CB-5175 > Project: Apache Cordova > Issue Type: Bug > Components: Docs, Plugin Device Orientation, Plugin File, Plugin > Media >Reporter: Mike Billau >Assignee: Mike Billau >Priority: Minor > > After CB-4133 we are able to detect and log when a plugin incorrectly does > work on the UI thread instead of a worker thread. We should go back and > verify that all of our plugins follow this practice - eat your own dogfood > type of thing. > We know there are problems with: > Android: file, compass > iOS: media > Docs: Need to verify plugin author guide is still valid -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5398) Pick image from Library or Photo album on android 4.4
[ https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13901804#comment-13901804 ] Mike Billau commented on CB-5398: - Thanks for looking at this! I've been testing the update and it all seems good, I can access images from any source now, no matter what I set the destination_type to. I did see that sometimes pulling an image from Drive with data_url will cause the app to quit with an Out Of Memory error, even when the same image can be opened with destination_type=file_uri. I can't reproduce this reliably though, I think it might be the known issue of the Camera app shutting down. > Pick image from Library or Photo album on android 4.4 > - > > Key: CB-5398 > URL: https://issues.apache.org/jira/browse/CB-5398 > Project: Apache Cordova > Issue Type: Bug > Components: Android, Plugin Camera >Affects Versions: 2.9.0, 3.2.0 > Environment: android 4.4 >Reporter: julio cesar >Assignee: Mike Billau > Fix For: 3.5.0 > > > An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or > pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI. > Now android 4.4, when you select the above options, it opens an "open from" > dialog that let you choose from new places as "Recent", "Drive", "Images" > and "Downloads" (the names might not be the same as I use the device in > spanish and translated it). > If you choose any of them, you get an error, AndroidProtocolHandler, unable > to open content URL: the url here with a content://com.android.providers > format. > I've tested on phonegap 2.9 because this is the version I use, but I suppose > it affects all of them. (in fact I use 2.9.1) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5202) Android Video Capture crashes app on 4.3
[ https://issues.apache.org/jira/browse/CB-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13900560#comment-13900560 ] Mike Billau commented on CB-5202: - Well I pushed in a fix to the dev branch, so marking resolved for 3.5.0 since that's when you would expect to see it without checking out the dev plugin branch. [~emmam] if you can still reproduce it feel free to open this back up. > Android Video Capture crashes app on 4.3 > > > Key: CB-5202 > URL: https://issues.apache.org/jira/browse/CB-5202 > Project: Apache Cordova > Issue Type: Bug > Components: Android, Plugin Media Capture >Affects Versions: 3.0.0 > Environment: Android 4.3 >Reporter: Tom Saunders >Assignee: Andrew Grieve > Fix For: 3.5.0 > > > Using the cordova video capture plugin crashes the application when returning > from the capture video intent. No data is returned. > This is a known issue with Android 4.3, the workaround is to explicitly > specify a location for saving the video > Relevant stackoverflows: > http://stackoverflow.com/questions/18472953/video-capture-in-android-4-3-using-camera-app-intent > http://stackoverflow.com/questions/18120775/android-android-provider-mediastore-action-video-capture-return-null-onactivityr -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CB-5202) Android Video Capture crashes app on 4.3
[ https://issues.apache.org/jira/browse/CB-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau closed CB-5202. --- Resolution: Fixed Fix Version/s: 3.5.0 > Android Video Capture crashes app on 4.3 > > > Key: CB-5202 > URL: https://issues.apache.org/jira/browse/CB-5202 > Project: Apache Cordova > Issue Type: Bug > Components: Android, Plugin Media Capture >Affects Versions: 3.0.0 > Environment: Android 4.3 >Reporter: Tom Saunders >Assignee: Andrew Grieve > Fix For: 3.5.0 > > > Using the cordova video capture plugin crashes the application when returning > from the capture video intent. No data is returned. > This is a known issue with Android 4.3, the workaround is to explicitly > specify a location for saving the video > Relevant stackoverflows: > http://stackoverflow.com/questions/18472953/video-capture-in-android-4-3-using-camera-app-intent > http://stackoverflow.com/questions/18120775/android-android-provider-mediastore-action-video-capture-return-null-onactivityr -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5202) Android Video Capture crashes app on 4.3
[ https://issues.apache.org/jira/browse/CB-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13899338#comment-13899338 ] Mike Billau commented on CB-5202: - New PR: https://github.com/apache/cordova-plugin-media-capture/pull/13 [~emmam] I don't have a i9250, would be interested to know if the above pull request fixes your issue as well. > Android Video Capture crashes app on 4.3 > > > Key: CB-5202 > URL: https://issues.apache.org/jira/browse/CB-5202 > Project: Apache Cordova > Issue Type: Bug > Components: Android, Plugin Media Capture >Affects Versions: 3.0.0 > Environment: Android 4.3 >Reporter: Tom Saunders >Assignee: Andrew Grieve > > Using the cordova video capture plugin crashes the application when returning > from the capture video intent. No data is returned. > This is a known issue with Android 4.3, the workaround is to explicitly > specify a location for saving the video > Relevant stackoverflows: > http://stackoverflow.com/questions/18472953/video-capture-in-android-4-3-using-camera-app-intent > http://stackoverflow.com/questions/18120775/android-android-provider-mediastore-action-video-capture-return-null-onactivityr -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5294) File input element not opening file picker in Android 4.4
[ https://issues.apache.org/jira/browse/CB-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13898217#comment-13898217 ] Mike Billau commented on CB-5294: - I've added a note to the Platform Upgrade Guide about this bug (it's kinda weird, we don't list Android platform-wide quirks anywhere so the Upgrade Guide seemed like a decent enough place to stick it.) Lets keep this ticket open so that every Android update we can check to see if this has been resolved, and if so, remove the quirk. > File input element not opening file picker in Android 4.4 > - > > Key: CB-5294 > URL: https://issues.apache.org/jira/browse/CB-5294 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 3.1.0 > Environment: Android 4.4 (emulator and Nexus 5) >Reporter: Paul Kane >Assignee: Joe Bowser > > The file input field doesn't respond when clicked/tapped in Android 4.4. > Works fine in previous Android versions. This is regardless of whether the > Target Level is set to 18 or 19. > To reproduce, I created a fresh Cordova 3.1.0 project for Android. The only > modification I made to the default (placeholder) index.html file was adding a > element with a single element inside. Clicking the > "Choose File" button does nothing. No Logcat output or errors. Normally at > this point a dialogue would open allowing me to select an image from the > gallery or take a picture, which is what happens in older Android versions. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CB-5977) Deprecate Android Geolocation plugin
Mike Billau created CB-5977: --- Summary: Deprecate Android Geolocation plugin Key: CB-5977 URL: https://issues.apache.org/jira/browse/CB-5977 Project: Apache Cordova Issue Type: Bug Components: Android, Plugin Geolocation Reporter: Mike Billau Lets deprecate the Geolocation plugin on Android since the Web Geolocation works just as well as our implementation. See http://markmail.org/message/ketdgrzm2dcpxfo2 for further discussion. We need to keep the config.xml in order to continue adding the location permissions. We should zero out the rest of the code since it shouldn't be used. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5202) Android Video Capture crashes app on 4.3
[ https://issues.apache.org/jira/browse/CB-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13886908#comment-13886908 ] Mike Billau commented on CB-5202: - I implemented a stripped down version of the pull request and it works great to fix the issue with 4.3. https://github.com/mbillau/cordova-plugin-media-capture/commit/8edfa3aea2906cd904ebc881cc822c14b8186411 Should I make a PR? If the original fix is from "lubogospod" do we first have to make sure he or she has signed the CLA? > Android Video Capture crashes app on 4.3 > > > Key: CB-5202 > URL: https://issues.apache.org/jira/browse/CB-5202 > Project: Apache Cordova > Issue Type: Bug > Components: Android, Plugin Media Capture >Affects Versions: 3.0.0 > Environment: Android 4.3 >Reporter: Tom Saunders >Assignee: Andrew Grieve > > Using the cordova video capture plugin crashes the application when returning > from the capture video intent. No data is returned. > This is a known issue with Android 4.3, the workaround is to explicitly > specify a location for saving the video > Relevant stackoverflows: > http://stackoverflow.com/questions/18472953/video-capture-in-android-4-3-using-camera-app-intent > http://stackoverflow.com/questions/18120775/android-android-provider-mediastore-action-video-capture-return-null-onactivityr -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5398) Pick image from Library or Photo album on android 4.4
[ https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13873646#comment-13873646 ] Mike Billau commented on CB-5398: - I'm trying to figure out where in Android there is a URI encoding bug so that we can report it and have the problem fixed upstream. However, I'm starting to think maybe we need to make some changes to incorporate the new Storage Access Framework...more specifically, checking different ContentProviders. I was able to implement the solution here: http://stackoverflow.com/a/20559175/368762 and it seems to work well for accessing images from all of the providers except for Drive. The new way of doing things seems to craft the URI based on which provider the data came from instead of just assuming uri = intent.getData() will be valid. > Pick image from Library or Photo album on android 4.4 > - > > Key: CB-5398 > URL: https://issues.apache.org/jira/browse/CB-5398 > Project: Apache Cordova > Issue Type: Bug > Components: Android, Plugin Camera >Affects Versions: 2.9.0, 3.2.0 > Environment: android 4.4 >Reporter: julio cesar >Assignee: Mike Billau > > An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or > pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI. > Now android 4.4, when you select the above options, it opens an "open from" > dialog that let you choose from new places as "Recent", "Drive", "Images" > and "Downloads" (the names might not be the same as I use the device in > spanish and translated it). > If you choose any of them, you get an error, AndroidProtocolHandler, unable > to open content URL: the url here with a content://com.android.providers > format. > I've tested on phonegap 2.9 because this is the version I use, but I suppose > it affects all of them. (in fact I use 2.9.1) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5398) Pick image from Library or Photo album on android 4.4
[ https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13871092#comment-13871092 ] Mike Billau commented on CB-5398: - [~bowserj], can you please explain how you were able to determine that the first URI "has the READ permission passed back to it"? I couldn't find a bug report for this on the Android tracker and would like to file it but I'm not sure if I understand enough to actually file a decent bug report. > Pick image from Library or Photo album on android 4.4 > - > > Key: CB-5398 > URL: https://issues.apache.org/jira/browse/CB-5398 > Project: Apache Cordova > Issue Type: Bug > Components: Android, Plugin Camera >Affects Versions: 2.9.0, 3.2.0 > Environment: android 4.4 >Reporter: julio cesar >Assignee: Mike Billau > > An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or > pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI. > Now android 4.4, when you select the above options, it opens an "open from" > dialog that let you choose from new places as "Recent", "Drive", "Images" > and "Downloads" (the names might not be the same as I use the device in > spanish and translated it). > If you choose any of them, you get an error, AndroidProtocolHandler, unable > to open content URL: the url here with a content://com.android.providers > format. > I've tested on phonegap 2.9 because this is the version I use, but I suppose > it affects all of them. (in fact I use 2.9.1) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CB-5232) Make android include CordovaLib as a library instead of a Jar
[ https://issues.apache.org/jira/browse/CB-5232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13851823#comment-13851823 ] Mike Billau commented on CB-5232: - https://github.com/apache/cordova-docs/pull/166 > Make android include CordovaLib as a library instead of a Jar > - > > Key: CB-5232 > URL: https://issues.apache.org/jira/browse/CB-5232 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Reporter: Andrew Grieve >Assignee: Andrew Grieve >Priority: Minor > > Motivation: > -Works better in IntelliJ > -Faster project creation > -Consistent with iOS approach > -Allows users to step into framework code when debugging > Proof of concept is checked in at cordova-android's "libproject" branch. > Let's wait until the 3.2.0 branch is created before merging. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CB-5232) Make android include CordovaLib as a library instead of a Jar
[ https://issues.apache.org/jira/browse/CB-5232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13851781#comment-13851781 ] Mike Billau commented on CB-5232: - Hey [~agrieve], after this change, when users import the project into Eclipse, they are now seeing "HelloWorld" and "HelloWorld-CordovaLibs" as options to import. Both need to be imported into Eclipse in order to resolve the Eclipse dependencies. We should add a note about this here: http://cordova.apache.org/docs/en/3.3.0/guide_platforms_android_index.md.html#Android%20Platform%20Guide I think that's the only place that needs the update. > Make android include CordovaLib as a library instead of a Jar > - > > Key: CB-5232 > URL: https://issues.apache.org/jira/browse/CB-5232 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Reporter: Andrew Grieve >Assignee: Andrew Grieve >Priority: Minor > > Motivation: > -Works better in IntelliJ > -Faster project creation > -Consistent with iOS approach > -Allows users to step into framework code when debugging > Proof of concept is checked in at cordova-android's "libproject" branch. > Let's wait until the 3.2.0 branch is created before merging. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CB-5398) Pick image from Library or Photo album on android 4.4
[ https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13850761#comment-13850761 ] Mike Billau commented on CB-5398: - Still broken in 4.4.2. Should we file a bug against Android since this is a URI encoding bug and pretty different than the one posted earlier in the thread? > Pick image from Library or Photo album on android 4.4 > - > > Key: CB-5398 > URL: https://issues.apache.org/jira/browse/CB-5398 > Project: Apache Cordova > Issue Type: Bug > Components: Android, Plugin Camera >Affects Versions: 2.9.0, 3.2.0 > Environment: android 4.4 >Reporter: julio cesar >Assignee: Mike Billau > > An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or > pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI. > Now android 4.4, when you select the above options, it opens an "open from" > dialog that let you choose from new places as "Recent", "Drive", "Images" > and "Downloads" (the names might not be the same as I use the device in > spanish and translated it). > If you choose any of them, you get an error, AndroidProtocolHandler, unable > to open content URL: the url here with a content://com.android.providers > format. > I've tested on phonegap 2.9 because this is the version I use, but I suppose > it affects all of them. (in fact I use 2.9.1) -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CB-4074) Error when adding android platform on Windows 7
[ https://issues.apache.org/jira/browse/CB-4074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13850693#comment-13850693 ] Mike Billau commented on CB-4074: - This has popped up on stackoverflow a few times, I think it started after adding q.js - or at least, q.js seems to be the first thing to try to call xcopy. Is this a problem only when using the CLI? If so, we can add a NOTE: section to the documentation on this page: http://cordova.apache.org/docs/en/3.3.0/guide_cli_index.md.html#The%20Command-Line%20Interface Similar to the note about adding the npm directory to your path if you install Cordova globally. If you need xcopy on the path regardless of whether you use the CLI or the native workflow, then I think it should be in check_reqs. Created https://issues.apache.org/jira/browse/CB-4286 to track. > Error when adding android platform on Windows 7 > --- > > Key: CB-4074 > URL: https://issues.apache.org/jira/browse/CB-4074 > Project: Apache Cordova > Issue Type: Bug > Components: CLI > Environment: Windows 7 >Reporter: Lisa Seacat DeLuca >Assignee: Filip Maj > > I got past the issue where I wasn't able to install cordova on my windows 7 > machine. I create a new project just fine but when I tried to add android as > a platform I see the following error: > C:\workspaces\cordovacli\helloworld>cordova platform add android > shell.js: internal error > Error: EPERM, operation not permitted > 'C:\Users\me\.cordova\lib\android\cordova\2.9.0\cordova-android-2.9.0-df1536e\test' > at Object.fs.renameSync (fs.js:543:18) > at > C:\Users\me\AppData\Roaming\npm\node_modules\cordova\node_modules\shelljs\shell.js:487:8 > at Array.forEach (native) > at Object._mv > (C:\Users\me\AppData\Roaming\npm\node_modules\cordova\node_modules\shelljs\shell.js:463:11) > at Object.mv > (C:\Users\me\AppData\Roaming\npm\node_modules\cordova\node_modules\shelljs\shell.js:1471:23) > at Extract. > (C:\Users\me\AppData\Roaming\npm\node_modules\cordova\src\lazy_load.js:115:43) > at Extract.EventEmitter.emit (events.js:117:20) > at DirWriter. > (C:\Users\me\AppData\Roaming\npm\node_modules\cordova\node_modules\tar\lib\extract.js:66:8) > at DirWriter.EventEmitter.emit (events.js:117:20) > at end > (C:\Users\me\AppData\Roaming\npm\node_modules\cordova\node_modules\tar\node_modules\fstream\lib\writer.js:323:12) > -- > note: I can use eclipse and create an android project with no problem and > test on devices and emulators. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (CB-5665) Document the need for xcopy on path
Mike Billau created CB-5665: --- Summary: Document the need for xcopy on path Key: CB-5665 URL: https://issues.apache.org/jira/browse/CB-5665 Project: Apache Cordova Issue Type: Bug Components: Android, Docs Environment: Windows Reporter: Mike Billau Priority: Minor Fix For: 3.4.0 On Windows, you need to have xcopy on the path when trying to build Android, otherwise it will fail. I think this maybe started when we switched to q.js See: https://issues.apache.org/jira/browse/CB-4074 and http://stackoverflow.com/questions/20616893/an-error-occured-during-creation-of-android-sub-project/20640450 If it is necessary only when you use the CLI, we can just add a note in the CLI documentation. If it is necessary regardless of which workflow you use, then I think it should be in check_reqs with a log message on the terminal to "Make sure xcopy is on your path." It's probably a Windows-specific thing, no? -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CB-5398) Pick image from Library or Photo album on android 4.4
[ https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13841440#comment-13841440 ] Mike Billau commented on CB-5398: - Pull request for the quick here: https://github.com/apache/cordova-docs/pull/163 > Pick image from Library or Photo album on android 4.4 > - > > Key: CB-5398 > URL: https://issues.apache.org/jira/browse/CB-5398 > Project: Apache Cordova > Issue Type: Bug > Components: Android, Plugin Camera >Affects Versions: 2.9.0, 3.2.0 > Environment: android 4.4 >Reporter: julio cesar >Assignee: Mike Billau > > An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or > pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI. > Now android 4.4, when you select the above options, it opens an "open from" > dialog that let you choose from new places as "Recent", "Drive", "Images" > and "Downloads" (the names might not be the same as I use the device in > spanish and translated it). > If you choose any of them, you get an error, AndroidProtocolHandler, unable > to open content URL: the url here with a content://com.android.providers > format. > I've tested on phonegap 2.9 because this is the version I use, but I suppose > it affects all of them. (in fact I use 2.9.1) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5398) Pick image from Library or Photo album on android 4.4
[ https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13841314#comment-13841314 ] Mike Billau commented on CB-5398: - I'm going to add a note under Android Quirks for getPicture() documenting this quirk for 4.4 and linking out to the stackoverflow post above as possible solutions. Sound good? When we resolve this we can remove the quirk in the documentation. Thanks guys for looking at this. Sorry I don't have anything to add yet but want to do more investigation today. > Pick image from Library or Photo album on android 4.4 > - > > Key: CB-5398 > URL: https://issues.apache.org/jira/browse/CB-5398 > Project: Apache Cordova > Issue Type: Bug > Components: Android, Plugin Camera >Affects Versions: 2.9.0, 3.2.0 > Environment: android 4.4 >Reporter: julio cesar >Assignee: Mike Billau > > An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or > pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI. > Now android 4.4, when you select the above options, it opens an "open from" > dialog that let you choose from new places as "Recent", "Drive", "Images" > and "Downloads" (the names might not be the same as I use the device in > spanish and translated it). > If you choose any of them, you get an error, AndroidProtocolHandler, unable > to open content URL: the url here with a content://com.android.providers > format. > I've tested on phonegap 2.9 because this is the version I use, but I suppose > it affects all of them. (in fact I use 2.9.1) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5398) Pick image from Library or Photo album on android 4.4
[ https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13839282#comment-13839282 ] Mike Billau commented on CB-5398: - I followed the suggestion here to force it to always open the Gallery app and that seemed to work as a temporary solution: http://stackoverflow.com/a/20177611/368762 [~agrieve], [~bowserj], what are the conditions for a ticket to be a blocker? This has workarounds but I don't think we should release a 3.3 "to fix android 4.4 issues" without resolving this. I didn't see CB-2432, thanks for pointing that out. > Pick image from Library or Photo album on android 4.4 > - > > Key: CB-5398 > URL: https://issues.apache.org/jira/browse/CB-5398 > Project: Apache Cordova > Issue Type: Bug > Components: Android, Plugin Camera >Affects Versions: 2.9.0, 3.2.0 > Environment: android 4.4 >Reporter: julio cesar >Assignee: Mike Billau > > An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or > pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI. > Now android 4.4, when you select the above options, it opens an "open from" > dialog that let you choose from new places as "Recent", "Drive", "Images" > and "Downloads" (the names might not be the same as I use the device in > spanish and translated it). > If you choose any of them, you get an error, AndroidProtocolHandler, unable > to open content URL: the url here with a content://com.android.providers > format. > I've tested on phonegap 2.9 because this is the version I use, but I suppose > it affects all of them. (in fact I use 2.9.1) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5488) deviceready event not firing with jQuery Mobile
[ https://issues.apache.org/jira/browse/CB-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13836674#comment-13836674 ] Mike Billau commented on CB-5488: - [~shazron], what order are the scripts tags in in the built application? I have seen this issue come up a few times on StackOverflow and iirc the problem always seems to be with putting jquery script tag first, before the cordova script. Do you have any idea why that would be? I will look into it this week - I don't think that the script tag order should matter, but if it does, we at least need to document it (and worst case, edit the shell scripts to make sure cordova tag is always first.) > deviceready event not firing with jQuery Mobile > --- > > Key: CB-5488 > URL: https://issues.apache.org/jira/browse/CB-5488 > Project: Apache Cordova > Issue Type: Bug >Affects Versions: 3.1.0 >Reporter: Federico Kereki > > If you use PhoneGap + jQuery + jQuery Mobile, the deviceready event doesn't > fire. Googling around, I found several similar reports, all pointing out that > if jQuery Mobile isn't included, the event fires. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5122) Document supported workflows
[
https://issues.apache.org/jira/browse/CB-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13830347#comment-13830347
]
Mike Billau commented on CB-5122:
-
I'm going to close this as it seems done after my first (painful) commit.
I opened up CB-5470 to track adding further details around the pros/cons of
each workflow. We haven't identified all of these issues yet so I'll go around
in the next few weeks and survey our developers and users and fill this
information out. It's not worth holding up this ticket though.
Thanks everyone who helped and contributed to the content!
> Document supported workflows
>
>
> Key: CB-5122
> URL: https://issues.apache.org/jira/browse/CB-5122
> Project: Apache Cordova
> Issue Type: Bug
> Components: Docs
>Affects Versions: 3.1.0
>Reporter: Mike Billau
>Assignee: Mike Sierra
>
> Based on the recent discussion here [1]we should document the two different
> supported Cordova workflows: using the CLI, and using plugman and bin
> scripts.
> Some of this documentation already exists but needs to be clarified and
> improved:
> {{Overview guide --> "Development Paths" section}}. This talks about getting
> started with the CLI and then mentions that you can switch to the
> platform-specific SDK tools. This section should be rewritten to make it
> clear that there are two distinct workflows, and that both are okay and
> supported. It could list out some pros and cons of each workflow (I'm sure we
> won't have any trouble finding those ;)). It should be prescriptive in that
> users should be following one of the two workflows, but it shouldn't make any
> statements about which is better.
> {{"The Command-line Interface" guide}} --> The "CLI workflow" guide. It
> generally looks complete except for some missing functionality that is
> documented in the CLI's README.md file (tests, hooks, some commands (serve),
> some merges info).
> {{Platform Guides --> (Platform) --> (Platform) Command-line tools}} --> Each
> platform has a "Command-line tools" doc that explains all of the command line
> tools for that project and how to use them. We need to go through these
> guides and verify that they are up to date and include all of the lower level
> command line tools and scripts. It should read like a tutorial in the same
> way that the Command-line Interface guide does.
> {{"Using Plugman to Manage Plugins"}} First, this guide needs to get exposed;
> I can't find any way to get to this guide from the docs and even had to ask a
> user how she managed to find it (a link from Plugman's readme!). This guide
> needs to be expanded quite a bit; we can probably fold most/all of Plugman's
> README.md file into this guide since it will be platform agnostic.
> I think those are the only pieces in the docs that need to be changed.
> [1] http://callback.markmail.org/thread/5nr7dgkquse4gdkl
> [2]
> http://cordova.apache.org/docs/en/edge/guide_overview_index.md.html#Overview
> [3] http://cordova.apache.org/docs/en/edge/plugin_ref_plugman.md.html
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (CB-5122) Document supported workflows
[
https://issues.apache.org/jira/browse/CB-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Billau resolved CB-5122.
-
Resolution: Fixed
> Document supported workflows
>
>
> Key: CB-5122
> URL: https://issues.apache.org/jira/browse/CB-5122
> Project: Apache Cordova
> Issue Type: Bug
> Components: Docs
>Affects Versions: 3.1.0
>Reporter: Mike Billau
>Assignee: Mike Sierra
>
> Based on the recent discussion here [1]we should document the two different
> supported Cordova workflows: using the CLI, and using plugman and bin
> scripts.
> Some of this documentation already exists but needs to be clarified and
> improved:
> {{Overview guide --> "Development Paths" section}}. This talks about getting
> started with the CLI and then mentions that you can switch to the
> platform-specific SDK tools. This section should be rewritten to make it
> clear that there are two distinct workflows, and that both are okay and
> supported. It could list out some pros and cons of each workflow (I'm sure we
> won't have any trouble finding those ;)). It should be prescriptive in that
> users should be following one of the two workflows, but it shouldn't make any
> statements about which is better.
> {{"The Command-line Interface" guide}} --> The "CLI workflow" guide. It
> generally looks complete except for some missing functionality that is
> documented in the CLI's README.md file (tests, hooks, some commands (serve),
> some merges info).
> {{Platform Guides --> (Platform) --> (Platform) Command-line tools}} --> Each
> platform has a "Command-line tools" doc that explains all of the command line
> tools for that project and how to use them. We need to go through these
> guides and verify that they are up to date and include all of the lower level
> command line tools and scripts. It should read like a tutorial in the same
> way that the Command-line Interface guide does.
> {{"Using Plugman to Manage Plugins"}} First, this guide needs to get exposed;
> I can't find any way to get to this guide from the docs and even had to ask a
> user how she managed to find it (a link from Plugman's readme!). This guide
> needs to be expanded quite a bit; we can probably fold most/all of Plugman's
> README.md file into this guide since it will be platform agnostic.
> I think those are the only pieces in the docs that need to be changed.
> [1] http://callback.markmail.org/thread/5nr7dgkquse4gdkl
> [2]
> http://cordova.apache.org/docs/en/edge/guide_overview_index.md.html#Overview
> [3] http://cordova.apache.org/docs/en/edge/plugin_ref_plugman.md.html
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (CB-5470) Document differences between CLI and shell workflows
Mike Billau created CB-5470: --- Summary: Document differences between CLI and shell workflows Key: CB-5470 URL: https://issues.apache.org/jira/browse/CB-5470 Project: Apache Cordova Issue Type: Bug Components: Docs Affects Versions: Master Reporter: Mike Billau Assignee: Mike Billau Priority: Minor Fix For: 3.3.0 After CB-5122, we have documented the two different workflows, the CLI and the shell scripts. However, we should further document the advantages and disadvantages to each workflow. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CB-5469) Document how to run npm without sudo
Mike Billau created CB-5469: --- Summary: Document how to run npm without sudo Key: CB-5469 URL: https://issues.apache.org/jira/browse/CB-5469 Project: Apache Cordova Issue Type: Bug Components: Docs Reporter: Mike Billau Assignee: Mike Billau Priority: Minor Fix For: 3.2.0 We ask users to install npm globally. Whether or not we are going to continue to suggest this is a different debate, but in the mean time we should talk about how they can set up npm to run without requiring sudo/Administrator. There is a wiki page here that talks about it: https://wiki.apache.org/cordova/npm_rc We need to build out this wiki page and then link to it in the docs. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5294) File input element not opening file picker in Android 4.4
[ https://issues.apache.org/jira/browse/CB-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13826937#comment-13826937 ] Mike Billau commented on CB-5294: - [~agrieve], it doesn't look like they are paying attention to the android issues list above. Are you seeing this getting more attention somewhere else? I'd just like to follow the progress. > File input element not opening file picker in Android 4.4 > - > > Key: CB-5294 > URL: https://issues.apache.org/jira/browse/CB-5294 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 3.1.0 > Environment: Android 4.4 (emulator and Nexus 5) >Reporter: Paul Kane >Assignee: Joe Bowser > > The file input field doesn't respond when clicked/tapped in Android 4.4. > Works fine in previous Android versions. This is regardless of whether the > Target Level is set to 18 or 19. > To reproduce, I created a fresh Cordova 3.1.0 project for Android. The only > modification I made to the default (placeholder) index.html file was adding a > element with a single element inside. Clicking the > "Choose File" button does nothing. No Logcat output or errors. Normally at > this point a dialogue would open allowing me to select an image from the > gallery or take a picture, which is what happens in older Android versions. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5398) Pick image from Library or Photo album on android 4.4
[ https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13826678#comment-13826678 ] Mike Billau commented on CB-5398: - 2012 Nexus 7 running KitKat installed from https://developers.google.com/android/nexus/images#nakasikrt16o Seeing the same thing as [~jcesarmobile] 1. everything works when destinationType = DATA_URL 2. With destinationType = FILE_URI, I can get images from "Downloads", but any other file picker will return to the app but the image does not appear. 3. With destinationType = FILE_URI, I can successfully access any image if I go through the "Gallery" app first 4. I get the same logcat message (posted above) whenever it unsuccessfully returns to mobilespec after trying to get a picture from Recent, Drive, Images, or External Storage. > Pick image from Library or Photo album on android 4.4 > - > > Key: CB-5398 > URL: https://issues.apache.org/jira/browse/CB-5398 > Project: Apache Cordova > Issue Type: Bug > Components: Android, Plugin Camera >Affects Versions: 2.9.0, 3.2.0 > Environment: android 4.4 >Reporter: julio cesar >Assignee: Mike Billau > > An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or > pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI. > Now android 4.4, when you select the above options, it opens an "open from" > dialog that let you choose from new places as "Recent", "Drive", "Images" > and "Downloads" (the names might not be the same as I use the device in > spanish and translated it). > If you choose any of them, you get an error, AndroidProtocolHandler, unable > to open content URL: the url here with a content://com.android.providers > format. > I've tested on phonegap 2.9 because this is the version I use, but I suppose > it affects all of them. (in fact I use 2.9.1) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5427) InAppBrowser crashes without loadstop or loaderror on Android 4.4
[
https://issues.apache.org/jira/browse/CB-5427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13826667#comment-13826667
]
Mike Billau commented on CB-5427:
-
Originally I reported this while testing on an actual build on a new Nexus 5
phone.
I just installed the 4.4 ROM (NAKASI-KRT16o) on my Nexus 7 and am getting both
errors.
1) Sometimes you see "Alert: Unexpected: browser closed without a loadstop or
loadstart error". I can reproduce it almost every time now by 1) open a page
in InAppBrowser, 2) hit back 3) open a page in CordovaWebView 4) see dialog.
Sometimes it will work fine but following this pattern triggers the error
pretty consistently on both of my devices.
If you dismiss the alert, the app seems fine, there isn't a nasty stack trace
or anything. This occurs on both Nexus 5 and Nexus 7, both running the latest
Android 4.4 (from Google.) It seems to happen slightly more consistently on
the Nexus 5 phone.
2) If you do not hit okay when the alert pops up and let it wait, eventually
you will get a {noformat}
11-19 11:38:41.867: E/CordovaWebView(7121): CordovaWebView: TIMEOUT
ERROR!{noformat}
error, a dialog about not being able to connect to the server, that nasty stack
trace above about the "window leaked". The app will force quit (but still say
in the app list..?) and if you launch the app again (either from the launcher
or from the recently used/running apps screen) the webview will stay black and
nothing happens until you quit the app and restart. (Cordova seems present when
this black screen is here because you can see {noformat}11-19 11:43:23.997:
I/CordovaLog(7665): Found start page location: index.html
11-19 11:43:23.997: I/CordovaLog(7665): Changing log level to DEBUG(3)
11-19 11:43:24.007: D/CordovaActivity(7665): CordovaActivity.onCreate()
11-19 11:43:24.017: D/CordovaWebView(7665): CordovaWebView is running on device
made by: asus
11-19 11:43:24.027: D/JsMessageQueue(7665): Set native->JS mode to 2
11-19 11:43:24.027: D/CordovaActivity(7665): CordovaActivity.init()
11-19 11:43:24.037: D/CordovaWebView(7665): >>>
loadUrl(file:///android_asset/www/index.html)
11-19 11:43:24.037: D/PluginManager(7665): init()
11-19 11:43:24.057: D/CordovaWebView(7665): >>> loadUrlNow()
{noformat}
I think we can probably ignore this second error for now since it's hard to
tell if that is being caused by the first error or not.
> InAppBrowser crashes without loadstop or loaderror on Android 4.4
> -
>
> Key: CB-5427
> URL: https://issues.apache.org/jira/browse/CB-5427
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, Plugin InAppBrowser
>Affects Versions: 3.2.0
> Environment: Windows 7
> Android 4.x
>Reporter: Mike Billau
>
> InAppBrowser on Android 4.4 sometimes fails when you click to open any page
> on the CordovaWebView. An alert will pop up saying "Unexpected: Browser
> closed without a loadstop or loaderror." Closing the dialog will force quit
> the application. I can't detect a pattern to reproduce the issue; what I do
> is just keep running through the first few buttons under Local URL and White
> Listed URL headings on the mobile spec page. Other people seem to be having
> this issue too: https://groups.google.com/forum/#!topic/phonegap/e5_5unC2fYs
> In logcat I'm seeing:
> {noformat}
> 11-18 11:50:07.648: D/CordovaLog(6369):
> file:///android_asset/www/inappbrowser/index.html: Line 79 : IAB
> event={"type":"loadstop","url":"http://www.google.com/"}
> 11-18 11:50:07.648: I/chromium(6369): [INFO:CONSOLE(79)] "IAB
> event={"type":"loadstop","url":"http://www.google.com/"}";, source:
> file:///android_asset/www/inappbrowser/index.html (79)
> 11-18 11:50:07.928: W/UnimplementedWebViewApi(6369): Unimplemented WebView
> method onKeyDown called from:
> android.webkit.WebView.onKeyDown(WebView.java:2169)
> 11-18 11:50:07.968: W/InputEventReceiver(6369): Attempted to finish an input
> event but the input event receiver has already been disposed.
> 11-18 11:50:07.998: D/CordovaLog(6369):
> file:///android_asset/www/inappbrowser/index.html: Line 79 : IAB
> event={"type":"exit"}
> 11-18 11:50:07.998: I/chromium(6369): [INFO:CONSOLE(79)] "IAB
> event={"type":"exit"}", source:
> file:///android_asset/www/inappbrowser/index.html (79)
> 11-18 11:50:09.408: D/InAppBrowser(6369): target = _self
> 11-18 11:50:09.418: D/InAppBrowser(6369): in self
> 11-18 11:50:09.418: D/CordovaWebView(6369): >>> loadUrl(http://www.apple.com/)
> 11-18 11:50:09.418: D/PluginManager(6369): init()
> 11-18 11:50:09.428: D/CordovaWebView(6369): >>> loadUrlNow()
> 11-18 11:50:09.428: W/CordovaPlugin(6369): Attempted to send a second
> callback for ID: InAppBrowser921848427
> 11-18 11:50:09.428: W/CordovaPlugin(6369): Result was: ""
> 11-18
[jira] [Updated] (CB-5427) InAppBrowser crashes without loadstop or loaderror on Android 4.4
[
https://issues.apache.org/jira/browse/CB-5427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Billau updated CB-5427:
Environment:
Windows 7
Android 4.x
was:
Windows 7
Android 4.4
> InAppBrowser crashes without loadstop or loaderror on Android 4.4
> -
>
> Key: CB-5427
> URL: https://issues.apache.org/jira/browse/CB-5427
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, Plugin InAppBrowser
>Affects Versions: 3.2.0
> Environment: Windows 7
> Android 4.x
>Reporter: Mike Billau
>
> InAppBrowser on Android 4.4 sometimes fails when you click to open any page
> on the CordovaWebView. An alert will pop up saying "Unexpected: Browser
> closed without a loadstop or loaderror." Closing the dialog will force quit
> the application. I can't detect a pattern to reproduce the issue; what I do
> is just keep running through the first few buttons under Local URL and White
> Listed URL headings on the mobile spec page. Other people seem to be having
> this issue too: https://groups.google.com/forum/#!topic/phonegap/e5_5unC2fYs
> In logcat I'm seeing:
> {noformat}
> 11-18 11:50:07.648: D/CordovaLog(6369):
> file:///android_asset/www/inappbrowser/index.html: Line 79 : IAB
> event={"type":"loadstop","url":"http://www.google.com/"}
> 11-18 11:50:07.648: I/chromium(6369): [INFO:CONSOLE(79)] "IAB
> event={"type":"loadstop","url":"http://www.google.com/"}";, source:
> file:///android_asset/www/inappbrowser/index.html (79)
> 11-18 11:50:07.928: W/UnimplementedWebViewApi(6369): Unimplemented WebView
> method onKeyDown called from:
> android.webkit.WebView.onKeyDown(WebView.java:2169)
> 11-18 11:50:07.968: W/InputEventReceiver(6369): Attempted to finish an input
> event but the input event receiver has already been disposed.
> 11-18 11:50:07.998: D/CordovaLog(6369):
> file:///android_asset/www/inappbrowser/index.html: Line 79 : IAB
> event={"type":"exit"}
> 11-18 11:50:07.998: I/chromium(6369): [INFO:CONSOLE(79)] "IAB
> event={"type":"exit"}", source:
> file:///android_asset/www/inappbrowser/index.html (79)
> 11-18 11:50:09.408: D/InAppBrowser(6369): target = _self
> 11-18 11:50:09.418: D/InAppBrowser(6369): in self
> 11-18 11:50:09.418: D/CordovaWebView(6369): >>> loadUrl(http://www.apple.com/)
> 11-18 11:50:09.418: D/PluginManager(6369): init()
> 11-18 11:50:09.428: D/CordovaWebView(6369): >>> loadUrlNow()
> 11-18 11:50:09.428: W/CordovaPlugin(6369): Attempted to send a second
> callback for ID: InAppBrowser921848427
> 11-18 11:50:09.428: W/CordovaPlugin(6369): Result was: ""
> 11-18 11:50:09.488: D/CordovaLog(6369):
> file:///android_asset/www/inappbrowser/index.html: Line 79 : IAB
> event={"type":"exit"}
> 11-18 11:50:09.488: I/chromium(6369): [INFO:CONSOLE(79)] "IAB
> event={"type":"exit"}", source:
> file:///android_asset/www/inappbrowser/index.html (79)
> 11-18 11:50:09.508: D/dalvikvm(6369): GC_FOR_ALLOC freed 50K, 3% free
> 18380K/18836K, paused 8ms, total 8ms
> 11-18 11:50:09.508: I/dalvikvm-heap(6369): Grow heap (frag case) to 18.584MB
> for 629776-byte allocation
> 11-18 11:50:09.528: D/dalvikvm(6369): GC_FOR_ALLOC freed 7K, 3% free
> 18988K/19452K, paused 12ms, total 12ms
> 11-18 11:50:09.578: D/dalvikvm(1108): GC_CONCURRENT freed 448K, 9% free
> 17309K/18816K, paused 2ms+1ms, total 23ms
> 11-18 11:50:09.638: D/dalvikvm(744): GC_CONCURRENT freed 2582K, 29% free
> 27397K/38100K, paused 3ms+4ms, total 76ms
> 11-18 11:50:29.428: E/CordovaWebView(6369): CordovaWebView: TIMEOUT ERROR!
> 11-18 11:50:29.428: D/CordovaWebViewClient(6369):
> CordovaWebViewClient.onReceivedError: Error code=-6 Description=The
> connection to the server was unsuccessful. URL=http://www.apple.com/
> 11-18 11:50:29.428: D/CordovaActivity(6369):
> onMessage(onReceivedError,{"errorCode":-6,"url":"http:\/\/www.apple.com\/","description":"The
> connection to the server was unsuccessful."})
> 11-18 11:50:29.458: D/SoftKeyboardDetect(6369): Ignore this event
> 11-18 11:50:29.558: D/CordovaWebViewClient(6369):
> onPageFinished(http://www.apple.com/)
> 11-18 11:50:29.558: D/CordovaActivity(6369):
> onMessage(onPageFinished,http://www.apple.com/)
> 11-18 11:50:56.078: D/audio_hw_primary(184): select_devices:
> out_snd_device(2: speaker) in_snd_device(0: )
> 11-18 11:50:56.098: D/CordovaActivity(6369): Paused the application!
> 11-18 11:50:56.128: W/IInputConnectionWrapper(6369): showStatusIcon on
> inactive InputConnection
> 11-18 11:50:56.598: D/CordovaActivity(6369): CordovaActivity.onDestroy()
> 11-18 11:50:56.598: D/CordovaWebView(6369): >>> loadUrlNow()
> 11-18 11:50:56.678: E/WindowManager(6369): android.view.WindowLeaked:
> Activity org.apache.mobilespec.mobilespec has leaked window
> com.android.internal.policy.impl.PhoneWindow$DecorView{42686118 V.E.
> R... 0,0-108
[jira] [Created] (CB-5427) InAppBrowser crashes without loadstop or loaderror on Android 4.4
Mike Billau created CB-5427:
---
Summary: InAppBrowser crashes without loadstop or loaderror on
Android 4.4
Key: CB-5427
URL: https://issues.apache.org/jira/browse/CB-5427
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin InAppBrowser
Affects Versions: 3.2.0
Environment: Windows 7
Android 4.4
Reporter: Mike Billau
InAppBrowser on Android 4.4 sometimes fails when you click to open any page on
the CordovaWebView. An alert will pop up saying "Unexpected: Browser closed
without a loadstop or loaderror." Closing the dialog will force quit the
application. I can't detect a pattern to reproduce the issue; what I do is just
keep running through the first few buttons under Local URL and White Listed URL
headings on the mobile spec page. Other people seem to be having this issue
too: https://groups.google.com/forum/#!topic/phonegap/e5_5unC2fYs
In logcat I'm seeing:
{noformat}
11-18 11:50:07.648: D/CordovaLog(6369):
file:///android_asset/www/inappbrowser/index.html: Line 79 : IAB
event={"type":"loadstop","url":"http://www.google.com/"}
11-18 11:50:07.648: I/chromium(6369): [INFO:CONSOLE(79)] "IAB
event={"type":"loadstop","url":"http://www.google.com/"}";, source:
file:///android_asset/www/inappbrowser/index.html (79)
11-18 11:50:07.928: W/UnimplementedWebViewApi(6369): Unimplemented WebView
method onKeyDown called from:
android.webkit.WebView.onKeyDown(WebView.java:2169)
11-18 11:50:07.968: W/InputEventReceiver(6369): Attempted to finish an input
event but the input event receiver has already been disposed.
11-18 11:50:07.998: D/CordovaLog(6369):
file:///android_asset/www/inappbrowser/index.html: Line 79 : IAB
event={"type":"exit"}
11-18 11:50:07.998: I/chromium(6369): [INFO:CONSOLE(79)] "IAB
event={"type":"exit"}", source:
file:///android_asset/www/inappbrowser/index.html (79)
11-18 11:50:09.408: D/InAppBrowser(6369): target = _self
11-18 11:50:09.418: D/InAppBrowser(6369): in self
11-18 11:50:09.418: D/CordovaWebView(6369): >>> loadUrl(http://www.apple.com/)
11-18 11:50:09.418: D/PluginManager(6369): init()
11-18 11:50:09.428: D/CordovaWebView(6369): >>> loadUrlNow()
11-18 11:50:09.428: W/CordovaPlugin(6369): Attempted to send a second callback
for ID: InAppBrowser921848427
11-18 11:50:09.428: W/CordovaPlugin(6369): Result was: ""
11-18 11:50:09.488: D/CordovaLog(6369):
file:///android_asset/www/inappbrowser/index.html: Line 79 : IAB
event={"type":"exit"}
11-18 11:50:09.488: I/chromium(6369): [INFO:CONSOLE(79)] "IAB
event={"type":"exit"}", source:
file:///android_asset/www/inappbrowser/index.html (79)
11-18 11:50:09.508: D/dalvikvm(6369): GC_FOR_ALLOC freed 50K, 3% free
18380K/18836K, paused 8ms, total 8ms
11-18 11:50:09.508: I/dalvikvm-heap(6369): Grow heap (frag case) to 18.584MB
for 629776-byte allocation
11-18 11:50:09.528: D/dalvikvm(6369): GC_FOR_ALLOC freed 7K, 3% free
18988K/19452K, paused 12ms, total 12ms
11-18 11:50:09.578: D/dalvikvm(1108): GC_CONCURRENT freed 448K, 9% free
17309K/18816K, paused 2ms+1ms, total 23ms
11-18 11:50:09.638: D/dalvikvm(744): GC_CONCURRENT freed 2582K, 29% free
27397K/38100K, paused 3ms+4ms, total 76ms
11-18 11:50:29.428: E/CordovaWebView(6369): CordovaWebView: TIMEOUT ERROR!
11-18 11:50:29.428: D/CordovaWebViewClient(6369):
CordovaWebViewClient.onReceivedError: Error code=-6 Description=The connection
to the server was unsuccessful. URL=http://www.apple.com/
11-18 11:50:29.428: D/CordovaActivity(6369):
onMessage(onReceivedError,{"errorCode":-6,"url":"http:\/\/www.apple.com\/","description":"The
connection to the server was unsuccessful."})
11-18 11:50:29.458: D/SoftKeyboardDetect(6369): Ignore this event
11-18 11:50:29.558: D/CordovaWebViewClient(6369):
onPageFinished(http://www.apple.com/)
11-18 11:50:29.558: D/CordovaActivity(6369):
onMessage(onPageFinished,http://www.apple.com/)
11-18 11:50:56.078: D/audio_hw_primary(184): select_devices: out_snd_device(2:
speaker) in_snd_device(0: )
11-18 11:50:56.098: D/CordovaActivity(6369): Paused the application!
11-18 11:50:56.128: W/IInputConnectionWrapper(6369): showStatusIcon on inactive
InputConnection
11-18 11:50:56.598: D/CordovaActivity(6369): CordovaActivity.onDestroy()
11-18 11:50:56.598: D/CordovaWebView(6369): >>> loadUrlNow()
11-18 11:50:56.678: E/WindowManager(6369): android.view.WindowLeaked: Activity
org.apache.mobilespec.mobilespec has leaked window
com.android.internal.policy.impl.PhoneWindow$DecorView{42686118 V.E.
R... 0,0-1080,638} that was originally added here
11-18 11:50:56.678: E/WindowManager(6369): at
android.view.ViewRootImpl.(ViewRootImpl.java:346)
11-18 11:50:56.678: E/WindowManager(6369): at
android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:248)
11-18 11:50:56.678: E/WindowManager(6369): at
android.view.WindowManagerImpl.addView(WindowManagerImpl.java:69)
11-18 11:50:56.67
[jira] [Commented] (CB-5414) 2.x InAppBrowser localUrls fail on Android 4.4
[ https://issues.apache.org/jira/browse/CB-5414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13824058#comment-13824058 ] Mike Billau commented on CB-5414: - Just tested with the latest 2.9.1 and this works fine. > 2.x InAppBrowser localUrls fail on Android 4.4 > --- > > Key: CB-5414 > URL: https://issues.apache.org/jira/browse/CB-5414 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin InAppBrowser >Affects Versions: 2.3.0, 2.6.0 >Reporter: Mike Billau >Priority: Minor > > For Cordova 2.x stream, InAppBrowser is not able to open Local URL links on > Android 4.4 > I think that it has to do with: > http://developer.android.com/guide/webapps/migrating.html#URLs > Apparently this is not covered by Quirks Mode because setting targetSDK=18 or > targetSDK=19 doesn't make a difference. > Tested with 2.x mobile spec. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CB-5414) 2.x InAppBrowser localUrls fail on Android 4.4
[ https://issues.apache.org/jira/browse/CB-5414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau updated CB-5414: Affects Version/s: (was: 2.9.0) > 2.x InAppBrowser localUrls fail on Android 4.4 > --- > > Key: CB-5414 > URL: https://issues.apache.org/jira/browse/CB-5414 > Project: Apache Cordova > Issue Type: Bug > Components: Plugin InAppBrowser >Affects Versions: 2.3.0, 2.6.0 >Reporter: Mike Billau >Priority: Minor > > For Cordova 2.x stream, InAppBrowser is not able to open Local URL links on > Android 4.4 > I think that it has to do with: > http://developer.android.com/guide/webapps/migrating.html#URLs > Apparently this is not covered by Quirks Mode because setting targetSDK=18 or > targetSDK=19 doesn't make a difference. > Tested with 2.x mobile spec. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CB-5414) 2.x InAppBrowser localUrls fail on Android 4.4
Mike Billau created CB-5414: --- Summary: 2.x InAppBrowser localUrls fail on Android 4.4 Key: CB-5414 URL: https://issues.apache.org/jira/browse/CB-5414 Project: Apache Cordova Issue Type: Bug Components: Plugin InAppBrowser Affects Versions: 2.9.0, 2.6.0, 2.3.0 Reporter: Mike Billau Priority: Minor For Cordova 2.x stream, InAppBrowser is not able to open Local URL links on Android 4.4 I think that it has to do with: http://developer.android.com/guide/webapps/migrating.html#URLs Apparently this is not covered by Quirks Mode because setting targetSDK=18 or targetSDK=19 doesn't make a difference. Tested with 2.x mobile spec. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5398) Pick image from Library or Photo album on android 4.4
[ https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13824028#comment-13824028 ] Mike Billau commented on CB-5398: - On Android 4.4, with Cordova 3.x, it looks like the app just doesn't get the image. However, on Cordova 2.x, the app actually will force quit. > Pick image from Library or Photo album on android 4.4 > - > > Key: CB-5398 > URL: https://issues.apache.org/jira/browse/CB-5398 > Project: Apache Cordova > Issue Type: Bug > Components: Android, Plugin Camera >Affects Versions: 2.9.0, 3.2.0 > Environment: android 4.4 >Reporter: julio cesar >Assignee: Mike Billau > > An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or > pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI. > Now android 4.4, when you select the above options, it opens an "open from" > dialog that let you choose from new places as "Recent", "Drive", "Images" > and "Downloads" (the names might not be the same as I use the device in > spanish and translated it). > If you choose any of them, you get an error, AndroidProtocolHandler, unable > to open content URL: the url here with a content://com.android.providers > format. > I've tested on phonegap 2.9 because this is the version I use, but I suppose > it affects all of them. (in fact I use 2.9.1) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5398) Pick image from Library or Photo album on android 4.4
[
https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13823835#comment-13823835
]
Mike Billau commented on CB-5398:
-
This exists on 3.x as well.
In the mean time a workaround is to go through the "Gallery" app.
So when it says "Recent", "Drive", "Images", and "Downloads", at the bottom of
that list will be "Gallery". As far as I can tell this opens up the Gallery app
and then you can navigate through those folders and select any of the photos.
I'm getting this in LOGCAT:
{noformat}
11-15 12:16:24.017: D/CordovaActivity(7351): Incoming Result
11-15 12:16:24.017: D/CordovaActivity(7351): Request code = 50
11-15 12:16:24.017: D/CordovaActivity(7351): We have a callback to send this
result to
11-15 12:16:24.037: D/dalvikvm(7351): GC_FOR_ALLOC freed 34K, 3% free
16572K/17084K, paused 8ms, total 8ms
11-15 12:16:24.057: I/dalvikvm-heap(7351): Grow heap (frag case) to 46.700MB
for 31961104-byte allocation
11-15 12:16:24.067: D/dalvikvm(7351): GC_FOR_ALLOC freed <1K, 2% free
47783K/48300K, paused 9ms, total 9ms
11-15 12:16:24.227: E/DatabaseUtils(4667): Writing exception to parcel
11-15 12:16:24.227: E/DatabaseUtils(4667): java.lang.SecurityException:
Permission Denial: reading com.android.providers.media.MediaDocumentsProvider
uri content://com.android.providers.media.documents/document/image:59 from
pid=7351, uid=10083 requires android.permission.MANAGE_DOCUMENTS, or
grantUriPermission()
11-15 12:16:24.227: E/DatabaseUtils(4667): at
android.content.ContentProvider$Transport.enforceReadPermissionInner(ContentProvider.java:457)
11-15 12:16:24.227: E/DatabaseUtils(4667): at
android.content.ContentProvider$Transport.enforceReadPermission(ContentProvider.java:394)
11-15 12:16:24.227: E/DatabaseUtils(4667): at
android.content.ContentProvider$Transport.enforceFilePermission(ContentProvider.java:387)
11-15 12:16:24.227: E/DatabaseUtils(4667): at
android.content.ContentProvider$Transport.openTypedAssetFile(ContentProvider.java:339)
11-15 12:16:24.227: E/DatabaseUtils(4667): at
android.content.ContentProviderNative.onTransact(ContentProviderNative.java:305)
11-15 12:16:24.227: E/DatabaseUtils(4667): at
android.os.Binder.execTransact(Binder.java:404)
11-15 12:16:24.227: E/DatabaseUtils(4667): at
dalvik.system.NativeStart.run(Native Method)
11-15 12:16:24.237: E/AndroidProtocolHandler(7351): Unable to open content URL:
content://com.android.providers.media.documents/document/image%3A59
11-15 12:16:24.247: D/dalvikvm(7351): GC_EXPLICIT freed 31233K, 4% free
16554K/17084K, paused 2ms+2ms, total 25ms
11-15 12:16:24.247: D/Whitelist(7351): Unlimited access to network resources
11-15 12:16:24.247: I/CordovaLog(7351): Found start page location: index.html
11-15 12:16:24.247: I/CordovaLog(7351): Changing log level to DEBUG(3)
11-15 12:16:24.247: D/CordovaActivity(7351): Resuming the App
11-15 12:16:24.247: D/CordovaActivity(7351): CB-3064: The errorUrl is null
11-15 12:16:24.247: D/CordovaLog(7351):
file:///android_asset/www/camera/index.html: Line 58 : URL:
content://com.android.providers.media.documents/document/image%3A59
11-15 12:16:24.247: I/chromium(7351): [INFO:CONSOLE(58)] "URL:
content://com.android.providers.media.documents/document/image%3A59", source:
file:///android_asset/www/camera/index.html (58)
{noformat}
Looks like there is a new permission: MANAGE_DOCUMENTS:
http://developer.android.com/reference/android/Manifest.permission.html#MANAGE_DOCUMENTS
I tried to add {{android.permission.MANAGE_DOCUMENTS}} to the
AndroidManifest.xml but even after doing this, compiling with ADB and
installing, I'm still getting the above error and still unable to pick any
photos unless I go through the "Gallery" app first. I made sure to set
targetSDK=19 which is when this new permission was added.
[~bowserj] do you have any ideas on why Android wouldn't be picking up the new
permission? Is the problem in {{DatabaseUtils}} that I assume is some Android
app?
> Pick image from Library or Photo album on android 4.4
> -
>
> Key: CB-5398
> URL: https://issues.apache.org/jira/browse/CB-5398
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, Plugin Camera
>Affects Versions: 2.9.0, 3.2.0
> Environment: android 4.4
>Reporter: julio cesar
>Assignee: Mike Billau
>
> An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or
> pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI.
> Now android 4.4, when you select the above options, it opens an "open from"
> dialog that let you choose from new places as "Recent", "Drive", "Images"
> and "Downloads" (the names might not be the same as I use the device in
> spanish and translated it).
> If you choose any of
[jira] [Assigned] (CB-5398) Pick image from Library or Photo album on android 4.4
[ https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau reassigned CB-5398: --- Assignee: Mike Billau > Pick image from Library or Photo album on android 4.4 > - > > Key: CB-5398 > URL: https://issues.apache.org/jira/browse/CB-5398 > Project: Apache Cordova > Issue Type: Bug > Components: Android, Plugin Camera >Affects Versions: 2.9.0, 3.2.0 > Environment: android 4.4 >Reporter: julio cesar >Assignee: Mike Billau > > An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or > pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI. > Now android 4.4, when you select the above options, it opens an "open from" > dialog that let you choose from new places as "Recent", "Drive", "Images" > and "Downloads" (the names might not be the same as I use the device in > spanish and translated it). > If you choose any of them, you get an error, AndroidProtocolHandler, unable > to open content URL: the url here with a content://com.android.providers > format. > I've tested on phonegap 2.9 because this is the version I use, but I suppose > it affects all of them. (in fact I use 2.9.1) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5372) Notification.beep blocks app execution - doesn't use CordovaInterface.getThreadPool
[
https://issues.apache.org/jira/browse/CB-5372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13823821#comment-13823821
]
Mike Billau commented on CB-5372:
-
I think that the beep has always blocked the UI...I think this is more of a
feature request and not a bug caused by not using a thread pool.
> Notification.beep blocks app execution - doesn't use
> CordovaInterface.getThreadPool
> ---
>
> Key: CB-5372
> URL: https://issues.apache.org/jira/browse/CB-5372
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android
>Affects Versions: 3.1.0
>Reporter: Michael Schmidt
>Priority: Blocker
>
> Calling a simple beep notification for 5 seconds blocks the whole app for
> this time
> {quote}
> navigator.notification.beep(5);
> {quote}
> Debug console output is as follows:
> {quote}
> 11-13 12:07:09.845: W/PluginManager(14561): THREAD WARNING: exec() call to
> Notification.beep blocked the main thread for 10507ms. Plugin should use
> CordovaInterface.getThreadPool().
> {quote}
> App runs on Android 4.1
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CB-5398) Pick image from Library or Photo album on android 4.4
[ https://issues.apache.org/jira/browse/CB-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau updated CB-5398: Affects Version/s: 3.2.0 > Pick image from Library or Photo album on android 4.4 > - > > Key: CB-5398 > URL: https://issues.apache.org/jira/browse/CB-5398 > Project: Apache Cordova > Issue Type: Bug > Components: Android, Plugin Camera >Affects Versions: 2.9.0, 3.2.0 > Environment: android 4.4 >Reporter: julio cesar > > An android 4.4 try to pick a photo using pictureSource.PHOTOLIBRARY or > pictureSource.SAVEDPHOTOALBUM and return type destinationType.FILE_URI. > Now android 4.4, when you select the above options, it opens an "open from" > dialog that let you choose from new places as "Recent", "Drive", "Images" > and "Downloads" (the names might not be the same as I use the device in > spanish and translated it). > If you choose any of them, you get an error, AndroidProtocolHandler, unable > to open content URL: the url here with a content://com.android.providers > format. > I've tested on phonegap 2.9 because this is the version I use, but I suppose > it affects all of them. (in fact I use 2.9.1) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CB-5294) File input element not opening file picker in Android 4.4
[ https://issues.apache.org/jira/browse/CB-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau updated CB-5294: Component/s: (was: Plugin File) > File input element not opening file picker in Android 4.4 > - > > Key: CB-5294 > URL: https://issues.apache.org/jira/browse/CB-5294 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 3.1.0 > Environment: Android 4.4 (emulator and Nexus 5) >Reporter: Paul Kane >Assignee: Joe Bowser >Priority: Blocker > > The file input field doesn't respond when clicked/tapped in Android 4.4. > Works fine in previous Android versions. This is regardless of whether the > Target Level is set to 18 or 19. > To reproduce, I created a fresh Cordova 3.1.0 project for Android. The only > modification I made to the default (placeholder) index.html file was adding a > element with a single element inside. Clicking the > "Choose File" button does nothing. No Logcat output or errors. Normally at > this point a dialogue would open allowing me to select an image from the > gallery or take a picture, which is what happens in older Android versions. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CB-5294) File input element not opening file picker in Android 4.4
[ https://issues.apache.org/jira/browse/CB-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau updated CB-5294: Assignee: Joe Bowser > File input element not opening file picker in Android 4.4 > - > > Key: CB-5294 > URL: https://issues.apache.org/jira/browse/CB-5294 > Project: Apache Cordova > Issue Type: Bug > Components: Android, Plugin File >Affects Versions: 3.1.0 > Environment: Android 4.4 (emulator and Nexus 5) >Reporter: Paul Kane >Assignee: Joe Bowser >Priority: Blocker > > The file input field doesn't respond when clicked/tapped in Android 4.4. > Works fine in previous Android versions. This is regardless of whether the > Target Level is set to 18 or 19. > To reproduce, I created a fresh Cordova 3.1.0 project for Android. The only > modification I made to the default (placeholder) index.html file was adding a > element with a single element inside. Clicking the > "Choose File" button does nothing. No Logcat output or errors. Normally at > this point a dialogue would open allowing me to select an image from the > gallery or take a picture, which is what happens in older Android versions. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CB-5294) File input element not opening file picker in Android 4.4
[ https://issues.apache.org/jira/browse/CB-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau updated CB-5294: Component/s: Plugin File Android > File input element not opening file picker in Android 4.4 > - > > Key: CB-5294 > URL: https://issues.apache.org/jira/browse/CB-5294 > Project: Apache Cordova > Issue Type: Bug > Components: Android, Plugin File >Affects Versions: 3.1.0 > Environment: Android 4.4 (emulator and Nexus 5) >Reporter: Paul Kane >Assignee: Joe Bowser >Priority: Blocker > > The file input field doesn't respond when clicked/tapped in Android 4.4. > Works fine in previous Android versions. This is regardless of whether the > Target Level is set to 18 or 19. > To reproduce, I created a fresh Cordova 3.1.0 project for Android. The only > modification I made to the default (placeholder) index.html file was adding a > element with a single element inside. Clicking the > "Choose File" button does nothing. No Logcat output or errors. Normally at > this point a dialogue would open allowing me to select an image from the > gallery or take a picture, which is what happens in older Android versions. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5122) Document supported workflows
[
https://issues.apache.org/jira/browse/CB-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13819099#comment-13819099
]
Mike Billau commented on CB-5122:
-
>> So far I see the #1 use case for the shell-tool workflow is when mixing
>> WebViews with native components, applicable only to Android & iOS. No
>> decision; it's simply not possible with the CLI.
Agreed.
Other advantages of using the Android SDK are:
- easier logging (Eclipse's logcat is much nicer than adb logcat),
- easier debugging (you could attach Eclipse debugger to your app - we'd need
to write instructions on this),
- some people may have set up their SDK for web dev
- developing plugins
- if only making an Android app, it might be easier conceptually
I'm having trouble thinking of other uses and use cases for native platform dev
workflow. Maybe [~shazron] and [~bowserj] have comments since I'm pretty sure
they don't use the CLI.
>> I tried to set up a separate platform "Installation" and shell "Development"
>> guides for Android, but it resulted in a lot of redundant or fragmented
>> content, e.g., regarding emulator setup, connecting the device, etc. As an
>> alternative, I worked the info about shell tools into the existing
>> "Installation" content and renamed the result back to a single "Platform
>> Guide." I think this approach is a much better way to clarify the overall
>> shell workflow, but let me know if you disagree. If not, we can use Android
>> for guidance & fold in the shell-tool content for other platforms.
SGTM. Lemme know how I can help.
> Document supported workflows
>
>
> Key: CB-5122
> URL: https://issues.apache.org/jira/browse/CB-5122
> Project: Apache Cordova
> Issue Type: Bug
> Components: Docs
>Affects Versions: 3.1.0
>Reporter: Mike Billau
>Assignee: Mike Sierra
>
> Based on the recent discussion here [1]we should document the two different
> supported Cordova workflows: using the CLI, and using plugman and bin
> scripts.
> Some of this documentation already exists but needs to be clarified and
> improved:
> {{Overview guide --> "Development Paths" section}}. This talks about getting
> started with the CLI and then mentions that you can switch to the
> platform-specific SDK tools. This section should be rewritten to make it
> clear that there are two distinct workflows, and that both are okay and
> supported. It could list out some pros and cons of each workflow (I'm sure we
> won't have any trouble finding those ;)). It should be prescriptive in that
> users should be following one of the two workflows, but it shouldn't make any
> statements about which is better.
> {{"The Command-line Interface" guide}} --> The "CLI workflow" guide. It
> generally looks complete except for some missing functionality that is
> documented in the CLI's README.md file (tests, hooks, some commands (serve),
> some merges info).
> {{Platform Guides --> (Platform) --> (Platform) Command-line tools}} --> Each
> platform has a "Command-line tools" doc that explains all of the command line
> tools for that project and how to use them. We need to go through these
> guides and verify that they are up to date and include all of the lower level
> command line tools and scripts. It should read like a tutorial in the same
> way that the Command-line Interface guide does.
> {{"Using Plugman to Manage Plugins"}} First, this guide needs to get exposed;
> I can't find any way to get to this guide from the docs and even had to ask a
> user how she managed to find it (a link from Plugman's readme!). This guide
> needs to be expanded quite a bit; we can probably fold most/all of Plugman's
> README.md file into this guide since it will be platform agnostic.
> I think those are the only pieces in the docs that need to be changed.
> [1] http://callback.markmail.org/thread/5nr7dgkquse4gdkl
> [2]
> http://cordova.apache.org/docs/en/edge/guide_overview_index.md.html#Overview
> [3] http://cordova.apache.org/docs/en/edge/plugin_ref_plugman.md.html
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (CB-5339) iOS progress indicator
Mike Billau created CB-5339: --- Summary: iOS progress indicator Key: CB-5339 URL: https://issues.apache.org/jira/browse/CB-5339 Project: Apache Cordova Issue Type: New Feature Components: Plugin Dialogs Environment: iOS Reporter: Mike Billau Priority: Minor iOS should have a progress indicator. Android has a "hidden" progress indicator API: https://github.com/apache/cordova-plugin-dialogs/blob/master/www/android/notification.js#L47 If we build one for iOS then we can expose both API's in the docs. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CB-5300) Clarify steps and expectations for manual tests
Mike Billau created CB-5300: --- Summary: Clarify steps and expectations for manual tests Key: CB-5300 URL: https://issues.apache.org/jira/browse/CB-5300 Project: Apache Cordova Issue Type: Bug Components: mobile-spec, Plugin InAppBrowser, Plugin Media Capture Reporter: Mike Billau Priority: Minor Some of the manual test pages are pretty confusing and it's not clear what steps should be taken to perform the tests or what the expectations should be. Part of this content is explained on http://wiki.apache.org/cordova/RunningTests but this page is missing data for InAppBrowser and MediaCapture (and possibly others.) Additionally, this wiki page is not very well known. The manual tests should either link to this wiki page or the test pages should include these steps directly in their HTML. This may require a separate jira item. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5122) Document supported workflows
[
https://issues.apache.org/jira/browse/CB-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13813281#comment-13813281
]
Mike Billau commented on CB-5122:
-
Sure [~sierra] feel free. I'm going to take another pass over the Overview,
Plugman, and CLI sections tomorrow (found a few undocumented CLI commands) and
then hopefully we can mark those ones as finished. Then I can help you or find
another task - anything in particular you could use extra help on?
> Document supported workflows
>
>
> Key: CB-5122
> URL: https://issues.apache.org/jira/browse/CB-5122
> Project: Apache Cordova
> Issue Type: Bug
> Components: Docs
>Affects Versions: 3.1.0
>Reporter: Mike Billau
>Assignee: Mike Sierra
>
> Based on the recent discussion here [1]we should document the two different
> supported Cordova workflows: using the CLI, and using plugman and bin
> scripts.
> Some of this documentation already exists but needs to be clarified and
> improved:
> {{Overview guide --> "Development Paths" section}}. This talks about getting
> started with the CLI and then mentions that you can switch to the
> platform-specific SDK tools. This section should be rewritten to make it
> clear that there are two distinct workflows, and that both are okay and
> supported. It could list out some pros and cons of each workflow (I'm sure we
> won't have any trouble finding those ;)). It should be prescriptive in that
> users should be following one of the two workflows, but it shouldn't make any
> statements about which is better.
> {{"The Command-line Interface" guide}} --> The "CLI workflow" guide. It
> generally looks complete except for some missing functionality that is
> documented in the CLI's README.md file (tests, hooks, some commands (serve),
> some merges info).
> {{Platform Guides --> (Platform) --> (Platform) Command-line tools}} --> Each
> platform has a "Command-line tools" doc that explains all of the command line
> tools for that project and how to use them. We need to go through these
> guides and verify that they are up to date and include all of the lower level
> command line tools and scripts. It should read like a tutorial in the same
> way that the Command-line Interface guide does.
> {{"Using Plugman to Manage Plugins"}} First, this guide needs to get exposed;
> I can't find any way to get to this guide from the docs and even had to ask a
> user how she managed to find it (a link from Plugman's readme!). This guide
> needs to be expanded quite a bit; we can probably fold most/all of Plugman's
> README.md file into this guide since it will be platform agnostic.
> I think those are the only pieces in the docs that need to be changed.
> [1] http://callback.markmail.org/thread/5nr7dgkquse4gdkl
> [2]
> http://cordova.apache.org/docs/en/edge/guide_overview_index.md.html#Overview
> [3] http://cordova.apache.org/docs/en/edge/plugin_ref_plugman.md.html
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CB-3962) document and implement editorial guidelines
[ https://issues.apache.org/jira/browse/CB-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13811205#comment-13811205 ] Mike Billau commented on CB-3962: - One trivial question I had - one or two spaces after a period? > document and implement editorial guidelines > --- > > Key: CB-3962 > URL: https://issues.apache.org/jira/browse/CB-3962 > Project: Apache Cordova > Issue Type: Task > Components: Docs >Reporter: Mike Sierra >Assignee: Mike Sierra >Priority: Critical > > The top-level STYLESHEET.md file collects editorial guidelines to help > standardize the doc. Keep updating to reflect any site-side conventions. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CB-5034) Document plugin registry
[ https://issues.apache.org/jira/browse/CB-5034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau reassigned CB-5034: --- Assignee: Mike Sierra (was: Mike Billau) > Document plugin registry > > > Key: CB-5034 > URL: https://issues.apache.org/jira/browse/CB-5034 > Project: Apache Cordova > Issue Type: Bug > Components: Docs, Registry >Affects Versions: Master >Reporter: Mike Billau >Assignee: Mike Sierra > > I can't find any reference to the plugin registry anywhere in our > documentation. Am I looking in the wrong place or are we waiting for the web > component to be more polished before announcing the registry? > I think some places the registry should be mentioned: > Plugman: readme.md > CLI: > cordova help command (CB-5031) > readme.md > docs: > http://cordova.apache.org/docs/en/edge/guide_cli_index.md.html#The%20Command-line%20Interface > (I think it's best to split the "Add Platforms" section into "Add > Platforms" and "Add Plugins", and in this new section talk about adding > plugins, automatic plugin installation (plugin dependencies), and the > registry) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CB-4890) Reference to plugins.xml should be config.xml
[
https://issues.apache.org/jira/browse/CB-4890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Billau resolved CB-4890.
-
Resolution: Fixed
> Reference to plugins.xml should be config.xml
> -
>
> Key: CB-4890
> URL: https://issues.apache.org/jira/browse/CB-4890
> Project: Apache Cordova
> Issue Type: Improvement
> Components: Docs
>Affects Versions: 2.9.0
>Reporter: Peter
>Assignee: Michael Brooks
>Priority: Trivial
>
> The Capture API documentation for Android (see "Permissions" section) is
> still referring to plugins.xml instead of config.xml
> {quote}
> Permissions
> Android
> app/res/xml/plugins.xml
> {quote}
> http://cordova.apache.org/docs/en/2.9.0/cordova_media_capture_capture.md.html#Capture
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CB-5122) Document supported workflows
[
https://issues.apache.org/jira/browse/CB-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809643#comment-13809643
]
Mike Billau commented on CB-5122:
-
bq. Not sure I understand "collapse," but if you mean simply copying the
README content into the doc (either one-time or dynamically), then I don't
agree.
The problem with the README.md files is that sometimes there will be duplicated
information in either the README or some guide, such as most of the
cordova-android README.md being duplicated in the Android Platform Guide, or
missing information, such as the registry commands and proxy settings for
cordova-cli being located only in the CLI's README.md.
bq. I suggest we get rid of "Platform Guide" & instead feature a "SoAndSo
Installation Guide", applicable to both CLI & shell workflows...
I think that we definitely need to revamp the individual Platform Guides and
remove any workflow related information. It should just talk about how to
install the platform SDKs and anything else common to both workflows (getting
signing keys, etc.) It should say something like "Now that you have installed
**Platform X** SDK, you can create an app using either _link to CLI guide_ or
_link to plugman guide_"
bq. ...then a separate "SoAndSo Development Guide" detailing the actual shell
workflow, corresponding to the current "Command-line Utilities" page
If you are suggesting multiple guides for each platform ("Android Development
Guide", "iOS Development Guide") then I think I agree. The problem will be not
reproducing the plugman documentation. I think we should have a high level
"Using Plugman" guide that details all of the common pieces of the shell
workflow and plugman API (the missing counterpart to "The Command-line
Interface" guide). Then we can add any platform-specific steps or information
for this shell workflow in these platform-specific "SoAndSo Development Guide"
- such as logging capabilities, anything unique in the "Command-line Utilities"
section, and all of the information about loading a project into an IDE. Then
go back to the "Using Plugman" guide and insert a bunch of warning and
pointers.
bq. Not sure I agree naming the CLI guide to "CLI Workflow", if that's what
you're suggesting. It implies a parallel set of "Workflow" topics elsewhere.
Agree. I'm not trying to suggest we call it the "CLI Workflow", I was just
using that phrase because that's what we were all throwing around on the ML. I
do think that this guide is sorely lacking a parallel doc though, but that will
be rectified when we expand the Using Plugman guide.
> Document supported workflows
>
>
> Key: CB-5122
> URL: https://issues.apache.org/jira/browse/CB-5122
> Project: Apache Cordova
> Issue Type: Bug
> Components: Docs
>Affects Versions: 3.1.0
>Reporter: Mike Billau
>Assignee: Mike Sierra
>
> Based on the recent discussion here [1]we should document the two different
> supported Cordova workflows: using the CLI, and using plugman and bin
> scripts.
> Some of this documentation already exists but needs to be clarified and
> improved:
> {{Overview guide --> "Development Paths" section}}. This talks about getting
> started with the CLI and then mentions that you can switch to the
> platform-specific SDK tools. This section should be rewritten to make it
> clear that there are two distinct workflows, and that both are okay and
> supported. It could list out some pros and cons of each workflow (I'm sure we
> won't have any trouble finding those ;)). It should be prescriptive in that
> users should be following one of the two workflows, but it shouldn't make any
> statements about which is better.
> {{"The Command-line Interface" guide}} --> The "CLI workflow" guide. It
> generally looks complete except for some missing functionality that is
> documented in the CLI's README.md file (tests, hooks, some commands (serve),
> some merges info).
> {{Platform Guides --> (Platform) --> (Platform) Command-line tools}} --> Each
> platform has a "Command-line tools" doc that explains all of the command line
> tools for that project and how to use them. We need to go through these
> guides and verify that they are up to date and include all of the lower level
> command line tools and scripts. It should read like a tutorial in the same
> way that the Command-line Interface guide does.
> {{"Using Plugman to Manage Plugins"}} First, this guide needs to get exposed;
> I can't find any way to get to this guide from the docs and even had to ask a
> user how she managed to find it (a link from Plugman's readme!). This guide
> needs to be expanded quite a bit; we can probably fold most/all of Plugman's
> README.md file into this guide since it will be platform agnostic.
> I think those are the only p
[jira] [Commented] (CB-4890) Reference to plugins.xml should be config.xml
[
https://issues.apache.org/jira/browse/CB-4890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809455#comment-13809455
]
Mike Billau commented on CB-4890:
-
Man, somehow this change from plugins.xml to config.xml didn't get put into
edge, 3.1, or 3.0: https://github.com/apache/cordova-docs/pull/142 for this
plugin.
> Reference to plugins.xml should be config.xml
> -
>
> Key: CB-4890
> URL: https://issues.apache.org/jira/browse/CB-4890
> Project: Apache Cordova
> Issue Type: Improvement
> Components: Docs
>Affects Versions: 2.9.0
>Reporter: Peter
>Assignee: Michael Brooks
>Priority: Trivial
>
> The Capture API documentation for Android (see "Permissions" section) is
> still referring to plugins.xml instead of config.xml
> {quote}
> Permissions
> Android
> app/res/xml/plugins.xml
> {quote}
> http://cordova.apache.org/docs/en/2.9.0/cordova_media_capture_capture.md.html#Capture
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Assigned] (CB-4390) Android Command-line Tools Section is missing few commands
[ https://issues.apache.org/jira/browse/CB-4390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau reassigned CB-4390: --- Assignee: Mike Billau (was: Sharif Ahmed) > Android Command-line Tools Section is missing few commands > -- > > Key: CB-4390 > URL: https://issues.apache.org/jira/browse/CB-4390 > Project: Apache Cordova > Issue Type: Bug > Components: Docs >Affects Versions: 3.0.0 >Reporter: Sharif Ahmed >Assignee: Mike Billau >Priority: Minor > > In the Android Command-line Tools Section the following commands > documentation are missing: > /bin/check_reqs > /bin/update [path] > /cordova/version > The above are present in README but has not been update in the doc. > Also, Cleaning font size is smaller than the rest. This also needs a fix. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CB-3802) General Configuration Guide has incorrect config.xml
[
https://issues.apache.org/jira/browse/CB-3802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Billau resolved CB-3802.
-
Resolution: Fixed
I'm pretty sure this can be closed. I went through all of the API's and
verified the docs (for Android) had the correct XML and permissions:
https://issues.apache.org/jira/browse/CB-5005
> General Configuration Guide has incorrect config.xml
>
>
> Key: CB-3802
> URL: https://issues.apache.org/jira/browse/CB-3802
> Project: Apache Cordova
> Issue Type: Bug
> Components: Docs
>Reporter: Joe Bowser
>Assignee: Michael Brooks
>
> The XML format for plugins is wrong. I'm not sure how it works across
> platfomrs, but for Android it should be:
> {code}
>
>
>
> {code}
> I'm guessing it's similar on iOS, but I want to make sure it's right, which
> is why I'm creating the ticket instead of just editing it on the spot.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CB-5122) Document supported workflows
[
https://issues.apache.org/jira/browse/CB-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13809023#comment-13809023
]
Mike Billau commented on CB-5122:
-
Hi Mike, thanks. I've started the first pass here:
https://github.com/apache/cordova-docs/pull/140
The only summary I have of the trade-offs is that huge thread:
http://callback.markmail.org/thread/5nr7dgkquse4gdkl
I was just going to explain the differences in the workflows at first and
encourage people to learn about both. Maybe later we can add a "pros/cons"
table that we can expand on as we discover them...the only problem with this is
that one person's pro is another person's con!
Regarding "merges" information, I reread everything and actually I think you're
right, the merges section on the Guide is pretty complete - I might change the
heading to "Customize Each Platform via /merges/" just to make it easier for
people trying to see what that folder is for. However I think that this
highlights a bigger issue: that the README.md files and the various Guides
sometimes have conflicting information. I wanted to create a new JIRA item to
collapse the readme.md's into the guides - what do you think about this?
> Document supported workflows
>
>
> Key: CB-5122
> URL: https://issues.apache.org/jira/browse/CB-5122
> Project: Apache Cordova
> Issue Type: Bug
> Components: Docs
>Affects Versions: 3.1.0
>Reporter: Mike Billau
>Assignee: Mike Sierra
>
> Based on the recent discussion here [1]we should document the two different
> supported Cordova workflows: using the CLI, and using plugman and bin
> scripts.
> Some of this documentation already exists but needs to be clarified and
> improved:
> {{Overview guide --> "Development Paths" section}}. This talks about getting
> started with the CLI and then mentions that you can switch to the
> platform-specific SDK tools. This section should be rewritten to make it
> clear that there are two distinct workflows, and that both are okay and
> supported. It could list out some pros and cons of each workflow (I'm sure we
> won't have any trouble finding those ;)). It should be prescriptive in that
> users should be following one of the two workflows, but it shouldn't make any
> statements about which is better.
> {{"The Command-line Interface" guide}} --> The "CLI workflow" guide. It
> generally looks complete except for some missing functionality that is
> documented in the CLI's README.md file (tests, hooks, some commands (serve),
> some merges info).
> {{Platform Guides --> (Platform) --> (Platform) Command-line tools}} --> Each
> platform has a "Command-line tools" doc that explains all of the command line
> tools for that project and how to use them. We need to go through these
> guides and verify that they are up to date and include all of the lower level
> command line tools and scripts. It should read like a tutorial in the same
> way that the Command-line Interface guide does.
> {{"Using Plugman to Manage Plugins"}} First, this guide needs to get exposed;
> I can't find any way to get to this guide from the docs and even had to ask a
> user how she managed to find it (a link from Plugman's readme!). This guide
> needs to be expanded quite a bit; we can probably fold most/all of Plugman's
> README.md file into this guide since it will be platform agnostic.
> I think those are the only pieces in the docs that need to be changed.
> [1] http://callback.markmail.org/thread/5nr7dgkquse4gdkl
> [2]
> http://cordova.apache.org/docs/en/edge/guide_overview_index.md.html#Overview
> [3] http://cordova.apache.org/docs/en/edge/plugin_ref_plugman.md.html
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Assigned] (CB-5122) Document supported workflows
[
https://issues.apache.org/jira/browse/CB-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Billau reassigned CB-5122:
---
Assignee: Mike Sierra (was: Mike Billau)
> Document supported workflows
>
>
> Key: CB-5122
> URL: https://issues.apache.org/jira/browse/CB-5122
> Project: Apache Cordova
> Issue Type: Bug
> Components: Docs
>Affects Versions: 3.1.0
>Reporter: Mike Billau
>Assignee: Mike Sierra
>
> Based on the recent discussion here [1]we should document the two different
> supported Cordova workflows: using the CLI, and using plugman and bin
> scripts.
> Some of this documentation already exists but needs to be clarified and
> improved:
> {{Overview guide --> "Development Paths" section}}. This talks about getting
> started with the CLI and then mentions that you can switch to the
> platform-specific SDK tools. This section should be rewritten to make it
> clear that there are two distinct workflows, and that both are okay and
> supported. It could list out some pros and cons of each workflow (I'm sure we
> won't have any trouble finding those ;)). It should be prescriptive in that
> users should be following one of the two workflows, but it shouldn't make any
> statements about which is better.
> {{"The Command-line Interface" guide}} --> The "CLI workflow" guide. It
> generally looks complete except for some missing functionality that is
> documented in the CLI's README.md file (tests, hooks, some commands (serve),
> some merges info).
> {{Platform Guides --> (Platform) --> (Platform) Command-line tools}} --> Each
> platform has a "Command-line tools" doc that explains all of the command line
> tools for that project and how to use them. We need to go through these
> guides and verify that they are up to date and include all of the lower level
> command line tools and scripts. It should read like a tutorial in the same
> way that the Command-line Interface guide does.
> {{"Using Plugman to Manage Plugins"}} First, this guide needs to get exposed;
> I can't find any way to get to this guide from the docs and even had to ask a
> user how she managed to find it (a link from Plugman's readme!). This guide
> needs to be expanded quite a bit; we can probably fold most/all of Plugman's
> README.md file into this guide since it will be platform agnostic.
> I think those are the only pieces in the docs that need to be changed.
> [1] http://callback.markmail.org/thread/5nr7dgkquse4gdkl
> [2]
> http://cordova.apache.org/docs/en/edge/guide_overview_index.md.html#Overview
> [3] http://cordova.apache.org/docs/en/edge/plugin_ref_plugman.md.html
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CB-5196) BB10 invoke() plugin is shadowded by cordova.js
[
https://issues.apache.org/jira/browse/CB-5196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13805334#comment-13805334
]
Mike Billau commented on CB-5196:
-
Hmmm so all of the WebWorks API's were folded into the Blackberry plugins
listed in the repo above?
If the WebWorks SDK is not compatible with Cordova 3.X, does that mean the only
way to access the WebWorks API is to install these plugins?
Is this documented anywhere? I was looking on edge but can't find anything
talking about installing these new plugins in order to continue to use
functionality that was "just there" from the WebWorks SDK. I can help with this
documentation if needed...We could probably create a new guide like "Using
WebWorks APIs" (blackberry.invoke) and link to this guide in the Blackberry
Platform Guide [1] and BB10 Command Line Tools [2]?
[1]http://cordova.apache.org/docs/en/edge/guide_platforms_blackberry10_index.md.html#BlackBerry%2010%20Platform%20Guide
[2]http://cordova.apache.org/docs/en/edge/guide_platforms_blackberry10_tools.md.html#BlackBerry%2010%20Command-line%20Tools
> BB10 invoke() plugin is shadowded by cordova.js
> ---
>
> Key: CB-5196
> URL: https://issues.apache.org/jira/browse/CB-5196
> Project: Apache Cordova
> Issue Type: Bug
> Components: BlackBerry
>Affects Versions: 3.1.0
> Environment: Blackberry 10
>Reporter: Mike Billau
> Attachments: bbInvoke.html
>
>
> Our users need to invoke blackberry.invoke.invoke(). As per WebWorks doc, to
> call any BB API, webworks.js needs to be included in the html file.
> The problem is that there does not seem to be a way to call invoke():
> 1. Create a simple BB10 app using the attached HTML file,
> 2. Add feature to the config.xml: name="blackberry.invoke" value="blackberry.invoke"/>
> 3. Run the app. Press the button; the browser window doesn't open.
> 4. Edit the HTML file and place the cordova.js script before webworks.js
> script
> 5. Run the app again, and there is a popup saying: "Error intializing
> cordova:undefined". After dismissing the alert, you can press the button and
> the browser opens just fine.
> "Analysis:
> Internally blackberry.invoke.invoke() ('invoke' plugin) calls
> *window.webworks.event.isOn()* in blackberry.invoke/client.js. This is where
> the problem is: *window.webworks* is defined in both cordova.js and
> webworks.js.The one in cordova.js doesn't have 'event' function whereas it is
> available in window.webworks of webworks.js. Hence when webworks.js is loaded
> after cordova.js, it works fine and not if it is reversed."
> Even though it works when we put webworks.js first we need to squash the
> alert() and make sure cordova initializes correctly.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CB-5196) BB10 invoke() plugin is shadowded by cordova.js
[
https://issues.apache.org/jira/browse/CB-5196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Billau updated CB-5196:
Attachment: bbInvoke.html
> BB10 invoke() plugin is shadowded by cordova.js
> ---
>
> Key: CB-5196
> URL: https://issues.apache.org/jira/browse/CB-5196
> Project: Apache Cordova
> Issue Type: Bug
> Components: BlackBerry
>Affects Versions: 3.1.0
> Environment: Blackberry 10
>Reporter: Mike Billau
> Attachments: bbInvoke.html
>
>
> Our users need to invoke blackberry.invoke.invoke(). As per WebWorks doc, to
> call any BB API, webworks.js needs to be included in the html file.
> The problem is that there does not seem to be a way to call invoke():
> 1. Create a simple BB10 app using the attached HTML file,
> 2. Add feature to the config.xml: name="blackberry.invoke" value="blackberry.invoke"/>
> 3. Run the app. Press the button; the browser window doesn't open.
> 4. Edit the HTML file and place the cordova.js script before webworks.js
> script
> 5. Run the app again, and there is a popup saying: "Error intializing
> cordova:undefined". After dismissing the alert, you can press the button and
> the browser opens just fine.
> "Analysis:
> Internally blackberry.invoke.invoke() ('invoke' plugin) calls
> *window.webworks.event.isOn()* in blackberry.invoke/client.js. This is where
> the problem is: *window.webworks* is defined in both cordova.js and
> webworks.js.The one in cordova.js doesn't have 'event' function whereas it is
> available in window.webworks of webworks.js. Hence when webworks.js is loaded
> after cordova.js, it works fine and not if it is reversed."
> Even though it works when we put webworks.js first we need to squash the
> alert() and make sure cordova initializes correctly.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (CB-5196) BB10 invoke() plugin is shadowded by cordova.js
Mike Billau created CB-5196:
---
Summary: BB10 invoke() plugin is shadowded by cordova.js
Key: CB-5196
URL: https://issues.apache.org/jira/browse/CB-5196
Project: Apache Cordova
Issue Type: Bug
Components: BlackBerry
Affects Versions: 3.1.0
Environment: Blackberry 10
Reporter: Mike Billau
Our users need to invoke blackberry.invoke.invoke(). As per WebWorks doc, to
call any BB API, webworks.js needs to be included in the html file.
The problem is that there does not seem to be a way to call invoke():
1. Create a simple BB10 app using the attached HTML file,
2. Add feature to the config.xml:
3. Run the app. Press the button; the browser window doesn't open.
4. Edit the HTML file and place the cordova.js script before webworks.js script
5. Run the app again, and there is a popup saying: "Error intializing
cordova:undefined". After dismissing the alert, you can press the button and
the browser opens just fine.
"Analysis:
Internally blackberry.invoke.invoke() ('invoke' plugin) calls
*window.webworks.event.isOn()* in blackberry.invoke/client.js. This is where
the problem is: *window.webworks* is defined in both cordova.js and
webworks.js.The one in cordova.js doesn't have 'event' function whereas it is
available in window.webworks of webworks.js. Hence when webworks.js is loaded
after cordova.js, it works fine and not if it is reversed."
Even though it works when we put webworks.js first we need to squash the
alert() and make sure cordova initializes correctly.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CB-5052) Andorid's media capture doesn't use ThreadPool
[
https://issues.apache.org/jira/browse/CB-5052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Billau updated CB-5052:
Priority: Minor (was: Major)
> Andorid's media capture doesn't use ThreadPool
> --
>
> Key: CB-5052
> URL: https://issues.apache.org/jira/browse/CB-5052
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, Plugin Media Capture
> Environment: Windows 7
>Reporter: Mike Billau
>Assignee: David Kemp
>Priority: Minor
>
> From:
> http://stackoverflow.com/questions/19282318/phongap-capture-plugin-crashes-android
> Taking a picture with media-capture plugin will crash the app when the plugin
> returns from the camera app. Reproduced with Nexus 7 on 4.2, I used the
> simple Full Example from the docs.
> Got this in logcat:
> {noformat}
> I/ActivityManager( 476): Displayed
> com.google.android.gallery3d/com.android.camera.CameraActivity: +1s80ms
> W/IInputConnectionWrapper(31792): showStatusIcon on inactive InputConnection
> V/CAM_PhotoModule(29129): Preview size is 960x720
> V/CAM_PhotoModule(29129): onShutterButtonClick: mCameraState=1
> E/NvOmxCamera( 128): OMX_ERRORTYPE
> android::NvOmxCamera::getCameraStereoMode(NvxComponent*,
> NvOmxCameraUserStereoMode&): Error: invalid NVX mode 0.
> E/NvOmxCamera( 128): OMX_ERRORTYPE
> android::NvOmxCamera::getCameraStereoModeAndCaptureInfo(NvxComponent*,
> NvOmxCameraUserStereoMode&, NVX_STEREOCAPTUREINFO&): getCameraStereoMode
> failed with 0x
> D/NvOsDebugPrintf( 128): NvMMLiteJPEGEncSetAttribute: Incorrect value 0 for
> stereo capture type
> E/NvOmxCameraSettings( 128): OMX_ERRORTYPE
> android::programStereoInfo(OMX_HANDLETYPE, const NVX_STEREOCAPTUREINFO&,
> android::NvxWrappers*): pNvxWrappers->OMX_SetConfigIL failed with 0x80001005
> V/CAM_PhotoModule(29129): mShutterToRawCallbackTime = 1381355622457ms
> V/CAM_PhotoModule(29129): mShutterLag = 422ms
> D/dalvikvm(29129): GC_FOR_ALLOC freed 679K, 15% free 1K/14236K, paused
> 27ms, total 28ms
> I/dalvikvm-heap(29129): Grow heap (frag case) to 13.063MB for 1036816-byte
> allocation
> D/NvOsDebugPrintf( 128): Tryproc: INBuffer-Values of Width and Height 1280
> 960
> D/dalvikvm(29129): GC_FOR_ALLOC freed 1K, 14% free 13233K/15252K, paused
> 33ms, total 33ms
> V/CAM_PhotoModule(29129): mShutterToPostViewCallbackTime = 88ms
> V/CAM_PhotoModule(29129): mShutterToRawCallbackTime = 109ms
> V/CAM_PhotoModule(29129): mPictureDisplayedToJpegCallbackTime = 25ms
> D/CameraStorage(29129): External storage state=mounted
> V/CAM_PhotoModule(29129): mJpegCallbackFinishTime = 2ms
> I/MPL-storeload( 476): mpl state size = 5512
> E/MPL-storeload( 476): calData from inv_save_mpl_states, size=2
> I/MPL-storeload( 476): cal data size to write = 5512
> I/MPL-storeload( 476): Bytes written = 5512
> V/CAM_PhotoModule(29129): stopPreview
> D/( 128): Camera fd close (MI1040)
> E/NvOmxCamera( 128): Already called release()
> I/CameraClient( 128): Destroying camera 0
> W/NvOmxCamera( 128): Already called release()
> D/MediaProvider(27296): object removed 2270
> W/AudioFlinger( 128): session id 453 not found for pid 128
> W/AudioFlinger( 128): session id 454 not found for pid 128
> D/CordovaActivity(31792): Request code = 1
> D/AndroidRuntime(31792): Shutting down VM
> W/dalvikvm(31792): threadid=1: thread exiting with uncaught exception
> (group=0x410ee930)
> E/AndroidRuntime(31792): FATAL EXCEPTION: main
> E/AndroidRuntime(31792): java.lang.RuntimeException: Failure delivering
> result ResultInfo{who=null, request=1, result=-1, data=null} to activity
> {io.cordova.hellocordova/io.cordova.hellocordova.HelloCordova}:
> java.lang.IllegalStateException: Do not perform IO operations on the UI
> thread. Use Cordova
> Interface.getThreadPool() instead.
> E/AndroidRuntime(31792):at
> android.app.ActivityThread.deliverResults(ActivityThread.java:3319)
> E/AndroidRuntime(31792):at
> android.app.ActivityThread.handleSendResult(ActivityThread.java:3362)
> E/AndroidRuntime(31792):at
> android.app.ActivityThread.access$1100(ActivityThread.java:141)
> E/AndroidRuntime(31792):at
> android.app.ActivityThread$H.handleMessage(ActivityThread.java:1282)
> E/AndroidRuntime(31792):at
> android.os.Handler.dispatchMessage(Handler.java:99)
> E/AndroidRuntime(31792):at android.os.Looper.loop(Looper.java:137)
> E/AndroidRuntime(31792):at
> android.app.ActivityThread.main(ActivityThread.java:5041)
> E/AndroidRuntime(31792):at
> java.lang.reflect.Method.invokeNative(Native Method)
> E/AndroidRuntime(31792):at
> java.lang.reflect.Method.invoke(Method.java:511)
> E/AndroidRuntime(31792):at
> com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:793)
> E/AndroidRuntime(3
[jira] [Commented] (CB-5052) Andorid's media capture doesn't use ThreadPool
[
https://issues.apache.org/jira/browse/CB-5052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13804476#comment-13804476
]
Mike Billau commented on CB-5052:
-
Okay I think that this might have been a false flag of sorts. Turns out the
initial error report about capturing images was being caused by malformed .js
on the main page. I have not been able to reproduce the error capturing video,
but I'm thinking it might be the same thing. I verified that the examples in
the docs all have valid HTML. Will keep this open since we should still move
the plugin off of the ThreadPool.
> Andorid's media capture doesn't use ThreadPool
> --
>
> Key: CB-5052
> URL: https://issues.apache.org/jira/browse/CB-5052
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, Plugin Media Capture
> Environment: Windows 7
>Reporter: Mike Billau
>Assignee: David Kemp
>Priority: Minor
>
> From:
> http://stackoverflow.com/questions/19282318/phongap-capture-plugin-crashes-android
> Taking a picture with media-capture plugin will crash the app when the plugin
> returns from the camera app. Reproduced with Nexus 7 on 4.2, I used the
> simple Full Example from the docs.
> Got this in logcat:
> {noformat}
> I/ActivityManager( 476): Displayed
> com.google.android.gallery3d/com.android.camera.CameraActivity: +1s80ms
> W/IInputConnectionWrapper(31792): showStatusIcon on inactive InputConnection
> V/CAM_PhotoModule(29129): Preview size is 960x720
> V/CAM_PhotoModule(29129): onShutterButtonClick: mCameraState=1
> E/NvOmxCamera( 128): OMX_ERRORTYPE
> android::NvOmxCamera::getCameraStereoMode(NvxComponent*,
> NvOmxCameraUserStereoMode&): Error: invalid NVX mode 0.
> E/NvOmxCamera( 128): OMX_ERRORTYPE
> android::NvOmxCamera::getCameraStereoModeAndCaptureInfo(NvxComponent*,
> NvOmxCameraUserStereoMode&, NVX_STEREOCAPTUREINFO&): getCameraStereoMode
> failed with 0x
> D/NvOsDebugPrintf( 128): NvMMLiteJPEGEncSetAttribute: Incorrect value 0 for
> stereo capture type
> E/NvOmxCameraSettings( 128): OMX_ERRORTYPE
> android::programStereoInfo(OMX_HANDLETYPE, const NVX_STEREOCAPTUREINFO&,
> android::NvxWrappers*): pNvxWrappers->OMX_SetConfigIL failed with 0x80001005
> V/CAM_PhotoModule(29129): mShutterToRawCallbackTime = 1381355622457ms
> V/CAM_PhotoModule(29129): mShutterLag = 422ms
> D/dalvikvm(29129): GC_FOR_ALLOC freed 679K, 15% free 1K/14236K, paused
> 27ms, total 28ms
> I/dalvikvm-heap(29129): Grow heap (frag case) to 13.063MB for 1036816-byte
> allocation
> D/NvOsDebugPrintf( 128): Tryproc: INBuffer-Values of Width and Height 1280
> 960
> D/dalvikvm(29129): GC_FOR_ALLOC freed 1K, 14% free 13233K/15252K, paused
> 33ms, total 33ms
> V/CAM_PhotoModule(29129): mShutterToPostViewCallbackTime = 88ms
> V/CAM_PhotoModule(29129): mShutterToRawCallbackTime = 109ms
> V/CAM_PhotoModule(29129): mPictureDisplayedToJpegCallbackTime = 25ms
> D/CameraStorage(29129): External storage state=mounted
> V/CAM_PhotoModule(29129): mJpegCallbackFinishTime = 2ms
> I/MPL-storeload( 476): mpl state size = 5512
> E/MPL-storeload( 476): calData from inv_save_mpl_states, size=2
> I/MPL-storeload( 476): cal data size to write = 5512
> I/MPL-storeload( 476): Bytes written = 5512
> V/CAM_PhotoModule(29129): stopPreview
> D/( 128): Camera fd close (MI1040)
> E/NvOmxCamera( 128): Already called release()
> I/CameraClient( 128): Destroying camera 0
> W/NvOmxCamera( 128): Already called release()
> D/MediaProvider(27296): object removed 2270
> W/AudioFlinger( 128): session id 453 not found for pid 128
> W/AudioFlinger( 128): session id 454 not found for pid 128
> D/CordovaActivity(31792): Request code = 1
> D/AndroidRuntime(31792): Shutting down VM
> W/dalvikvm(31792): threadid=1: thread exiting with uncaught exception
> (group=0x410ee930)
> E/AndroidRuntime(31792): FATAL EXCEPTION: main
> E/AndroidRuntime(31792): java.lang.RuntimeException: Failure delivering
> result ResultInfo{who=null, request=1, result=-1, data=null} to activity
> {io.cordova.hellocordova/io.cordova.hellocordova.HelloCordova}:
> java.lang.IllegalStateException: Do not perform IO operations on the UI
> thread. Use Cordova
> Interface.getThreadPool() instead.
> E/AndroidRuntime(31792):at
> android.app.ActivityThread.deliverResults(ActivityThread.java:3319)
> E/AndroidRuntime(31792):at
> android.app.ActivityThread.handleSendResult(ActivityThread.java:3362)
> E/AndroidRuntime(31792):at
> android.app.ActivityThread.access$1100(ActivityThread.java:141)
> E/AndroidRuntime(31792):at
> android.app.ActivityThread$H.handleMessage(ActivityThread.java:1282)
> E/AndroidRuntime(31792):at
> android.os.Handler.dispatchMessage(Handler.java:99)
> E/AndroidRuntime(31792):at android.os
[jira] [Commented] (CB-5034) Document plugin registry
[ https://issues.apache.org/jira/browse/CB-5034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13803220#comment-13803220 ] Mike Billau commented on CB-5034: - Plugman README.md: https://github.com/apache/cordova-plugman/pull/28 Adds registry commands to the README.md file including how to change the registry's URL. `plugman help` already had comments about the registry, these just weren't reflected in the README.md CLI help command: https://github.com/apache/cordova-cli/pull/48 Adds the search command to the CLI's help file. Currently the CLI is unable to set the registry for plugman so I did not include the config set commands yet (filed CB-5185 for this) readme.md: Forgot to add the registry stuff in the above pull request; created a new request based off of the updated README.md: https://github.com/apache/cordova-cli/pull/61 Command-line Interface guide: It looks like Mike Sierra and Michael Brooks beat me to it with https://github.com/apache/cordova-docs/commit/8b1b333d3fd37ad256c3c2a8894dc4405c61bc19. This adds a line about how the plugins use a registry and how plugin add will take the plugin id, along with some examples of "advanced plugin usage." Looks great. It doesn't talk about using 3rd party registries but I think that can wait until the CLI can change plugman's registry. Sorry that it took me a little while to get to this. > Document plugin registry > > > Key: CB-5034 > URL: https://issues.apache.org/jira/browse/CB-5034 > Project: Apache Cordova > Issue Type: Bug > Components: Docs, Registry >Affects Versions: Master >Reporter: Mike Billau >Assignee: Mike Billau > > I can't find any reference to the plugin registry anywhere in our > documentation. Am I looking in the wrong place or are we waiting for the web > component to be more polished before announcing the registry? > I think some places the registry should be mentioned: > Plugman: readme.md > CLI: > cordova help command (CB-5031) > readme.md > docs: > http://cordova.apache.org/docs/en/edge/guide_cli_index.md.html#The%20Command-line%20Interface > (I think it's best to split the "Add Platforms" section into "Add > Platforms" and "Add Plugins", and in this new section talk about adding > plugins, automatic plugin installation (plugin dependencies), and the > registry) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CB-4982) "cordova plugin add" help text should show how to install plugin by git url plus branch and subdir
[ https://issues.apache.org/jira/browse/CB-4982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau reassigned CB-4982: --- Assignee: Mike Billau > "cordova plugin add" help text should show how to install plugin by git url > plus branch and subdir > -- > > Key: CB-4982 > URL: https://issues.apache.org/jira/browse/CB-4982 > Project: Apache Cordova > Issue Type: Improvement > Components: CLI >Affects Versions: Master > Environment: cordova 3.1.0-0.1.0 >Reporter: Shazron Abdullah >Assignee: Mike Billau >Priority: Minor > > when you run cordova with no arguments, the "Project Level Commands" section, > "plugin add" parameter has help text on how to install a plugin by git url, > but nothing about how to specify a branch and a subdir. > A branch is specified by a hash, and subdir with a colon. > For example, this uses the "plugins" branch, and the subdir of "keyboard": > https://git-wip-us.apache.org/repos/asf/cordova-labs.git#plugins:keyboard -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CB-5185) CLI should expose Plugman's Registry actions
Mike Billau created CB-5185:
---
Summary: CLI should expose Plugman's Registry actions
Key: CB-5185
URL: https://issues.apache.org/jira/browse/CB-5185
Project: Apache Cordova
Issue Type: Bug
Components: CLI
Affects Versions: 3.2.0
Environment: Windows 7
Reporter: Mike Billau
Priority: Minor
If you run plugman without arguments, the help text does a great job explaining
how to interact with the registry, listing commands like:
{noformat}
plugman info plugin
plugman config set registry {url}
plugman config get registry
{noformat}
Unfortunately these do not seem to be accessible via the CLI, which means the
Web Platform vs Native Platform workflows are different. If we are going to be
supporting (or at least mentioning) 3rd party registries, both workflows should
be equal.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CB-5052) Andorid's media capture doesn't use ThreadPool
[
https://issues.apache.org/jira/browse/CB-5052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13802218#comment-13802218
]
Mike Billau commented on CB-5052:
-
The workaround in the stack overflow post just disables threadChecking before
calling out to webView.getResourceApi().mapUriToFile(data); then re-enables
threadChecking, so I'm not sure that this is an actual solution (the workaround
DOES work fine btw.) Regardless we can't take photos or videos on Android
(well, Nexus 7 and S4)...not sure how this slipped through the release testing.
> Andorid's media capture doesn't use ThreadPool
> --
>
> Key: CB-5052
> URL: https://issues.apache.org/jira/browse/CB-5052
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, Plugin Media Capture
> Environment: Windows 7
>Reporter: Mike Billau
>Assignee: David Kemp
>
> From:
> http://stackoverflow.com/questions/19282318/phongap-capture-plugin-crashes-android
> Taking a picture with media-capture plugin will crash the app when the plugin
> returns from the camera app. Reproduced with Nexus 7 on 4.2, I used the
> simple Full Example from the docs.
> Got this in logcat:
> {noformat}
> I/ActivityManager( 476): Displayed
> com.google.android.gallery3d/com.android.camera.CameraActivity: +1s80ms
> W/IInputConnectionWrapper(31792): showStatusIcon on inactive InputConnection
> V/CAM_PhotoModule(29129): Preview size is 960x720
> V/CAM_PhotoModule(29129): onShutterButtonClick: mCameraState=1
> E/NvOmxCamera( 128): OMX_ERRORTYPE
> android::NvOmxCamera::getCameraStereoMode(NvxComponent*,
> NvOmxCameraUserStereoMode&): Error: invalid NVX mode 0.
> E/NvOmxCamera( 128): OMX_ERRORTYPE
> android::NvOmxCamera::getCameraStereoModeAndCaptureInfo(NvxComponent*,
> NvOmxCameraUserStereoMode&, NVX_STEREOCAPTUREINFO&): getCameraStereoMode
> failed with 0x
> D/NvOsDebugPrintf( 128): NvMMLiteJPEGEncSetAttribute: Incorrect value 0 for
> stereo capture type
> E/NvOmxCameraSettings( 128): OMX_ERRORTYPE
> android::programStereoInfo(OMX_HANDLETYPE, const NVX_STEREOCAPTUREINFO&,
> android::NvxWrappers*): pNvxWrappers->OMX_SetConfigIL failed with 0x80001005
> V/CAM_PhotoModule(29129): mShutterToRawCallbackTime = 1381355622457ms
> V/CAM_PhotoModule(29129): mShutterLag = 422ms
> D/dalvikvm(29129): GC_FOR_ALLOC freed 679K, 15% free 1K/14236K, paused
> 27ms, total 28ms
> I/dalvikvm-heap(29129): Grow heap (frag case) to 13.063MB for 1036816-byte
> allocation
> D/NvOsDebugPrintf( 128): Tryproc: INBuffer-Values of Width and Height 1280
> 960
> D/dalvikvm(29129): GC_FOR_ALLOC freed 1K, 14% free 13233K/15252K, paused
> 33ms, total 33ms
> V/CAM_PhotoModule(29129): mShutterToPostViewCallbackTime = 88ms
> V/CAM_PhotoModule(29129): mShutterToRawCallbackTime = 109ms
> V/CAM_PhotoModule(29129): mPictureDisplayedToJpegCallbackTime = 25ms
> D/CameraStorage(29129): External storage state=mounted
> V/CAM_PhotoModule(29129): mJpegCallbackFinishTime = 2ms
> I/MPL-storeload( 476): mpl state size = 5512
> E/MPL-storeload( 476): calData from inv_save_mpl_states, size=2
> I/MPL-storeload( 476): cal data size to write = 5512
> I/MPL-storeload( 476): Bytes written = 5512
> V/CAM_PhotoModule(29129): stopPreview
> D/( 128): Camera fd close (MI1040)
> E/NvOmxCamera( 128): Already called release()
> I/CameraClient( 128): Destroying camera 0
> W/NvOmxCamera( 128): Already called release()
> D/MediaProvider(27296): object removed 2270
> W/AudioFlinger( 128): session id 453 not found for pid 128
> W/AudioFlinger( 128): session id 454 not found for pid 128
> D/CordovaActivity(31792): Request code = 1
> D/AndroidRuntime(31792): Shutting down VM
> W/dalvikvm(31792): threadid=1: thread exiting with uncaught exception
> (group=0x410ee930)
> E/AndroidRuntime(31792): FATAL EXCEPTION: main
> E/AndroidRuntime(31792): java.lang.RuntimeException: Failure delivering
> result ResultInfo{who=null, request=1, result=-1, data=null} to activity
> {io.cordova.hellocordova/io.cordova.hellocordova.HelloCordova}:
> java.lang.IllegalStateException: Do not perform IO operations on the UI
> thread. Use Cordova
> Interface.getThreadPool() instead.
> E/AndroidRuntime(31792):at
> android.app.ActivityThread.deliverResults(ActivityThread.java:3319)
> E/AndroidRuntime(31792):at
> android.app.ActivityThread.handleSendResult(ActivityThread.java:3362)
> E/AndroidRuntime(31792):at
> android.app.ActivityThread.access$1100(ActivityThread.java:141)
> E/AndroidRuntime(31792):at
> android.app.ActivityThread$H.handleMessage(ActivityThread.java:1282)
> E/AndroidRuntime(31792):at
> android.os.Handler.dispatchMessage(Handler.java:99)
> E/AndroidRuntime(31792):at android.os.Looper.loop(Looper.java:137)
> E/AndroidRuntime(31792):
[jira] [Resolved] (CB-5117) Android's bin/check_reqs should report success
[ https://issues.apache.org/jira/browse/CB-5117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau resolved CB-5117. - Resolution: Fixed Fix Version/s: 3.2.0 > Android's bin/check_reqs should report success > -- > > Key: CB-5117 > URL: https://issues.apache.org/jira/browse/CB-5117 > Project: Apache Cordova > Issue Type: Bug > Components: Android > Environment: Windows 7 >Reporter: Mike Billau >Priority: Minor > Fix For: 3.2.0 > > > Running the /bin/check_reqs script will report errors if there is a problem > with your ant, java, or Android SDK versions. If there are no problems, it > remains silents - it'd be nice for some positive feedback so that you know > that the script worked and nothing is wrong. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CB-5175) Fix core plugins that incorrectly run on main thread
Mike Billau created CB-5175: --- Summary: Fix core plugins that incorrectly run on main thread Key: CB-5175 URL: https://issues.apache.org/jira/browse/CB-5175 Project: Apache Cordova Issue Type: Bug Components: Docs, Plugin Device Orientation, Plugin File, Plugin Media Reporter: Mike Billau Priority: Minor After CB-4133 we are able to detect and log when a plugin incorrectly does work on the UI thread instead of a worker thread. We should go back and verify that all of our plugins follow this practice - eat your own dogfood type of thing. We know there are problems with: Android: file, compass iOS: media Docs: Need to verify plugin author guide is still valid -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CB-5122) Document supported workflows
Mike Billau created CB-5122:
---
Summary: Document supported workflows
Key: CB-5122
URL: https://issues.apache.org/jira/browse/CB-5122
Project: Apache Cordova
Issue Type: Bug
Components: Docs
Affects Versions: 3.1.0
Reporter: Mike Billau
Assignee: Mike Billau
Based on the recent discussion here[1], we should document the two different
supported Cordova workflows: using the CLI, and using plugman and bin scripts.
Some of this documentation already exists but needs to be clarified and
improved:
Overview guide --> "Development Paths" section[2]. This talks about getting
started with the CLI and then mentions that you can switch to the
platform-specific SDK tools. This section should be rewritten to make it clear
that there are two distinct workflows, and that both are okay and supported. It
could list out some pros and cons of each workflow (I'm sure we won't have any
trouble finding those ;)). It should be prescriptive in that users should be
following one of the two workflows, but it shouldn't make any statements about
which is better.
"The Command-line Interface" guide --> The "CLI workflow" guide. It generally
looks complete except for some missing functionality that is documented in the
CLI's README.md file (tests, hooks, some commands (serve), some merges info).
Platform Guides --> {Platform} --> {Platform} Command-line tools --> Each
platform has a "Command-line tools" doc that explains all of the command line
tools for that project and how to use them. We need to go through these guides
and verify that they are up to date and include all of the lower level command
line tools and scripts. It should read like a tutorial in the same way that the
Command-line Interface guide does.
"Using Plugman to Manage Plugins" [3] First, this guide needs to get exposed; I
can't find any way to get to this guide from the docs and even had to ask a
user how she managed to find it (a link from Plugman's readme!). This guide
needs to be expanded quite a bit; we can probably fold most/all of Plugman's
README.md file into this guide since it will be platform agnostic.
I think those are the only pieces in the docs that need to be changed.
[1] http://callback.markmail.org/thread/5nr7dgkquse4gdkl
[2] http://cordova.apache.org/docs/en/edge/guide_overview_index.md.html#Overview
[3]http://cordova.apache.org/docs/en/edge/plugin_ref_plugman.md.html
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CB-5122) Document supported workflows
[
https://issues.apache.org/jira/browse/CB-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Billau updated CB-5122:
Description:
Based on the recent discussion here [1]we should document the two different
supported Cordova workflows: using the CLI, and using plugman and bin scripts.
Some of this documentation already exists but needs to be clarified and
improved:
{{Overview guide --> "Development Paths" section}}. This talks about getting
started with the CLI and then mentions that you can switch to the
platform-specific SDK tools. This section should be rewritten to make it clear
that there are two distinct workflows, and that both are okay and supported. It
could list out some pros and cons of each workflow (I'm sure we won't have any
trouble finding those ;)). It should be prescriptive in that users should be
following one of the two workflows, but it shouldn't make any statements about
which is better.
{{"The Command-line Interface" guide}} --> The "CLI workflow" guide. It
generally looks complete except for some missing functionality that is
documented in the CLI's README.md file (tests, hooks, some commands (serve),
some merges info).
{{Platform Guides --> (Platform) --> (Platform) Command-line tools}} --> Each
platform has a "Command-line tools" doc that explains all of the command line
tools for that project and how to use them. We need to go through these guides
and verify that they are up to date and include all of the lower level command
line tools and scripts. It should read like a tutorial in the same way that the
Command-line Interface guide does.
{{"Using Plugman to Manage Plugins"}} [3] First, this guide needs to get
exposed; I can't find any way to get to this guide from the docs and even had
to ask a user how she managed to find it (a link from Plugman's readme!). This
guide needs to be expanded quite a bit; we can probably fold most/all of
Plugman's README.md file into this guide since it will be platform agnostic.
I think those are the only pieces in the docs that need to be changed.
[1] http://callback.markmail.org/thread/5nr7dgkquse4gdkl
[2] http://cordova.apache.org/docs/en/edge/guide_overview_index.md.html#Overview
[3]http://cordova.apache.org/docs/en/edge/plugin_ref_plugman.md.html
was:
Based on the recent discussion here [1], we should document the two different
supported Cordova workflows: using the CLI, and using plugman and bin scripts.
Some of this documentation already exists but needs to be clarified and
improved:
{{Overview guide --> "Development Paths" section}}[2]. This talks about getting
started with the CLI and then mentions that you can switch to the
platform-specific SDK tools. This section should be rewritten to make it clear
that there are two distinct workflows, and that both are okay and supported. It
could list out some pros and cons of each workflow (I'm sure we won't have any
trouble finding those ;)). It should be prescriptive in that users should be
following one of the two workflows, but it shouldn't make any statements about
which is better.
{{"The Command-line Interface" guide}} --> The "CLI workflow" guide. It
generally looks complete except for some missing functionality that is
documented in the CLI's README.md file (tests, hooks, some commands (serve),
some merges info).
{{Platform Guides --> (Platform) --> (Platform) Command-line tools}} --> Each
platform has a "Command-line tools" doc that explains all of the command line
tools for that project and how to use them. We need to go through these guides
and verify that they are up to date and include all of the lower level command
line tools and scripts. It should read like a tutorial in the same way that the
Command-line Interface guide does.
{{"Using Plugman to Manage Plugins"}} [3] First, this guide needs to get
exposed; I can't find any way to get to this guide from the docs and even had
to ask a user how she managed to find it (a link from Plugman's readme!). This
guide needs to be expanded quite a bit; we can probably fold most/all of
Plugman's README.md file into this guide since it will be platform agnostic.
I think those are the only pieces in the docs that need to be changed.
[1] http://callback.markmail.org/thread/5nr7dgkquse4gdkl
[2] http://cordova.apache.org/docs/en/edge/guide_overview_index.md.html#Overview
[3]http://cordova.apache.org/docs/en/edge/plugin_ref_plugman.md.html
> Document supported workflows
>
>
> Key: CB-5122
> URL: https://issues.apache.org/jira/browse/CB-5122
> Project: Apache Cordova
> Issue Type: Bug
> Components: Docs
>Affects Versions: 3.1.0
>Reporter: Mike Billau
>Assignee: Mike Billau
>
> Based on the recent discussion here [1]we should document the two different
> supported Cordova workflows: using the
[jira] [Updated] (CB-5122) Document supported workflows
[
https://issues.apache.org/jira/browse/CB-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Billau updated CB-5122:
Description:
Based on the recent discussion here [1]we should document the two different
supported Cordova workflows: using the CLI, and using plugman and bin scripts.
Some of this documentation already exists but needs to be clarified and
improved:
{{Overview guide --> "Development Paths" section}}. This talks about getting
started with the CLI and then mentions that you can switch to the
platform-specific SDK tools. This section should be rewritten to make it clear
that there are two distinct workflows, and that both are okay and supported. It
could list out some pros and cons of each workflow (I'm sure we won't have any
trouble finding those ;)). It should be prescriptive in that users should be
following one of the two workflows, but it shouldn't make any statements about
which is better.
{{"The Command-line Interface" guide}} --> The "CLI workflow" guide. It
generally looks complete except for some missing functionality that is
documented in the CLI's README.md file (tests, hooks, some commands (serve),
some merges info).
{{Platform Guides --> (Platform) --> (Platform) Command-line tools}} --> Each
platform has a "Command-line tools" doc that explains all of the command line
tools for that project and how to use them. We need to go through these guides
and verify that they are up to date and include all of the lower level command
line tools and scripts. It should read like a tutorial in the same way that the
Command-line Interface guide does.
{{"Using Plugman to Manage Plugins"}} First, this guide needs to get exposed; I
can't find any way to get to this guide from the docs and even had to ask a
user how she managed to find it (a link from Plugman's readme!). This guide
needs to be expanded quite a bit; we can probably fold most/all of Plugman's
README.md file into this guide since it will be platform agnostic.
I think those are the only pieces in the docs that need to be changed.
[1] http://callback.markmail.org/thread/5nr7dgkquse4gdkl
[2] http://cordova.apache.org/docs/en/edge/guide_overview_index.md.html#Overview
[3] http://cordova.apache.org/docs/en/edge/plugin_ref_plugman.md.html
was:
Based on the recent discussion here [1]we should document the two different
supported Cordova workflows: using the CLI, and using plugman and bin scripts.
Some of this documentation already exists but needs to be clarified and
improved:
{{Overview guide --> "Development Paths" section}}. This talks about getting
started with the CLI and then mentions that you can switch to the
platform-specific SDK tools. This section should be rewritten to make it clear
that there are two distinct workflows, and that both are okay and supported. It
could list out some pros and cons of each workflow (I'm sure we won't have any
trouble finding those ;)). It should be prescriptive in that users should be
following one of the two workflows, but it shouldn't make any statements about
which is better.
{{"The Command-line Interface" guide}} --> The "CLI workflow" guide. It
generally looks complete except for some missing functionality that is
documented in the CLI's README.md file (tests, hooks, some commands (serve),
some merges info).
{{Platform Guides --> (Platform) --> (Platform) Command-line tools}} --> Each
platform has a "Command-line tools" doc that explains all of the command line
tools for that project and how to use them. We need to go through these guides
and verify that they are up to date and include all of the lower level command
line tools and scripts. It should read like a tutorial in the same way that the
Command-line Interface guide does.
{{"Using Plugman to Manage Plugins"}} [3] First, this guide needs to get
exposed; I can't find any way to get to this guide from the docs and even had
to ask a user how she managed to find it (a link from Plugman's readme!). This
guide needs to be expanded quite a bit; we can probably fold most/all of
Plugman's README.md file into this guide since it will be platform agnostic.
I think those are the only pieces in the docs that need to be changed.
[1] http://callback.markmail.org/thread/5nr7dgkquse4gdkl
[2] http://cordova.apache.org/docs/en/edge/guide_overview_index.md.html#Overview
[3]http://cordova.apache.org/docs/en/edge/plugin_ref_plugman.md.html
> Document supported workflows
>
>
> Key: CB-5122
> URL: https://issues.apache.org/jira/browse/CB-5122
> Project: Apache Cordova
> Issue Type: Bug
> Components: Docs
>Affects Versions: 3.1.0
>Reporter: Mike Billau
>Assignee: Mike Billau
>
> Based on the recent discussion here [1]we should document the two different
> supported Cordova workflows: using the CLI, and
[jira] [Updated] (CB-5122) Document supported workflows
[
https://issues.apache.org/jira/browse/CB-5122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Billau updated CB-5122:
Description:
Based on the recent discussion here [1], we should document the two different
supported Cordova workflows: using the CLI, and using plugman and bin scripts.
Some of this documentation already exists but needs to be clarified and
improved:
{{Overview guide --> "Development Paths" section}}[2]. This talks about getting
started with the CLI and then mentions that you can switch to the
platform-specific SDK tools. This section should be rewritten to make it clear
that there are two distinct workflows, and that both are okay and supported. It
could list out some pros and cons of each workflow (I'm sure we won't have any
trouble finding those ;)). It should be prescriptive in that users should be
following one of the two workflows, but it shouldn't make any statements about
which is better.
{{"The Command-line Interface" guide}} --> The "CLI workflow" guide. It
generally looks complete except for some missing functionality that is
documented in the CLI's README.md file (tests, hooks, some commands (serve),
some merges info).
{{Platform Guides --> (Platform) --> (Platform) Command-line tools}} --> Each
platform has a "Command-line tools" doc that explains all of the command line
tools for that project and how to use them. We need to go through these guides
and verify that they are up to date and include all of the lower level command
line tools and scripts. It should read like a tutorial in the same way that the
Command-line Interface guide does.
{{"Using Plugman to Manage Plugins"}} [3] First, this guide needs to get
exposed; I can't find any way to get to this guide from the docs and even had
to ask a user how she managed to find it (a link from Plugman's readme!). This
guide needs to be expanded quite a bit; we can probably fold most/all of
Plugman's README.md file into this guide since it will be platform agnostic.
I think those are the only pieces in the docs that need to be changed.
[1] http://callback.markmail.org/thread/5nr7dgkquse4gdkl
[2] http://cordova.apache.org/docs/en/edge/guide_overview_index.md.html#Overview
[3]http://cordova.apache.org/docs/en/edge/plugin_ref_plugman.md.html
was:
Based on the recent discussion here[1], we should document the two different
supported Cordova workflows: using the CLI, and using plugman and bin scripts.
Some of this documentation already exists but needs to be clarified and
improved:
Overview guide --> "Development Paths" section[2]. This talks about getting
started with the CLI and then mentions that you can switch to the
platform-specific SDK tools. This section should be rewritten to make it clear
that there are two distinct workflows, and that both are okay and supported. It
could list out some pros and cons of each workflow (I'm sure we won't have any
trouble finding those ;)). It should be prescriptive in that users should be
following one of the two workflows, but it shouldn't make any statements about
which is better.
"The Command-line Interface" guide --> The "CLI workflow" guide. It generally
looks complete except for some missing functionality that is documented in the
CLI's README.md file (tests, hooks, some commands (serve), some merges info).
Platform Guides --> {Platform} --> {Platform} Command-line tools --> Each
platform has a "Command-line tools" doc that explains all of the command line
tools for that project and how to use them. We need to go through these guides
and verify that they are up to date and include all of the lower level command
line tools and scripts. It should read like a tutorial in the same way that the
Command-line Interface guide does.
"Using Plugman to Manage Plugins" [3] First, this guide needs to get exposed; I
can't find any way to get to this guide from the docs and even had to ask a
user how she managed to find it (a link from Plugman's readme!). This guide
needs to be expanded quite a bit; we can probably fold most/all of Plugman's
README.md file into this guide since it will be platform agnostic.
I think those are the only pieces in the docs that need to be changed.
[1] http://callback.markmail.org/thread/5nr7dgkquse4gdkl
[2] http://cordova.apache.org/docs/en/edge/guide_overview_index.md.html#Overview
[3]http://cordova.apache.org/docs/en/edge/plugin_ref_plugman.md.html
> Document supported workflows
>
>
> Key: CB-5122
> URL: https://issues.apache.org/jira/browse/CB-5122
> Project: Apache Cordova
> Issue Type: Bug
> Components: Docs
>Affects Versions: 3.1.0
>Reporter: Mike Billau
>Assignee: Mike Billau
>
> Based on the recent discussion here [1], we should document the two different
> supported Cordova workflows: using the CLI, and us
[jira] [Commented] (CB-5117) Android's bin/check_reqs should report success
[ https://issues.apache.org/jira/browse/CB-5117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798268#comment-13798268 ] Mike Billau commented on CB-5117: - Here is a pull request: https://github.com/apache/cordova-android/pull/79 Still wrapping my head around Q.js so any hints or comments are appreciated. > Android's bin/check_reqs should report success > -- > > Key: CB-5117 > URL: https://issues.apache.org/jira/browse/CB-5117 > Project: Apache Cordova > Issue Type: Bug > Components: Android > Environment: Windows 7 >Reporter: Mike Billau >Priority: Minor > > Running the /bin/check_reqs script will report errors if there is a problem > with your ant, java, or Android SDK versions. If there are no problems, it > remains silents - it'd be nice for some positive feedback so that you know > that the script worked and nothing is wrong. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-5119) Android's bin/check_reqs fails with spaces
[ https://issues.apache.org/jira/browse/CB-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13798170#comment-13798170 ] Mike Billau commented on CB-5119: - Fails when there are spaces in the path. > Android's bin/check_reqs fails with spaces > -- > > Key: CB-5119 > URL: https://issues.apache.org/jira/browse/CB-5119 > Project: Apache Cordova > Issue Type: Bug > Components: Android > Environment: Windows 7 >Reporter: Mike Billau >Priority: Minor > > If you have a path with a space in it, running the check_reqs script will > fail. Thought this was a bit odd since the create script will work even with > spaces. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CB-5119) Android's bin/check_reqs fails with spaces
Mike Billau created CB-5119: --- Summary: Android's bin/check_reqs fails with spaces Key: CB-5119 URL: https://issues.apache.org/jira/browse/CB-5119 Project: Apache Cordova Issue Type: Bug Components: Android Environment: Windows 7 Reporter: Mike Billau Priority: Minor If you have a path with a space in it, running the check_reqs script will fail. Thought this was a bit odd since the create script will work even with spaces. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CB-5117) Android's bin/check_reqs should report success
Mike Billau created CB-5117: --- Summary: Android's bin/check_reqs should report success Key: CB-5117 URL: https://issues.apache.org/jira/browse/CB-5117 Project: Apache Cordova Issue Type: Bug Components: Android Environment: Windows 7 Reporter: Mike Billau Priority: Minor Running the /bin/check_reqs script will report errors if there is a problem with your ant, java, or Android SDK versions. If there are no problems, it remains silents - it'd be nice for some positive feedback so that you know that the script worked and nothing is wrong. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CB-4518) Battery "level" is not calculated correctly
[
https://issues.apache.org/jira/browse/CB-4518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797995#comment-13797995
]
Mike Billau commented on CB-4518:
-
Not sure if these are the same issues or not...
> Battery "level" is not calculated correctly
> ---
>
> Key: CB-4518
> URL: https://issues.apache.org/jira/browse/CB-4518
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android
>Affects Versions: 2.9.0
>Reporter: Peter
>Assignee: Joe Bowser
>Priority: Minor
>
> The meaning of the Battery "level" in Cordova is a charge *percentage*.
> Ref
> http://cordova.apache.org/docs/en/2.9.0/cordova_events_events.md.html#batterylow
> But the Battery EXTRA_LEVEL is not a percentage. It's just a number in the
> range 0 to EXTRA_SCALE
> Ref
> http://developer.android.com/reference/android/os/BatteryManager.html#EXTRA_LEVEL
> So the battery level calculation should be something like:
> {code}
> int level = batteryIntent.getIntExtra(android.os.BatteryManager.EXTRA_LEVEL,
> 0);
> int scale = batteryIntent.getIntExtra(android.os.BatteryManager.EXTRA_SCALE,
> 100);
> int percent = 100 * level / scale;
> obj.put("level", percent);
> {code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (CB-4725) device.cordova returns 'dev' on Android
[ https://issues.apache.org/jira/browse/CB-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Billau resolved CB-4725. - Resolution: Fixed Looks like it's fixed. > device.cordova returns 'dev' on Android > --- > > Key: CB-4725 > URL: https://issues.apache.org/jira/browse/CB-4725 > Project: Apache Cordova > Issue Type: Bug > Components: Android, Plugin Device >Affects Versions: 3.0.0 > Environment: Android >Reporter: Stefan Dobrev >Assignee: Andrew Grieve >Priority: Minor > > device.cordova returns 'dev' on Android platform. Expected value is '3.0.0' -- This message was sent by Atlassian JIRA (v6.1#6144)
