Super Duper Messaging Manager

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
===== Access Types =====

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 level, 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.

  * **ACCESS_TYPE_SYSTEM** 		- Please contact us for system level access as a carrier or manufacturer.

  * **ACCESS_TYPE_SYSRESERVED** 	- Please contact us for reserved, premium access and features.

  * **ACCESS_TYPE_ANTISPAM** 		- Antispam apps can block messages from regular messaging and other apps

 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.

  * **ACCESS_TYPE_PLUGIN**	 	- SMS / MMS preprocessing for special features.

 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.

  * **ACCESS_TYPE_AUTORESPONDER** 	- SMS Autoresponders
 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. 

  * **ACCESS_TYPE_MSGRESERVED** 	- Premium access for messaging apps.
  Provide enhanced processing and services before standard messaging apps. Please contact us for details.

  * **ACCESS_TYPE_MESSAGING** 		- Standard text messaging apps. 
  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."//

  * **ACCESS_TYPE_BACKUP** 		- Backup apps will have full access to the SMS database. Since the system broadcasts "SMS_RECEIVED", SDSMS will do the same for your app. This provides forward compatibility, in the event that Android changes that going forward. If you integrate with SDMM, you will be able to provide full backup/recovery without user intervention or action. You can also support devices without SDMM simply by following Android "advice for backup apps" in their documentation.

  * **ACCESS_TYPE_OBSERVER**		- Observers will simply receive an additional SMS_RECEIVED broadcast. This provides forward compatibility in the case where Android stops broadcasting the "SMS_RECEIVED" intent and your app relies on that.

  * **ACCESS_TYPE_UNREGISTERED** 	- Reserved for apps that do not integrate or that do not integrate properly by requesting an inappropriate Access Type (either based on their requested permissions, behavior, SDMM review, attempting to modify the SMS tables with authorization, etc.)
Super Duper Messaging Manager

User Tools

Site Tools

Page Tools
