SDMM Access Types determine both the order of your app's processing and the types of operations you can perform on the SMS content provider. Requesting higher priority access adds restrictions on the functionality that your app can perform. For example, while ACCESS_TYPE_ANTISPAM is the highest non-premium priority, it only allows for the ability to send a message to SDMM that a message has been blocked. This ensures that it is not written to the SMS content provider and is effectively blocked. So the high-priority processing provides for the appropriate user experience while the limited features offered are still supported.
Additionally, there are some premium access levels. These can provide your app with additional functionality and features to give your app added flexibility, but still give other app developers confidence that all apps will function as expected by the user.
Please contact us if you have questions about the type of access your app should request or concerns about functionality. We can test your app for you if it appears that SDMM does not support it's required features properly.
Antispam apps should not request the permission “SMS_DELIVERED” - if you do, you will be denied this permission level and it will default to “unregistered” and your app will not work for antispam purposes. This will also help with backward compatibility. Antispam apps can send SMS only messages that are not written to the SMS database.
Plugin apps should not request the permission “SMS_DELIVERED” - if you do, you will be denied this permission level and it will default to “unregistered” and your app will not work as a plugin properly. This will also help with backward compatibility. You will not have SMS/MMS write access to the SMS provider, so modifications must be made by your app in the SMS broadcast intent.
Autoresponder apps should not request the permission “SMS_DELIVERED” - if you do, you will be denied this permission level and it will default to “unregistered” and your app will not appear work as an autoresponder. This will also help with backward compatibility. Do not write the received message to the SMS provider, as this will create a duplicate message. Autoresponders can update messages (“mark as read” and “delete”) so that the user has the appropriate experience. However, autoresponders should not request features like “SENDTO” since that is the responsibility of full-featured messaging apps. Only the most recently installed autoresponder will receive a notification from SDMM unless the user changes that default autoresponder in SDMM.
Provide enhanced processing and services before standard messaging apps. Please contact us for details.
By requesting this type of access your app will be responsible for writing to the SMS database. Therefore, all features should work in your app. As with pre-KitKat messaging, your app should abort the broadcast if there is reason to (for example, you have an anti-spam feature). The user will select the app that receives the broadcast and if a new full-featured text messaging app is installed, it will become the recipient of the broadcast automatically until the user changes it or uninstalls the app. This allows the user to have the proper experience with any new apps they want to try while still allowing all full-featured apps to function properly (sending MMS is still available, so there is no need to disable your app's features if you are not the recipient of the message broadcast).
It is important to follow Android's recommendation to disable all features when you are not the “default sms app”. However, SDMM allows you to do the same “checks” to determine if SDMM is the “default sms app” so that your app can continue to function if SDMM is the “default sms app.”