Sample app in Xcode 7 generates 200+ warnings

The warnings generated are related to the way the precompiled headers are built in third-party libraries. This is a known issue that appeared in Xcode 7 Beta 5 and is still appearing in Xcode 7. To resolve the warnings, change the following settings:

• Precompile Prefix (GCC_PRECOMPILE_PREFIX_HEADER) = NO
• Debug Information Format (DEBUG_INFORMATION_FORMAT) = DWARF with dSYM
• Enabled Modules (C and Objective-C) (CLANG_ENABLE_MODULES) = NO

Why the Android SDK uses WAKE_LOCK

MCE uses only a partial computer-only WAKE_LOCK. It is used to make sure that the in-progress task of parsing a notification or sending metrics is completed successfully without a forced stop by the operating system. The WAKE_LOCK permission is used as part of the WakefulBroadcastReceiver pattern to automatically handle the release of the lock when the job is done and to make sure that the lock is not leaked.

Removing the WAKE_LOCK permission results in some tasks being stopped forcefully by the system. It is recommended to keep it because during testing no battery concerns were noticed with users, and the patterns previously mentioned were used.

Why the Android SDK uses BOOT_COMPLETED

The Mobile app messaging SDK for Android uses Alarms, scheduled jobs similar to a Cron job, to handle repetitive tasks. Alarms allow MCE to not use services that always run in the background, and MCE is only called when there is a job to run. When the operating system restarts, all scheduled jobs are removed, and a local copy is kept of the unscheduled alarms. When a notification comes from BOOT_COMPLETED, the operating system starts again, and jobs and alarms are rescheduled.

Removing BOOT_COMPLETED does not allow incomplete jobs to finish. For example, if the first registration attempt was not successful, an alarm is set to retry again, with backoff. If the operation system restarts, the job must be rescheduled to make sure that registration is done successfully.

Security scenarios

This section provides security scenarios and explains how they can be used to address common security needs.

Protection criteria of the local database used by the SDKs

For Android, the HTML is stored locally in a directory owned by the application. The device must be compromised already by an attacker with root access to modify the SQLite files. Similarly, getting access from the desktop requires root access on the device.

For iOS, the HTML is saved in the application’s sandbox, and an attacker must have access to that to change the HTML. For another app on the device to get access, the device would need to be jailbroken / compromised. It is possible that a compromised desktop could connect to the device and push a new SQLite database; however, this would require the device be physically connected to the compromised desktop, and the user must unlock the device to modify the HTML.