# Did not meet TRUSTED criteria This build did not satisfy all of CITT's published criteria for the TRUSTED mark. The full criteria and this app's results are shown below. ## Trust Pillars - **Secure by Design**: Under review. This area was not fully assessed in this version. - **Data Minimization**: Not met. Did not meet one criterion in this area. - **Manifest Mismatch**: Not met. Did not meet one criterion in this area. - **User Control**: Strong. Strong result in this area. - **Truly Local**: Not applicable. Does not apply to this app. - **Child-Safe**: Not applicable. Does not apply to this app. --- # Security & Privacy Scorecard ## AAWireless for Android Auto™ ## What This Means for You Build 7.6.2659 contains code that assembles device identifiers and Bluetooth device names for the developer's own backend server; a diagnostics component also bundled in this build reached end of vendor support in December 2021 and may route additional device telemetry to a third-party service. ## Recommendation: Trustworthy CITT rates this build 88/100 (Trustworthy). The build stores sign-in details using hardware-backed encryption and routes off-device data only to the developer's own infrastructure and standard Firebase services, not to advertising networks or data brokers. The primary areas for improvement are WiFi hotspot settings stored without encryption on the device, a diagnostics SDK that reached end of vendor support in December 2021, and testing framework components that shipped in the production build. **Best For:** People who use an AAWireless adapter for wireless Android Auto connectivity and want adapter management data handled by first-party infrastructure rather than advertising or data-broker networks. ## Method and Limitations Static analysis only. CITT reviewed the code of this build without running the app, so runtime behavior was not observed. The findings below describe the analyzed build and may not reflect server-side controls or later versions. CITT makes no determination about compliance with any law or platform policy; it reports what the artifacts contain and cites the published guidance so a reader can compare. ## Key Findings **Data Security:** 0 findings **Network Security:** 1 finding (1 medium) **Code Safety:** 7 findings (4 medium, 3 low) **Privacy:** 3 findings (1 medium, 2 low) ## Privacy Concerns ### What Leaves the Device - Device identifiers (manufacturer, model, OS version, app version): build 7.6.2659 contains code in a background sync component that assembles these values for api.aawireless.app; runtime behavior was not observed. - Bluetooth device names and hardware addresses for Android Auto-paired devices: the same background sync code assembles paired-device names and addresses alongside device fingerprint data for api.aawireless.app; runtime behavior was not observed. - Account identifier and push notification identifier: the build contains code that links the authenticated account identifier to a push notification identifier and passes the pair to api.aawireless.app; runtime behavior was not observed. - Device telemetry including carrier network name, battery level, GPS-enabled state, and device modification detection result: the bundled Splunk MINT SDK (version 5.2.1, EOL December 2021) contains code that assembles this telemetry and may route it to splkmobile.com; runtime behavior was not observed. ### What Stays on the Device - WiFi network and hotspot configuration data is stored on the device. No code path routing this configuration to external services was identified in this analysis, meaning this data remains within the device. - Android Auto session and connection state data appears to remain on the device based on code paths reviewed; no off-device flow for this data was identified. ### Third-Party Data Sharing **Third parties that may receive data from the app:** - AAWireless developer backend (api.aawireless.app) - device fingerprint, Bluetooth device names and hardware addresses, account and notification identifiers - Firebase (Google) - authentication, app analytics, crash reporting, and push notification delivery - Splunk (splkmobile.com) - device telemetry via bundled MINT SDK (EOL December 2021) - Channel.io - customer support chat SDK bundled in the build; chat data may reach Channel.io servers if the in-app support feature is used ## Understanding the Scores **Security:** 88/100 **Privacy:** 88/100 ### Security Breakdown - **Data Security:** 94/100. Stored sign-in details use hardware-backed encryption, and backup channels are disabled, preventing data extraction via device backup methods. - **Network Security:** 95/100. TLS certificate chains are validated on all connections, with no override or bypass code identified in this build. - **Code Safety:** 86/100. The production build includes testing framework components that other apps on the device can address, and several Bluetooth-related receivers lack permission requirements. Firmware update integrity is verified against a value supplied by the developer's API server rather than an independently embedded signing check. ### Privacy Breakdown - **Data Collection:** 89/100. Off-device data flows are directed to the developer's own backend and Firebase infrastructure; no broad-reach advertising SDK was identified in this build. - **Data Sharing:** 93/100. Data routed off the device reaches only the developer's own infrastructure and contracted services; no data broker or advertising network sharing was identified. - **User Control:** 89/100. Standard Firebase account controls are present; the Play Store Data Safety section could more specifically enumerate certain device and Bluetooth identifiers passed to the backend. ## Positive Security Features - Stored sign-in details use hardware-backed encryption tied to the device's secure hardware. - Backup channels (device backup and cloud backup) are disabled, preventing stored data from being extracted via backup methods. - Firebase App Check is enforced on API calls, providing server-side verification of the app build against repackaged copies. - No broad-reach advertising SDK was identified in this build; no AdMob or equivalent ad-network library is present. - Data flows observed in the code reach only the developer's own backend and standard Firebase infrastructure, with no data broker or advertising network sharing identified. - TLS certificate chains are validated on all connections; no certificate validation bypass code was identified. - No vehicle diagnostic data collection was identified; the build contains no code that reads OBD or vehicle system data beyond adapter form-factor context. ## Areas for Improvement ### Disclosure observations Observations about disclosure, each stated against the published guidance so a reader can compare: 1. **Bluetooth device data in Play Store disclosure** Google's Data Safety guidance requires disclosure of data types shared with third parties. The Play Store Data Safety section for this app (retrieved August 2026) declares "Device or other IDs" under "This app may share these data types with third parties." Build 7.6.2659 contains code that assembles Bluetooth device names (which may reflect vehicle make and model) and hardware addresses for Android Auto-paired devices and passes them to the developer's backend. These specific data types are not explicitly listed under "Device or other IDs" in the Play Store section. The reader can compare this description against the published Data Safety label to assess completeness. ### Security Enhancements 1. **WiFi hotspot configuration storage** The build stores WiFi hotspot settings without the hardware-backed encryption used for other sign-in data. Someone with physical access and elevated device permissions could read this configuration from storage. Applying the same hardware-backed encryption approach to hotspot settings would bring this data in line with the rest of the build's stored data handling. 2. **Diagnostics SDK end of support** The build bundles Splunk MINT version 5.2.1, which reached end of vendor support in December 2021 and no longer receives security updates. Replacing it with a currently maintained crash and diagnostics SDK would close this maintenance gap. 3. **Test and development components in production build** Four testing framework activities and two Bluetooth event receivers in the production build are accessible by other apps on the same device without requiring any permission. Removing test dependencies from production builds and adding permission requirements to the Bluetooth event receivers would reduce the surface available to co-installed apps. 4. **Firmware update integrity** Firmware update downloads are verified against an integrity value supplied by the developer's API server. An independent signing check using a verification key embedded in the build would add a layer of trust that does not depend solely on the API server response being unmodified. ## Technical Context **App Type:** IoT companion app for wireless Android Auto adapter **Classes Analyzed:** 2,400 **Third-Party Services:** 25 **Context Tags:** bluetooth, iot_companion, automotive, third_party_sdk --- ## About This Analysis This security analysis was conducted by CITT (Can I Trust That), an independent security analysis service. The analysis is static code review of Android applications, intended to help people make informed decisions about app security and privacy. ### App Details **Developer:** AAWireless (CP & EB IT) **Version:** 7.6.2659 **Analysis Date:** 2026-08-13 **Package:** app.aawireless ### Analysis Limitations - Static analysis only (code review without running the app) - Based on APK version 7.6.2659 analyzed on 2026-08-13 - May not reflect server-side security controls - Cannot detect all runtime behaviors