The device publishers write device information through the platform's publish-subscribe services when users attach or detach devices. Your applications can read this information and use it to access media content and decide what to synchronize and play.
Figure 1. Device Monitoring and Information Retrieval
Detecting device attachments
Device publishers don't physically detect when users attach or detach devices. Other OS-layer processes—device drivers and protocol stacks—monitor I/O hardware for physical state changes that indicate device attachments or detachments (e.g., SD card insertions or USB device connections). Because they interface with hardware, the drivers and stacks contain up-to-date details on the physical connectivity and mountpoints of devices. The publishers must communicate with these other processes to learn of device attachments and detachments.
Obtaining device information
Different publishers use different methods for obtaining the latest device information. The usblauncher publisher queries the USB stack process for device information (for details, see “The USB Launcher Service” in the Device Publishers Developer's Guide). The mmcsdpub publisher monitors specific /dev paths and when it notices new or updated entries, it communicates with the drivers to obtain device information (for details, see “Role of device drivers”).
Publishing device, driver, and filesystem information
After retrieving information about newly attached devices from other OS processes, the publishers output this information through the platform's publish-subscribe services. The publishers use different data types for storing device connectivity, driver process, and filesystem information.
When publishers learn from a driver or protocol stack process that a device has been detached, they write updated information indicating the device is no longer present.
Publishing additional device information
For MTP and Apple devices, additional information is published by the driver. The MTP driver publishes the software version, manufacturer name, vendor name, and the last time that media content was modified on the device. The modification time is republished whenever media content is added, modified, or deleted.
With Apple devices, the extra information written depends on which protocol the device runs; for details, see the documentation installed with the Apple components in the QNX Multimedia Suite.
Detecting devices in media applications
Before your applications can synchronize or play any media, they must learn which devices (or mediastores) are attached to your system. To readily receive information about newly attached devices, your applications must monitor updates to the device-related data types through the publish-subscribe services. This information includes the mountpoints, which your applications can use to explore mediastore filesystems to find media tracks.
For example, when a USB device is inserted, its default mountpoint is /fs/usb0. The publisher that monitors USB device attachments and removals (usblauncher) publishes this mountpoint information.
Other information fields can help you enforce media policies. For instance, suppose that you want to restrict playback to certain types of mediastores. By examining the media_type field, your application can play tracks on some device types (say, audio CDs) but ignore tracks on other device types (say, DVDs).
For more information on detecting mediastores, see the first two steps of the process described in the “Synchronizing metadata from mediastores” section in the Multimedia Synchronizer Developer's Guide.