- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As i know the Crosswalk android should using the Chrome web view to wrap/embedded cordova app(correct me if i m wrong)
But in Debug mode, my native input like Select Option/Date picker is in well Holo Theme
but after build and open, it show as the theme before ICS, attach with screen shot of my issue
- Tags:
- HTML5
- Intel® XDK
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jack, I'm trying to get some clarification from the build engineer about why this is happening, may take a while to resolve.
Regarding "wrapping in Chrome" -- this is not quite what happens. What you see in the browser is unique to the browser, it does not appear to be using the native date picker, rather, it is using something of it's own design. The Crosswalk webview is based on the Chromium project, but it is not Chrome and the runtime engine used by your mobile Chrome browser is not used to execute your app. At compile time a Crosswalk runtime engine is included with your app and your app is executed by this runtime engine, not by the Chrome browser installed on your device. So while many things will look and behave similarly to the Chrome browser (because the Crosswalk engine is based on the same Chromium project), there are differences. In this case, the mobile browser IS NOT using the native picker and the Crosswalk engine IS using the native picker. So the issue is why does the debug module use the Holo themed picker and the built apps use the earlier themed pickers?
---- update ----
I spoke with the build engineer and we isolated the reason behind this. The debug modules are pre-built projects that get modified, because they include extra code that would not be part of your built app. It turns out that in those pre-built projects they have specified the Android Holo theme, but in the standard Cordova apps the theme is specified as the original "black" theme. This is what is causing the difference.
It may be possible to change this behavior with a plugin, which I hope to try, assuming I get enough time.
I will be filing a bug in order to resolve this difference.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Because debug mode uses crosswalk and assuming you might be building with android for device. So I would recommend using Crosswalk for device too.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Amrita C. (Intel) wrote:Yes, i m build the app with xdk crosswalk Android, embedded ver 15, min API level = 17, target 22
Because debug mode uses crosswalk and assuming you might be building with android for device. So I would recommend using Crosswalk for device too.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok! Can you check this first with some existing sample? Build with crosswalk and math the behavior after debugging.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jack -- are you using a custom debug module in the "debug" example or the "default" debug module with the Debug tab? If you are using a custom debug module, then I'm guessing that something is awry with the build settings being used by the custom debug module builder (or with the standard build).
If you could attach a simple project that illustrates the issue, I can use that to investigate and get in front of the engineers.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
p.s. What is the device and the version of Android on that device, the device that you are using for these tests?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Paul F. (Intel) wrote:
p.s. What is the device and the version of Android on that device, the device that you are using for these tests?
Hi Paul,
i got several testing device for the picker,
(i) Google Nexus 5, version 5.1.1 and now update to version 6.0
(ii) Xiao Mi 3, version 4.4
(iii) Samsung Note 2, version 4.4
(iv) Sony Xperia Z1, version 5.0
(v) Asus ZenFone 2, version 5.1.1
All display in different view on Chrome Browser, Debug Mode and Actual Build APK installed App
(if not wrong, crosswalk should be wrap the app with Chrome engine and it should look like what i get in Chrome)
Attach again with test project screen shot and project file
Click to download project file(Google Drive Share Link, no worry, its not virus)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jack, I'm trying to get some clarification from the build engineer about why this is happening, may take a while to resolve.
Regarding "wrapping in Chrome" -- this is not quite what happens. What you see in the browser is unique to the browser, it does not appear to be using the native date picker, rather, it is using something of it's own design. The Crosswalk webview is based on the Chromium project, but it is not Chrome and the runtime engine used by your mobile Chrome browser is not used to execute your app. At compile time a Crosswalk runtime engine is included with your app and your app is executed by this runtime engine, not by the Chrome browser installed on your device. So while many things will look and behave similarly to the Chrome browser (because the Crosswalk engine is based on the same Chromium project), there are differences. In this case, the mobile browser IS NOT using the native picker and the Crosswalk engine IS using the native picker. So the issue is why does the debug module use the Holo themed picker and the built apps use the earlier themed pickers?
---- update ----
I spoke with the build engineer and we isolated the reason behind this. The debug modules are pre-built projects that get modified, because they include extra code that would not be part of your built app. It turns out that in those pre-built projects they have specified the Android Holo theme, but in the standard Cordova apps the theme is specified as the original "black" theme. This is what is causing the difference.
It may be possible to change this behavior with a plugin, which I hope to try, assuming I get enough time.
I will be filing a bug in order to resolve this difference.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Paul F. (Intel) wrote:
I spoke with the build engineer and we isolated the reason behind this. The debug modules are pre-built projects that get modified, because they include extra code that would not be part of your built app. It turns out that in those pre-built projects they have specified the Android Holo theme, but in the standard Cordova apps the theme is specified as the original "black" theme. This is what is causing the difference.
It may be possible to change this behavior with a plugin, which I hope to try, assuming I get enough time.
I will be filing a bug in order to resolve this difference.
Note, because i still new to cordova and no idea on the plugin and those manifest thing....
Thanks for your asssit :) waiting your good new here
(p/s: about the native, I think the Chrome is using the correct native picker because Android 5.0 above should no longer using the Holo Theme,
if possible can the plugin to get the correct theme base on device OS version? because i test with Chrome, 4.4 in Holo and 5.0 above should in material design)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I took a look into this and I don't see an easy way to change this with the current plugin options. This would require a change to the build system to use a special directive. This is a feature request that I will write up, but not something that will happen very soon. Sorry.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Paul F. (Intel) wrote:
I took a look into this and I don't see an easy way to change this with the current plugin options. This would require a change to the build system to use a special directive. This is a feature request that I will write up, but not something that will happen very soon. Sorry.
Hi Paul,
I found apost in stackoverflow had mention about the theme can be change by change the manifest,please refer to below
Don't worry - fixed it myself. For those who want to know, there is the following tag set in the default manifest file. By default, this is set to:
android:theme="Theme.Black.NoTitleBar"
Changing it to the following fixed it:
android:theme="Theme.DeviceDefault"
http://stackoverflow.com/questions/19766268/phonegap-3-x-android-native-popup-dialog-theme
--------------- End -------------------------
but the manifest is auto generate in intel xdk (although i follow the guide from FAQ 14
- Is it possible to modify Android* Manifest through Intel XDK?
the theme still stay in theme black (android 2 theme),
my custom plugin.xml can get from my google drive, please correct me if my plugin is create wrongly
https://drive.google.com/file/d/0B6OWGY1bCBPJVWhJRmhqRUU3SHM/view?usp=sharing
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The reason a simple plugin won't fix this is due to the way this feature is added to the AndroidManifest.xml file. It is highly dependent on what you are building. Here's an example of what I mean:
<activity android:configChanges="orientation|keyboardHidden|keyboard|screenSize|locale" android:label="@string/app_name" android:name="AppAnalyzer" android:theme="@android:style/Theme.Holo.NoActionBar"> <intent-filter> <action android:name="com.intel.app_analyzer.v12.XWALK" /> <category android:name="android.intent.category.DEFAULT" /> </intent-filter> </activity>
This is an excerpt from a custom debug module that is forcing the Holo theme. Notice that it is part of a multi-line XML directive, so the normal tool you can use with a Cordova plugin.xml file to add one-line directives, with a simple plugin, may not work. We have to change the build system to make this work right. I've filed a request to change this, but I do not know how long it will take to make the change.
Go ahead and give yours a try, it may be that adding something like you've done to the AndroidManifest.xml will override prior statements. I don't know enough about how the AndroidManifest.xml file is parsed to say with certainty.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page