You are here: Foswiki>Dmi Web>WinterSchool2020SleepingScore (31 Jan 2020, AnneHelmond)Edit Attach
Who knows your sleeping score?
A critical analysis of companion mobile apps (CMAs) of fitness-tracking wristbands and their connection to third-party software
Team Members
Team members: Rimmert Sijtsma and Anne Schmitz Part of the project: 'Apps and Their Practices: A comparative issue analysis across app stores and countries' Facilitated by Esther Weltevrede and Anne HelmondSummary of Key Findings
Within our research project we analyzed mobile apps, which accompany fitness wristbands in terms of how the infrastructure of the apps connect to third-party software, especially in terms of intimate user data. We used a two layers-approach for our analysis. On a first layer we analyzed metadata of twelve popular companying mobile apps within the google play store and informations about the Software Development Kits (SDK) these apps consist, captured via appbrain. Our research question in regards to this layer is: How are companion mobile apps (CMA) for fitness wristbands manage the infrastructure of intimate user data? On a second layer we analyzed what kind of developer ecosystems are embedded in the infrastructure(s) behind fitness-tracking wristbands, using Fitbit as a case study. We captured the data of their own developer webpage. Our main findings are that all selected apps ask for quite similar user permission when it comes to access to specific mobile phone functions. Huawei Health with 42 permissions demands for the most amount of access, whereas Moov and Tomtom require the least amount of permissions (19). Even though they vary in number, they typically comprise the same categories of permissions. The most frequently requested permissions are “modify or delete the contents of your USB storage” (24), “Read the contents of your USB storage” (24), “Find accounts on the device” (21), “Read phone status and identity” (20) as well as “View network connections” (12). The first four are classified as dangerous in terms of their protection level. Similar permissions seem to be the norm within these kinds of apps. Additionally, the libraries, which are used in regards to these apps, show a relatively homogeneous picture. In total, there are three overarching types: ad libraries, social libraries and development tools. In our sample only a small number of ad libraries (4) are found, as well as only three different social libraries can be identified. In terms of the development tools up to 89 are used, but also here, it seems to be quite standardized, which types of development tools are included. They can be categorized into 31 different types of development tools, whereas so-called “support” and “open-source” libraries are the most used types. In total, the average number of SDK per CMA is 30,3 (std. dev = 12,6). Based on these results and the high level of standardization in the app-specific developer environment, we shifted our focus towards a broader perspective and the multitude of infrastructures within the context of fitness-trackers and their companion mobile apps. With infrastructure we mean various software solutions which enable the communication between the app, the phone and the wearable using Fitbit as a case study. We can conclude that Fitbit provides 13 different APIs, of which seven are wearable-specific and five are app-specific. Moreover, additional permissions are needed for third-party software to function on the Fitbit infrastructure. The developer reference guide showed 11 permissions that developers need to access all functionalities of the development ecosystem. Also here six are wearable-specific and five are app-specific. All in all, the findings highlight a normative standard for using permissions that request far-fetching access to intimate user data. Given the opacity of these third-party software libraries, more scholarly attention is beneficial to understand the infrastructures that flow behind the scenes of these daily app-routines.Introduction
Fitness-tracker wristbands and other kinds of activity-wearables gained widespread popularity within the last years (Lui, 2019). They allow users to track a vast range of data regarding their sleep, activity, calories, heart rate or other body-related informations. In most cases the use of the trackers require the download of an companion app on the mobile phone, which is connected to the wearable. The app then makes it possible to observe and analyze the development of the measured data over time. However, to enable all functions and for the most accurate analysis possible, the users must feed all kind of information about themselves into the app and allow various access to permissions on the mobile phone, such as their location. Consequently, these fitness and activity-trackers and the companion apps constantly collect intimate data through permissions, which are oftentimes not understood by users (Kelley et al., 2012). Even though the data collected via these devices is highly protected and regulated within the EU, as it contains valuable information about the state of health of humans, criticism is repeatedly voiced that there are major security gaps in the trackers and apps, especially due to the wireless connections through which the data circulates between the wearable and the app (Karp, n.d.). Against this background the aim of our research project is to focus on the mobile apps, which are needed to use the fitness-tracker wristbands. Through an analysis of the permissions that companion mobile apps (CMAs) request users to accept and the software development kits (SDKs) used to support the CMAs, we have created an initial cartography of the infrastructure behind Fitness-tracker wristbands and their CMAs. This question has already found some resonance in previous literature. Recent work has covered the data flows of dating apps to analyze how they deal with intimate data (Weltevreden & Jansen, 2019), how the utilities of platforms are shaped by the ecosystems in which platforms are embedded (Tiwana, 2014) and discussed the privacy issues of wearable devices (Taylor, Hagen, Dincelli, & Unsworth, 2017). Another strand of research has studied how these wearable devices are worn on a day-to-day basis (Gilmore, 2016) and mediate body and relationship (Wissinger, 2017), specifically raising questions about the autonomy of users. This research project is similar in terms of its scope to the work of Weltevrede & Jansen (2019), who set out to analyze ways to hold apps accountable for the practices they engage in regarding the exchange of data within the infrastructure of the app. In doing so, this research project raises questions about the normative standards that surround this “everywear” (Gilmore, 2016) through a digital methods approach.Initial Data Sets
Our method for generating our data sample ran in three consecutive steps. In the first step we searched the currently most popular fitness trackers on the market. Through the analysis of market reports and querying Google Search, we found several brands that ranked highly across the results. From major brands, such as Samsung, Huawei and Fitbit, to smaller brands such as Health Mate and Moov Coach. In the second step, we searched for the companying apps fo the fitness-trackers in step one. As a third step we looked up and compared the number of downloads each CMA has in the Google Play Store and ranked them, according to the respective download rates, which resulted in a list of twelve CMAs within our sample (See table 1). It has to be noted, that we had to exclude the Apple Watch from our sample, even though it is extremely popular, as we could not access the same level of data as we could for the more open Google Play Store. This is something that should be looked into in further research projects. The most downloaded CMAs were the Samsung Health and Huawei Health apps, with respectively 500 000 000 and 100 000 000 downloads in the Google Play Store. Although these apps are pre-installed on either the Samsung branded or Huawei branded smartphones, they still rank highly in the popularity lists of fitness-tracker wristbands. On the one hand the sampling procedure based on the download rate enables us to include different kinds of CMAs, on the other hand the requirements for using the apps are of different types, which weakens comparability.Research Questions
Given the goal of this research project to analyze the infrastructure behind fitness-tracker wristbands and their CMAs, we will answer the following research questions in the remaining parts of this research report: How do companion mobile apps (CMAs) manage the infrastructure of intimate user data?- What kind of permissions do the companying mobile apps require the user to accept?
- What kind of Software Development Kits do they consist of?
- Which API(s) are present?
- What specific permissions (mobile phone and wearable) are requested?
- How is the wearable-specific hardware, such as sensors, used?
Methodology
Stage I: the CMAs
Starting with our initial data set, we looked up every CMA on our list in the Google Play Store and noted their number of downloads and the permissions they request. This data was stored in spreadsheets for further analysis. In parallel, the SDKs used per CMA were manually collected via the website appbrain.com. This website provides information about the Android ecosystem and allows developers to gain insight into ways to promote, analyze and monetize their applications. In this case, the website was appropriated to make a data set containing all the SDKs used by the CMAs. An SDK belongs to either one of three categories. Namely, ad libraries, social libraries or developer tools. By querying the appbrain.com website for a specific CMA, a list of SDKs can be found. A limitation to this method is that appbrain.com allows only five queries per day for clients without login credentials. To speed up the process, we made use of the desktops available at the University of Amsterdam to circumvent the query limitation. In total, we found 89 unique SDKs within the sample of CMAs. We then categorized each of the unique SDKs by querying them one by one in Google Search (see table 6 in appendix). This was done to decrease the amount of SDKs as we oftentimes found their names (Swift, Brave, Panda, Yoga, etcetera) to be rather uninsightful. The category was often synthesized from the description the developer gives to the SDK in question. For example, the software ‘Joda’ provides libraries to aid developers. This SDK was thus dubbed a ‘support library’. Due to time limitations, this process was fully done by hand, but there is certainly a case to be made for automating the process of collecting and categorizing SDKs when the sample size increases. After collecting the required data, we visualized the spreadsheets with the help of the DensityDesign Team using the RawGraphs software (figure 3). We have chosen to integrate both the permissions and SDK Types into a single alluvial diagram. In this way, one can immediately see how one CMA is connected to the different permissions and the SDK Types. The diagram is color-coded per CMA, to create unity on both sides of the visualisation. The permissions and SDK Types are ranked according to their total count of appearances.Stage II: the Fitbit ecosystem
To gain a better understanding of the Fitbit ecosystem, we have analyzed the permissions specific to the ecosystem, the Fitbit APIs open to developers and sensors used by Fitbit wristbands and thus the infrastructure(s) behind this specific fitness-tracker. With infrastructure we mean various software solutions which enable the communication between the app, the phone and the wearable using Fitbit as a case study. Our method of this stage can be found in figure 2. The data for this stage have been collected from the development documents that Fitbit offers on https://dev.fitbit.com/build/guides/ and https://dev.fitbit.com/build/reference/. From the guide we noted the permissions that developers can work with to get access to data captured by the Fitbit device (the wristband) or the companion (the Fitbit CMA). The specific APIs that work with each permission was also noted. In some occasions, the document also referenced which sensor was available with that specific permission. If this was the case, we noted it. Lastly, we coded each API whether it was for the device or companion. The output of this undertaking can be found in table 8 in the appendix. Having collected the data regarding the permissions, APIs and sensors, we have visualized the flow of connections within the Fitbit device and between the device and CMA in an alluvial diagram. This follows the approach of Weltevrede and Jansen (2019) where the apps are not seen as a single object of study but “as mediators of visible and invisible data relationships”. From left to right, it starts with the Fitbit device, the sensors that are used, the permissions that are required for the sensors, the APIs that connect to the permissions and, finally, whether the API is specific to the device or the companion. Following the diagram, we can see that in order to read the Heart Rate sensor, developers need to use the device-specific API ‘Device.Heart-rate’ that needs the Heart Rate permission to be accepted by the user.Findings
RQ 1: How do companion mobile apps (CMAs) manage the infrastructure of intimate user data?
Permissions
The use of permissions across the sample appears to be quite similar. The mean average of permissions per CMA is 26 (std. dev = 6,38) and the Huawei Health (42) uses the most and TomTom (19) the least. The most used permissions (see table 2) regard the reading and writing on the device’s USB storage and analyzing the device the CMA is installed on. This includes mapping the accounts on the device, the phone status and identity (phone number, state of call, contacts on phone) and view network connections. All CMAs use these permissions. Except for Fitbit and TomTom, who do not request access to the contacts (Fitbit, TomTom) and identity (TomTom). As can be seen in table 2, most of the widely used permission require access to data that is considered as dangerous (i.e. privacy sensitive data) by Android (Android Developers, n.d.). This seems to indicate that the use of ‘dangerous’ data is widely practiced among CMAs. This raises questions regarding the use of intimate data by apps that users are required to download when they want to use the hardware they purchased.| Rank | Permission | Count | Protection level |
| 1. | Modify or delete the contents of your USB storage | 24 | Dangerous |
| 2. | Read the contents of your USB storage | 24 | Dangerous |
| 3. | Find accounts on the device | 21 | Dangerous |
| 4. | Read phone status and identity | 20 | Dangerous |
| 5. | View network connections | 12 | Normal |
Table 2: Top five most used permissions by CMAs. The protection level is indicated on the Android developer website under manifest.permission. The sample consists of 12 CMAs, but some permissions have two categories, which totals some permissions on 24. Besides the most widely used permissions, there are also permissions that are uniquely used across the sample. The Galaxy Wear device requests users to accept the ‘delete apps’ permission. This wearable is the only CMA that asks for this permission. After consulting the Samsung helpdesk, they elaborated that the permission allows the CMA to delete previous versions of the CMA (in order to install an update, for example). Three CMAs (Fitbit, Garmin and Huawei Wear) also request users to allow the CMA to send SMS messages. This permission is also labelled under the protection level ‘dangerous’ by Android. The only permission that seems specific for wearable technology is the ‘body sensors’ permission. This permission, used by Polar, TomTom and Samsung Health, allows the CMAs to access hardware that monitors bodily functions embedded within the smartphone device. It is therefore not specific to wearable technology, but instead offers CMAs access to another data entry point: the smartphone device. Figure 3: Alluvial diagram of the permissions (left), CMAs (middle) and SDK Types (right). The CMAs are color-coded based on their make. The permissions and SDK Types are ranked according to their number of appearances. Designed by DensityDesign for the 2020 DMI Winter School.
Software Development Kits
Having considered the use of permissions by the CMAs, the SDKs will provide insight into how these development environments use third-party software. Similar to the use of permissions, the CMAs do not seem to use specific third-party software for the wristband hardware, which is arguably a highly specific form of hardware. The average number of SDKs per CMA is 30,3 (std. dev = 12,6). The CMA Amazfit uses the most with a total of 49 different SDKs. On the other hand of the spectrum is the Galaxy Wear with a total of five SDKs. Given the broad range of SDKs available, a typology has been made. An overview of the types can be found in table 6 and 7 and the use of SDKs per CMA can be found in figure 3. The most used types are so-called ‘support’ and ‘open-source’ libraries. The support libraries are oftentimes developed by Android to ensure a certain standard by providing ready-made app functions. Open-source libraries, such as Google gson, jsoup, Okio and Twitter Kit, consist of a wide range of software often created for a specific function. The source code of these SDKs are open to the public and are usually serviced by a community of developers. Jsoup, for example, is a Java (a high-level coding language) library that allows users to manipulate and extract data from HTML pages (Jsoup, n.d.). Other highly used types are ‘Developer APIs’ and ‘Analytical platforms’. These APIs are designed to be used by developers (rather than consumers) and provide, among others, integration to Google Maps, PubNub (“Infrastructure-as-a-Service”) (PubNub, n.d.) and Paypal. Just as websites, apps are prone to real-time analytics. These companies, such as Appsee, provide “qualitative app analytics” beyond metrics alone. Appsee boasts the ability of providing real-time individual user-behaviour data for apps that use Appsee (Appsee, n.d). In this sample, only Moov Coach uses the Appsee analytical platform. Of the SDKs used in the sample, the majority are classified as “development tools” (n = 351). The other two classes, ad libraries and social libraries, were used four and seven times, respectively. Out of the four ad libraries, three were used by Mi Fit alone. This CMA thus seems to distinguish itself from the rest of the sample by including three different advertisement libraries within the app. These ad libraries, such as AdMob and MoPub, provide options to monetize apps. Since these ad libraries appear only four times, the CMAs, consequently, do not seem to rely heavily on the use of advertisement business models.RQ 2: What kind of developer ecosystems are embedded in the infrastructure(s) behind fitness tracking wristbands?
Specific APIs
The analysis of the Fitbit developer references highlighted 13 APIs that can be used by developers to access data captured by the Fitbit hardware (see table 8 in appendix). These APIs can be categorized as either device- or companion-specific APIs. In total, there are seven APIs specifically for the device (the wearable) and five for the companion application (see table 4).| Device API | CMA API |
| Device.Body-presence | Companion-Wake-interval |
| Device.Display | Companion.App-cluster-storage |
| Device.Exercise | Companion.Calendars |
| Device.Geolocation | Companion.Fetch |
| Device.Heart-rate | Companion.Geolocation |
| Device.User-activity | Companion.Location-change |
| Device.User-profile |
Specific permissions
Concerning the permissions needed for third-party software to function on the Fitbit infrastructure, the developer reference guide showed 11 permissions that developers need to access all functionalities of the development ecosystem. The permissions are highlighted in table five.| Device permissions | CMA permissions |
| Activity | Run in background |
| Always-on Display | App Cluster Storage |
| Exercise | Calendars |
| Location | Internet |
| Heart Rate | Location |
| User Profile |
Discussion
This study has found that the sample of CMAs request similar permissions and use similar SDKs. Most notably, they use software libraries and Developer APIs in the development of their CMAs. We found no software specific for wearable technology. Furthermore, only four ad libraries were found, which indicates a different business model than the ‘freemium’ model. The similarities between the CMAs arguably reflect a normative standard when it comes to requesting permissions. The CMAs need far-reaching access to the smartphone device in order to function completely. Although the policies provided by the makers of these CMAs do seem to warn against data misuse, the normative standard nevertheless raises concerns about user agency as these apps are required if the fitness-tracker wristband wants to function. The CMA seems a necessary evil for those who want to use the fitness-tracker wristband. Although the use of SDKs seems to be widely accepted, the security risks involved are inneglectible. In their work on Android ad libraries, Book, Pridgen and Wallach (2013) showed that third-party software ad libraries are increasingly making use of the permissions requested by apps. When users accept access to certain permissions by the CMA, they thus also accept the use of these access points by third-party ad libraries. Given the commercial and power relations (Wissinger, 2017) in this industry, the opacity of these ad libraries in combination with intimate data requests more scholarly attention. In their discussion of permissions, Weltevrede and Jansen (2019) approach permissions from the perspective of how they “set the conditions for intimate app data”. In their analysis of 42 dating apps, they found that there are differences between the invasiveness of the apps. The sample used here had one outlier, Huawei Health with 42 permissions, but the rest of the sample all had similar amounts of requested permissions. The similarities of the CMAs shifted the focus of this research to the Fitbit ecosystem as a relevant object of study. It deals with highly intimate data in combination with third-party applications through a non-public development ecosystem. The initial mapping of this ecosystem revealed more specific APIs and permissions that third-party developers can request access to. Permissions, then, seem on the one hand to function as data-gatekeepers, but on the other hand they need to be accepted for the hardware to function as it was originally marketed. This finding is in line with the ‘apps-as-data-relationships-mediators’ approach (Weltevrede & Jansen, 2019). Lastly, we want to highlight again the difficulty of studying platforms and APIs. As they are, to a certain extent, closed systems the data needed to do research is hard to come by. All data that has been used in this study was collected manually by the authors. In a post-API era (Rogers, 2019), it seems even more necessary to discuss the workarounds needed to keep a check on these private platforms, especially when it concerns such intimate user data.Conclusions
With the increase in fitness-tracker wristbands in a post-API era (Rogers, 2019), it becomes ever more relevant to understand how these devices manage the infrastructure of our intimate data. Against this backdrop, this research project has first focussed on the user permissions and software development kits used by the companion mobile apps of popular fitness-tracker wristbands. Then, the Fitbit ecosystem was explored to put the spotlight on the infrastructures that handle intimate data captured through these devices. Yet there remains a lot to be done. Further research could scrutinize the practices of this new space, the Fitbit Gallery (where the third-party apps are available for download), to map which actors are prevalent in this space and what their practices entail. Another strand of research could focus on highlighting some of these CMAs and analyze their business models in more depth (see for example Wilken, Burgess & Albury, 2019). This could shed more light on why certain permissions and SDKs are used. Finally, the methodology used in this research project would benefit from ways to automate the collection of these data. As this would result in larger samples to question both quantitatively and qualitatively.References
Appsee. (n.d.). Features. Retrieved from https://www.appsee.com/features Book, T., Pridgen, A., & Wallach, D. S. (2013, April 18). Longitudinal Analysis of Android Ad Library Permissions. Retrieved from https://arxiv.org/abs/1303.0857 Gilmore, J. N. (2016). Everywear: The quantified self and wearable fitness technologies. New Media & Society, 18(11), 2524–2539. doi: 10.1177/1461444815588768 Jsoup. (n.d.). jsoup Java HTML Parser, with best of DOM, CSS, and jquery. Retrieved from https://jsoup.org/ Karp, K. (n.d.). Wie gehen Fitnesstracker mit Daten um? Retrieved from http://rechtundnetz.com/wie-gehen-fitnesstracker-mit-daten-um/ Kelley, P. G., Consolvo, S., Cranor, L. F., Jung, J., Sadeh, N., & Wetherall, D. (2012). A Conundrum of Permissions: Installing Applications on an Android Smartphone. Financial Cryptography and Data Security Lecture Notes in Computer Science, 68–79. doi: 10.1007/978-3-642-34638-5_6 Lui, S. (2019, May 22). Fitness & activity tracker - Statistics & Facts. Retrieved from https://www.statista.com/topics/4393/fitness-and-activity-tracker/ Rogers, R. (2019). Doing digital methods. Los Angeles: SAGE. Taylor, N. G., Hagen, L., Dincelli, E., & Unsworth, K. (2017, October 24). Wearable devices: Information privacy, policy and user behavior. Retrieved from https://asistdl.onlinelibrary.wiley.com/doi/abs/10.1002/pra2.2017.14505401084 Tiwana, A. (2014). Platform ecosystems: Aligning architecture, governance, and strategy. Amsterdam: Morgan Kaufmann. Weltevrede, E., & Jansen, F. (2019). Infrastructures of Intimate Data: Mapping the Inbound and Outbound Data Flows of Dating Apps. Computational Culture, (7). Wilken, R., Burgess, J., & Albury, K. (2019, October 21). Dating Apps and Data Markets: A Political Economy of Communication Approach. Retrieved from http://computationalculture.net/dating-apps-and-data-markets-a-political-economy-of-communication-approach/ Wissinger, E. (2017). Wearable tech, bodies, and gender. Sociology Compass, 11(11). doi: 10.1111/soc4.12514Appendix
SDK Labels and Types
| SDK Label | SDK Type |
| ACRA | IT Solutions Software |
| ActiveAndroid | Database Library |
| AdMob | Ad Library |
| Alipay | Payment |
| Android Architecture Components | Development Libraries |
| Android Asynchronous Http Client | HTTP Library |
| Android GIF Drawable | UI Component |
| Android Jetpack Annotations | Code Analysis Software |
| Android Jetpack AppCompat | Support Library |
| Android Jetpack Media | Support Library |
| Android Jetpack VersionedParcelable | Support Library |
| Android Jetpack Widgets | Support Library |
| Android Support library | Support Library |
| Android Support Library collections | Support Library |
| Android Support Library Print | Support Library |
| Android Transition Support Library | Support Library |
| Android WorkManager | Job Scheduler |
| Android-Job | Job Scheduler |
| android-wheel | UI Component |
| AndroidSlidingUpPanel | UI Component |
| AndroidSVG | Rendering Library |
| Apache Commons Codec | Development Libraries |
| Apache Commons I/O | IO Library |
| Appsee | Analytical Platform |
| BoltsFramework | Support Library |
| Braze | Analytical Platform |
| Butter Knife | Chart/View Manager |
| CircleImageView | Chart/View Manager |
| CommonsWare Android Components (CWAC) | Open-Source Library |
| Crashlytics | Developer API |
| Dagger | Analytical Platform |
| DragSortListView | UI Component |
| fabric | Development Platform |
| Login Library | |
| Facebook Audience Network | Ad Library |
| FasterXML Jackson | JSON Library |
| Firebase | Developer API |
| Glide | Video-Messaging Platform |
| Google Analytics | Analytical Platform |
| Google Cloud Messaging (GCM) | Developer API |
| Google gson | Open-Source Library |
| Google Guava | Open-Source Library |
| Google Maps SDK | Developer API |
| Google Protocol Buffers | Developer API |
| Google ZXing | Open-Source Library |
| greenDAO | UI Component |
| greenrobot EventBus | Open-Source Library |
| Grpc | Open-Source Framework |
| HockeyApp | Support API |
| IntelliJ IDEA | Development Environment |
| JetBrains Annotations | Code Analysis Software |
| Joda | Support Library |
| jsoup: Java HTML Parser | Open-Source Library |
| Kotlin | Programming Language |
| LeakCanary | Open-Source Library |
| LoganSquare | JSON Library |
| Lottie | Animation Library |
| mixpanel | Analytical Platform |
| MoPub | Ad Library |
| Moshi | JSON Library |
| MPAndroidChart | Chart/View Manager |
| okHttp | HTTP Library |
| Okio | Open-Source Library |
| Optimizely | Analytical Platform |
| Paypal SDK | Developer API |
| PhotoView | UI Component |
| Picasso | Development Environment |
| PubNub | Developer API |
| React Native | Development Framework |
| Reactive Streams | Compatibility Software |
| ReactiveX | Developer API |
| ReLinker | Native Library Loader |
| Retrofit | HTTP Library |
| Simple Logging Facade for Java (SLF4J) | Open-Source ORM |
| Simple XML Serialization | Developer API |
| Smack API | Open-Source Ad API |
| Spongy Castle - Bouncy Castle for Android | Cryptography API |
| StickyListHeaders | UI Component |
| Stripe | Payment |
| SugarORM | Open-Source ORM |
| The Legion of the Bouncy Castle | Cryptography API |
| Timber | Login Library |
| Twitter Kit | Open-Source Library |
| uCrop | UI Component |
| Umeng | Analytical Platform |
| ViewPager indicator | UI Component |
| Volley | HTTP Library |
| Yoga | Cross-Platform Layout Engine |
| ZBar bar code reader | Open-Source Library |
| SDK Type | Type count |
| Support Library | 10 |
| Open-Source Library | 10 |
| UI Component | 9 |
| Developer API | 9 |
| Analytical Platform | 7 |
| HTTP Library | 4 |
| JSON Library | 3 |
| Chart/View Manager | 3 |
| Ad Library | 3 |
| Payment | 2 |
| Open-Source ORM | 2 |
| Login Library | 2 |
| Job Scheduler | 2 |
| Development Libraries | 2 |
| Development Environment | 2 |
| Cryptography API | 2 |
| Code Analysis Software | 2 |
| Video-Messaging Platform | 1 |
| Support API | 1 |
| Rendering Library | 1 |
| Programming Language | 1 |
| Open-Source Framework | 1 |
| Open-Source Ad API | 1 |
| Native Library Loader | 1 |
| IT Solutions Software | 1 |
| IO Library | 1 |
| Development Platform | 1 |
| Development Framework | 1 |
| Database Library | 1 |
| Cross-Platform Layout Engine | 1 |
| Compatibility Software | 1 |
| Animation Library | 1 |
| Total | 89 |
Fitbit APIs and Permissions
| App | Permissions for the Device | Permission description | Related API | Related Sensor |
| Fitbit | Activity | Read user activities for today (distance, calories, steps, elevation and active minutes), daily goals, and activity history. The body presence sensor is used to detect if the device is being worn, or not. | Device.User-activity | n/a |
| Fitbit | Activity | Read user activities for today (distance, calories, steps, elevation and active minutes), daily goals, and activity history. The body presence sensor is used to detect if the device is being worn, or not. | Device.Body-presence | n/a |
| Fitbit | Always-on Display | Allows a developer to enable Always-on Display for their applications and clock faces. | Device.Display | Body Presence sensor |
| Fitbit | App Cluster Storage | Allows a developer to persist data on the mobile phone and share it between all of their applications and clock faces. | Companion.App-cluster-storage | n/a |
| Fitbit | Calendars | Allows a developer to access calendar and event data from a user's mobile phone. | Companion.Calendars | n/a |
| Fitbit | Exercise | Allow the application to create entries within the user's Fitbit Activity Log. | Device.Exercise, | n/a |
| Fitbit | Heart Rate | Application may read the heart-rate sensor in real-time. | Device.Heart-rate. | Heart Rate Sensor |
| Fitbit | Internet | Companion may communicate with the Internet using your phone data connection. | Companion.Fetch | n/a |
| Fitbit | Location | Application and companion may request location data from the device or mobile GPS. | Device.Geolocation | n/a |
| Fitbit | Location | Application and companion may request location data from the device or mobile GPS. | Companion.Geolocation | n/a |
| Fitbit | Run in background | Companion may run even when the application is not actively in use. | Companion.Location-change | n/a |
| Fitbit | Run in background | Companion may run even when the application is not actively in use. | Companion-Wake-interval | n/a |
| Fitbit | User Profile | Read non-identifiable personal information (gender, age, height, weight, resting heart rate, basal metabolic rate, stride, heart rate zones). | Device.User-profile | n/a |
Edit | Attach | Print version | History: r1 | Backlinks | View wiki text | Edit wiki text | More topic actions
Topic revision: r1 - 31 Jan 2020, AnneHelmond
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding Foswiki? Send feedback