Ace gives your Cordova app the power of native code. Not just the ability to use specific native UI controls, but the ability to invoke any native APIs.
As a developer, you have some control over the capabilities granted to your app. This is independent from Ace and Cordova. In Android, for example, you control this with an AndroidManifest.xml file. A typical Cordova project uses an auto-generated version of this file (found in the platforms/android subfolder), but you can modify this file. And because the platforms folder is typically excluded from source control, Ace projects typically place the master copy of the modified file in the native/android subfolder, which will get copied to the right spot at build time. The AceExamples project does this in order to override the app theme and to request permission for the vibration capability:
<uses-permission android:name="android.permission.VIBRATE" />
This enables the app’s vibration code to succeed:
If the advice of “Don’t execute untrusted code” is universally true, why is it even worth pointing out here? Well, when building a native app with other technologies, you need to go out of your way to load arbitrary, untrusted Web content in a context that gives it more power than a typical Web browser. When building an app with Cordova, however, it’s much easier to load arbitrary, untrusted Web content.
Fortunately, Cordova has protections in place to help you avoid loading untrusted Web content. It uses domain whitelisting to restict access to external domains. It also uses the W3C Content Security Policy (CSP) to tightly control a number of things, such as eval() and inline script. Make sure to use these mechanisms properly to avoid exposing the native power of any Cordova plugin (Ace being just one example) improperly.