Ionic 1.0.1 + Amazon = Cordova: Class not found?


#1

Upgrading to the latest Ionic (1.0.1) and Cordova (5.2.0) (npm update -g cordova ionic), starting a new project (and adding Amazon FireOS support), and then attempting to run on a Kindle Fire, I get this fun error message:

[ERROR] Error initializing Cordova: Class not found

Error is shown on startup. Watching the adb log output, the failure seems to be when Cordova is attempting to log the plugins, each failing with things like the following:

D/PluginManager(13205): in getPlugin for service - Device
D/PluginManager(13205): exec() call to unknown plugin: Device

Previous versions seemed to work just fine, but for some reason this new release stopped working. A little detective work shows that my platforms/amazon-fireos/res/xml/config.xml isn’t being populated with the plugin references like it used to, missing lines like:

<feature name="Device">
    <param name="android-package" value="org.apache.cordova.device.Device" />
</feature>

Android seems to be working just fine with the latest, just not Amazon’s. I do see the plugins listed just fine in the plugins/amazon-fireos.json file, so in theory it should work.

An “ionic platform” run shows that it’s still using Cordova’s v3.6.3 for Amazon, the same as what I’ve used for past Ionic versions (including 1.0.1) without problem, so my guess is that somewhere in the Ionic CLI there was a change that broke Amazon support (and probably similar to Cordova’s issue back in Jan where it assumed all platforms are alphabetical-only, and don’t contain things like dashes in the name).

Anyone else experiencing issues?


#2

Should mention that a platform reset (ionic platform remove amazon-fireos; ionic platform add amazon-fireos) doesn’t help. All signs point to the updated Ionic CLI, from what I can tell.


#3

I’ve kept digging, and can see the cordova_plugins.js file generated correctly (can see listings for all of my Cordova plugins). Problem only seems to be the generation of the res/xml/config.xml file during build time; everything else in the directory tree appears to be built correctly.

Narrowing down the issue, at least.


#4

If anyone is interested, I found the problem:

https://issues.apache.org/jira/browse/CB-6414

Turns out there’s a recent change deep in Cordova where, for compatibility sake, it’s possible that a plugin can reference the config file two different ways. There was a patch done a few months ago to support this in Android, but other Android derivatives, such as Amazon-FireOS.

Until Cordova can fix, there are two ways to fix yourself:

  1. Make sure all of your plugins reference the config file directly (changing <config-file target=“config.xml”> to <config-file target=“res/xml/config.xml”>)

  2. In ConfigKeeper.js (on my Mac, it’s installed at /usr/local/lib/node_modules/cordova/node_modules/cordova-lib/src/plugman/util/), change this line in get():

    if(file == ‘config.xml’ && platform == ‘android’){

to:

if(file == ‘config.xml’ && (platform == ‘android’ || platform == ‘amazon-fireos’)){

Never did find the plugin that just referenced “config.xml” instead of “res/xml/config.xml”, so resorted to fix #2, which seems to have solved the problem.


#5

Finally found the offending plugin: cordova-plugin-file. Apparently a recent revision to the plugin now adds an “AndroidPersistentFileLocation” reference to the config.