Cordova Plugins Overview

Cordova's core is deliberately small. It gives you a WebView and the machinery to bridge JavaScript calls to native code, but it does not ship with camera access, GPS, file access, or any other device feature baked in. Every one of those capabilities comes from a plugin that you add to your project explicitly. This page explains what a plugin actually is under the hood, how to manage plugins with the Cordova CLI, where to find them, and gives you a map of the native-device plugins this track covers next.

What a Plugin Actually Is

A Cordova plugin is really two matched halves glued together by the Cordova bridge:

HalfWhat it contains
Native sideReal platform code — Java or Kotlin for Android, Swift or Objective-C for iOS — that calls the actual device API (the real camera, the real GPS radio, the real filesystem)
JavaScript sideA small JS API installed into your www/ project (things like navigator.camera.getPicture()) that your app code calls directly, exactly like any other JavaScript function

When your JavaScript calls a plugin method, Cordova's bridge serializes that call, hands it to the matching native code, waits for the native side to do its (often asynchronous) work, and then routes the result back to your JavaScript success or error callback. You never write the native Java/Swift code yourself — you only consume the JavaScript API the plugin author wrote on top of it.

Installing a Plugin

Plugins are added from the project root using the Cordova CLI. Once added, the plugin's native code is automatically merged into every platform you've added (Android, iOS), and its JavaScript API becomes available globally in your app after deviceready fires.

cordova plugin add cordova-plugin-camera

You can also install a plugin from a specific version on npm, a local folder, or a git repository URL — useful when you need a fork or a version pinned for compatibility:

cordova plugin add cordova-plugin-camera@6.0.0
cordova plugin add ../my-local-plugin
cordova plugin add https://github.com/some-user/cordova-plugin-fork.git

Listing and Removing Plugins

It's easy to lose track of which plugins a project already has, especially once several native-device features are wired in. cordova plugin ls (or its longer alias cordova plugin list) prints every plugin currently installed, along with its version:

cordova plugin ls

Typical output looks like this — a plugin ID followed by its installed version:

cordova-plugin-camera 6.0.0 "Camera"
cordova-plugin-device 2.1.0 "Device"
cordova-plugin-geolocation 4.1.0 "Geolocation"

To remove a plugin you no longer need, use cordova plugin remove (or the shorter rm alias) followed by the plugin's ID exactly as it appears in the list above:

cordova plugin rm cordova-plugin-camera
Note: Removing a plugin deletes its native code from your platform folders on the next build, but it does not remove calls to that plugin's JavaScript API from your own code — clean those up yourself, or your app will throw errors calling a function that no longer exists.

Where to Find Plugins

Plugins are ordinary npm packages, so the same registry you'd search for any JavaScript package doubles as the plugin catalog. Two good starting points:

SourceWhat you'll find
Apache Cordova Plugin registryA searchable listing of plugins, historically at cordova.apache.org/plugins, indexing packages published under the cordova-plugin-* naming convention
npm searchSince plugins are npm packages, searching npm search cordova-plugin or browsing npmjs.com directly surfaces the same packages, often with more up-to-date download and maintenance stats

Core Plugins vs. Community Plugins

Not all plugins carry the same level of trust. It helps to think of them in two tiers:

TierWhat to expect
Core pluginsPlugins historically maintained under the Apache Cordova project itself (camera, device, geolocation, network-information, file, splash screen, and a handful of others). These have a long track record and go through the Apache release process, though maintenance activity varies plugin to plugin over time.
Community pluginsEverything else — plugins built and maintained by individual developers or third-party organizations for features core plugins don't cover (Bluetooth, biometrics, push notifications, in-app purchases, and more). Quality, documentation, and how actively they're maintained vary enormously from one to the next.
Before you depend on a community plugin: check its npm page for the last publish date, open GitHub issues, and whether it's been updated for the Android/iOS SDK versions you're targeting. A plugin last touched several years ago may still work, or may silently break on a newer OS — test early rather than assuming.

The Native-Device Plugins This Track Covers

The next several lessons walk through the most commonly used core plugins in detail, one at a time. Here's the map of what's coming and why each one matters:

PluginWhat it gives your app
CameraTake a photo with the device camera, or pick an existing photo from the library
GeolocationRead the device's current GPS position, or watch position changes continuously
DeviceRead basic device info — platform, OS version, model, and a unique device identifier
Network InformationDetect the current connection type (Wi-Fi, cellular, none) and react to online/offline changes
FileRead and write files in sandboxed, permission-scoped storage directories on the device
Splash ScreenControl the launch splash image shown while your app's WebView is still loading
Status BarControl the color, style, and visibility of the OS status bar at the top of the screen
In-App BrowserOpen external web links in a controlled in-app window instead of leaving your app
Push NotificationsReceive and react to push messages sent to the device from a remote server

Always Wait for deviceready

Every plugin JavaScript API attaches itself to the global scope only after Cordova has fully initialized the native bridge — which is exactly what the deviceready event signals, covered in detail in the previous lesson. Calling a plugin method before that event fires is one of the single most common Cordova bugs: the function may not exist yet, or the native bridge may not be ready to service the call.

document.addEventListener('deviceready', onDeviceReady, false);

function onDeviceReady() {
    // Safe: deviceready has fired, every installed plugin's JS API is ready
    navigator.camera.getPicture(onSuccess, onError, { quality: 75 });
}

function onSuccess(imageData) {
    // Handle the captured image here
}

function onError(message) {
    console.log('Camera error: ' + message);
}
Rule of thumb: if a line of code calls anything hanging off navigator, device, or cordova.*, it belongs inside (or after) your onDeviceReady handler — never at the top level of a script that runs immediately on page load.
Up next: Start putting this into practice with the Camera Plugin, the first native-device plugin covered in full detail.