Feature Detection

What features can you detect on KaiOS?

Summary. KaiOS has two APIs, navigator.getFeature() and navigator.hasFeature, for detecting device and platform features. These APIs require the feature-detection permission.

Here is a simple TypeScript definition for the Feature Detection API on KaiOS 2.5:

1interface Navigator {
2    getFeature(name: string): Promise<any>;
3    hasFeature(name: string): Promise<boolean>;
4}

On KaiOS 3.0, the DeviceCapabilityManager API is loaded from http://shared.localhost/js/session/device_capability/device_capability.js and shortens getFeature to just get. The hasFeature API was removed in KaiOS 3.0. Here is an example for each KaiOS version:

1// KaiOS 2.5
2navigator.getFeature('hardware.memory')
3    .then((mem) => (mem === 256) ? /* TODO */ : /* TODO */)
4
5// KaiOS 3.0 (assumes DeviceCapabilityManager has been loaded)
6DeviceCapabilityManager.get('hardware.memory')
7    .then((mem) => (mem === 256) ? /* TODO */ : /* TODO */)

Why use Feature Detection?

Feature Detection is a common paradigm in mobile apps to support graceful degradation and provide user-friendly error messages. For instance, if your application requires a certain capability like Bluetooth, you might display a fatal error message and not allow the user to proceed. Alternatively, you might adapt based on hardware limitations (i.e. device memory) and downsample images, or change how input is gathered on a T9 vs QWERTY device. Finally, you might enable advanced features to certain users if they have Developer Mode enabled.

For example, pre-installed apps use feature detection (esp. hardware.memory) including:

• The Music app disabled the “Share” and “Set Ringtone” on low-memory (256mb) devices, likely because passing audio blobs between apps using Web Activities could result in memory pressure and crashes
• The Gallery app adapts downsampling using the #-moz-samplesize media fragment based on device memory
• The Email and Calendar apps are suppressed on low-memory (256mb) devices
• Apps are instantly terminated when EndCall or GoBack is pressed on low-memory devices, unless they’re playing background audio

Background

Q: Why use navigator.hasFeature when you can just check if certain properties exist?

Per Bug #1009645:

The entire purpose of this API is so that we can hide properties such as navigator.mozBluetooth for contexts where the web page lacks the required permissions in order to be able to call into the API.

That was for Firefox OS from 10 years ago. Many (but not all) KaiOS APIs will be set to null or completely unavailable unless the necessary permissions and app level are met.

Feature Table

Below is a list of features that can be detected using the Feature Detection API.

❗ Important: for features that return a boolean (true or false), use navigator.hasFeature. For all other features, use navigator.getFeature!

Miscellaneous Features

⚠️ Warning: some of the features above (i.e. capabilities.sandboxedCookies) are KaiOS 2.5 specific, since the corresponding APIs or permissions were removed in KaiOS 3.0.

Manifest Properties

ℹ️ Note: the above manifest features are hard-coded to return true.

Device Capabilities (KaiOS 2.5)

Device Capabilities (KaiOS 3.0)

ℹ️ More Info: in addition to the device capabilities above, KaiOS 3.0 exposes several more build properties. See devicecapability.json included in API Daemon.

Platform APIs

In fact, you can check any FeatureDetectible property. For instance, navigator properties like api.window.Navigator.fota and api.window.Navigator.spatialNavigationEnabled, or B2G API properties like api.window.MozNFC.enabled and api.window.KeyboardEventGenerator.generate (even if your app doesn’t have permission to use these APIs).

Behind the Scenes

The logic in Configuration.py shows that any non-test API defined in WebIDL with the CheckAnyPermissions, CheckAllPermissions, or AvailableIn annotation is accessible to feature detection. In this context, the Feature Detection API returns what the device is capable of, not what your app is allowed to do.

Conclusion

The KaiOS Feature Detection API is simple, but useful. Just a few lines of code can prevent user confusion, avoid errors, and tailor the user experience to different devices. However, the Feature Detection API is not a substitute for general feature detection. It is still important to check for the presence of certain platform-specific APIs, and to catch errors (i.e. SecurityError) in case permissions are rejected or the device does not support certain capabilities. If you would like to build a world-class KaiOS experience for your business that adapts based on device capabilities and characteristics, contact the author from the About page.

• Previous
  KaiOS Open Source Resources
• Next
  Special Keys on KaiOS