Device Storage
#
DescriptionThe Device Storage API is used to access the file system within a Web app. Accessing the file system can be highly sensitive, and for that reason this API is available for privileged apps only.
Note: Accessing device storage is slow due to a limitation at the physical level. In many cases it can be faster to use an IndexedDB database to store files instead of physical device storage.
#
Accessing device storageThis section explains what is needed to access device storage.
#
Entry pointIt's possible to access storage areas by using the navigator.getDeviceStorage()
and navigator.getDeviceStorages()
methods:
navigator.getDeviceStorage()
accepts a string parameter representing the name of the default storage area to be accessed. The method returns a DeviceStorage object, which is used to access the related storage area. It returns the storage area whose .default attribute is true. This is controlled by the user via Settings App > Media Storage > Default media location.navigator.getDeviceStorages()
on the other hand accepts a string representing the name of the storage area to be accessed, and returns an Array of DeviceStorage objects, one per physical storage area.
KaiOS provides the following storage names:
apps
This storage area is used to store the user data needed by apps. As it is critical data, accessing this storage area requires some extra privileges (see below) and is available to certified applications only.music
This is the storage area where music and sounds are stored.pictures
This is the storage area where pictures are stored.sdcard
This is the storage area that grants access to the device's SDCard. sdcard is also used as the name of the device's default internal storage, which is a bit unfortunate and potentially confusing; be aware.videos
This is the storage area where videos are stored.
#
Accessing different storage areas with navigator.getDeviceStorages()When using navigator.getDeviceStorages()
, if there is more than one storage area then the internal one will be named for example sdcard
and the physical storage area will be called something else (sometimes it's extsdcard
, sometimes it's sdcard1
). This varies by device manufacturer. The names of files on the sdcard storage area will be /sdcard/path/filename
, and the names of files on the sdcard1
storage area will be /sdcard1/path/filename
, or whatever.
Note that the /sdcard
and /sdcard1
are storage names. Their actual mount points on the system are determined via vold and/or /system/etc/volume.cfg
file.) DeviceStorage
transparently maps the storageName
into the actual mountPoint
(so you don't need the mount point if you're just accessing the files through device storage).
If you want to determine the mount point to examine the filesystem from an adb shell, then you can determine the vold mount points by using the command adb shell vdc volume list (this requires a root shell).
On the Flame, you'll see something like this:
For volumes that aren't managed by vold the mount point is found in /system/etc/volume.cfg
.
Note: In Gaia engineering builds there is a ds-test app, which is useful for device storage testing.
#
Device storage permissionsTo be able to use these storage areas, the application must declare them in its application manifest. For example, if the application wants to access the sdcard storage area, it must have the "device-storage:sdcard"
permission in its manifest.
As mentioned above, using device-storage:apps
also needs some extra permissions, in the form of the webapps-manage permission, which allows access to the navigator.mozApps.mgmt
API for managing installed open web apps.
All of the device-storage name permissions are privileged level, except for apps, which is certified. webapps-manage is certified level.
#
Using a storageOnce an application gets access to a storage area, it's possible to add, get and remove files inside the area.
#
Add a fileAdding a file is done using the addNamed or add methods. The former allows to set an explicit name when storing a file while the latter creates a name automatically when the file is stored. Both methods are asynchronous and return a DOMRequest
object to handle the success or error of the operation. This is very important as writing and reading files on a physical support is a slow process.
Those two methods expect a Blob as their first parameter. This object will be turned into a file under the hood and stored. When creating a Blob object, it's mandatory to give it a type. This type, which is a MIME type, is important because some storage areas have restrictions based on the type:
- music only accepts Blob with a valid audio MIME type
- pictures only accepts Blob with a valid image MIME type
- videos only accepts Blob with a valid video MIME type
Note: Repositories in a storage area are implicit. It's not possible to create explicitly an empty repository. If you want to use a repository structure you have to make it part of the name of the file to store. So if you want to store the file bar inside the foo repository, you have to use the addNamed method with the complete path name of the file addNamed(blob, "foo/bar"). This is also true when you want to retrieve a file using its name (see below).
As files are added in a given restricted storage area for security reasons, a file path name cannot start with "/" nor "../" (and "./" is pointless).
#
Get a fileRetrieving a file can be done in two ways: by using its name or by iterating the whole list of files.
The easiest way is to retrieve a file by its name using the get
and getEditable
methods. The former provides a File
object (which act like a read only file) when the latter provides a FileHandle
object (which allows updating the underlaying file). Both methods are asynchronous and return a DOMRequest
object to handle the success or error of the operation.
The other way to retrieve files is by browsing the content of the storage area. This is possible using the enumerate and enumerateEditable methods. The former provides File
objects when the latter provides FileHandle
objects. Both methods are asynchronous and return a DOMCursor
object to iterate along the list of files. A DOMCursor
is nothing less than a DOMRequest
with extra power to iterate asynchronously along a list of things (files in that case).
It's possible to limit the number of results by passing two optional parameters to the enumerate
and enumerateEditable
methods.
- The first parameter can be a string representing a sub folder to search inside.
- The second parameter can be an object with a since property, which allows you to limit the search to a given time period.
#
Delete a fileA file can be removed from the storage area by simply using the delete
method. This method just needs the name of the file to delete. As all the other methods from the DeviceStorage
interface, this one is also asynchronous and returns a DOMRequest
object to handle the success
or error
of the operation.
#
Storage informationBeyond accessing files, a storage area provides a few methods to easily reach some important information
#
Available spaceOne of the most important things to know when storing files on a device is the amount of space available. The DeviceStorage interface provides two useful functions dedicated to space:
- freeSpace() to get the amount of free space available to store new files;
- usedSpace() to get the amount of space used to store the files;
As those methods are asynchronous, they return a DOMRequest
object to handle the success or error of the operation.
#
Listening for changeAs many applications can use a same storage area at the same time, it's sometimes useful for an application to be aware of a change in that storage area. It's also useful for an application performing an asynchronous action because it doesn't have to relay on all the DOMRequest
objects returned by each method of the DeviceStorage
interface.
To that end, a change event is triggered each time a file is created, modified or deleted. This event can be captured using the onchange
property or the addEventListener()
method. The event handler gets a DeviceStorageChangeEvent object which is a regular Event
object with two extra properties:
DeviceStorageChangeEvent.reason
which gives the reason of the change (created, modified or deleted).DeviceStorageChangeEvent.path
which gives the full path to the file affected by the change.