Simulate Tab Limitations

Running Your App in the Simulate Tab Differs from Running on a Real Device

The Intel® XDK Simulate Tab approximately simulates your app on a virtual device. It is directly based on the Microsoft* Cordova Simulate tool that is part of the Apache* Cordova* project.

There are significant limitations between the simulator and a real device. When running your app run in the simulator:

  • It runs on your development computer, not on an actual mobile device. Your development computer has different processor(s), memory, and networking capabilities, so your app runs faster and more reliably in the simulator than on real mobile devices. The performance seen under simulation is completely unrelated to that seen on a real device!

  • It runs in simulated system code, not actual system code. The simulator is not an instruction-level device simulator, so it cannot directly use actual sensors found only on mobile devices. That is, the simulator provides replacement routines for some host system routines, including the native parts of many Apache Cordova* plugins.

  • It runs in a browser built on your development system’s web runtime that simulates the web runtime (WebView) on a device. Your app is run in a frame whose dimensions match the selected virtual device. Within that frame, a few device-specific properties, such as the navigator.userAgent string and window.screen object, are assigned values that correspond to the selected device. When compared to a real device’s runtime, the simulator’s runtime may implement HTML5 features more accurately, may implement newer HTML5 features more completely and often has fewer bugs. Your app will look and behave differently when it runs under simulation compared to running on a real device!

You should think of the Simulate tab as a Cordova API simulator that provides you with a convenient viewport to help you visualize the approximate layout of your app on various devices. It does not simulate real devices nor does it simulate third-party Cordova plugin APIs. Getting your app to work in the Simulate tab is not a guarantee that it will work on a real device. Conversely, if things work on a real device but do not work in the Simulate tab, that is not an indication that your app is "broken." The only way to know with certainty that your app works as intended is to build it and install it on real devices.

Use the device simulator to quickly debug and test your app before you test and debug it on actual device(s). For more details about:

Using Media Queries in the Device Simulator

The simulator will see all the media queries in the program under test, but it only knows how to evaluate a few forms of media query, and not for all simulated device conditions. For example, if you have a media query that tests something like "-webkit-min-device-pixel-ratio:2" your CSS would be correctly applied when simulating an iPad3 (pixel ratio = 2) but not when simulating a Droid2 (pixel ratio = 1.5).

More complicated media queries are left unaltered by the simulator. This means they get evaluated by the host system's web runtime and are subject to the host system interpretation. For example, media query tests that inspect "device-width" and "device-height" may provide incorrect results. Because your development system monitor is usually large your media queries will always return the "large screen" option, regardless of the selected simulation device. In that case, you may have better luck using "width" and "height" instead of "device-width" and "device-height."

Use the clause "if(window._cordovaSimulate)" to check for execution of your app in the device simulator; if the result is "true" you are executing within the Simulate tab. (To detect the now retired Emulate tab you would have checked for "if(window.tinyHippos)").

Supported Plugin APIs in the Device Simulator

In addition to the Intel Security APIs, the following core Cordova Plugins are simulated:

Using the App Security API Plugin in the Device Simulator

If your app uses the App Security API plugin, please be aware that the device simulator’s emulation of the App Security API does not provide any real security. When you test using the device simulator, no cryptography is used (hardware or software), so do not use sensitive data for your testing.

Unhandled Exec Call

The appearance of an "unhandled exec call" dialog is not an error. It will appear when your code calls any Cordova plugin API that is not simulated. In those instances you will see a popup similar to the following:

In this dialog you can specify whether the call to the non-simulated Cordova plugin API should return a success or failure and, optionally, what value it should return to the code that made the call to that plugin API within the simulator. The appearance of this "unhandled exec call" simply means the simulator has encountered an API that it does not understand, and is offering you the option to "simulate" a return to that that API so your app can continue executing.

Unsupported Media Formats

Certain media files will not play in the device simulator because of either missing CODECs in the simulator or legal issues that restrict the use of certain media CODECs. Within the device simulator you cannot play .mp3 or .mp4 files. Apps that use these files should be tested when you run your app on your actual test devices.

Plugin Native Code Limitations

The simulator does not support the "native code" component of a plugin (even those that are listed above). It relies on JavaScript "simulation" code that is provided by the Cordova plugin author. This means that even those plugins that include support for the simulator will be limited to the functionality of the simulation code provided by that plugin author. In other words, even those plugins that are supported in the simulator are not guaranteed to behave in the simulator like they do on a real device.

For example, see this forum post regarding the network information plugin for some discrepancies that have been noted between the simulated plugin and the real plugin.

Resources

For more complete information about compiler optimizations, see our Optimization Notice.