Plugin apps are classifed as apps that intercept or modify messages. These apps may block or alter messages, and in some cases they respond to the sender according to the user's setup in the plugin app. Your app will have permission to modify existing messages as they are received. If your app requires other features either select a different Access Type or contact us for premium access details.
SDMM allows your app to abort and/or modify messages prior to being processed by a full-featured messaging app. When you integrate and register with SDMM, SDMM will notify your app of any incoming messages prior to them being processed by the full-featured app.
To integrate with SDMM, do the following:
1. Download and import the SDK into your IDE. You will need to include the SDK as a library in your app's project.
2. Copy the sdmm_default_strings.xml file to your /res/strings directory.
3. Change the following entries to match your app:
<string name="sdmm_app_version">1</string> <string name="sdmm_app_name">Super Duper Messaging Manager SDK</string> <string name="sdmm_app_id">sdmm_test_id</string> <string name="sdmm_package_id">com.sdmmllc.superdupersmsmanager.sdk</string> <string name="sdmm_sms_received_class">com.sdmmllc.superdupersmsmanager.sdk.SMS_RECEIVED_CLASS</string> <string name="sdmm_wap_push_received_class">com.sdmmllc.superdupersmsmanager.sdk.WAP_PUSH_RECEIVED_CLASS</string>
The sdmm_app_version is for your reference only when we are assisting with debugging online.
Enter your app's name for sdmm_app_name - this should match your Play Store name.
After your register your app with SDMM, you will receive the sdmm_app_id for this app. For testing you do not have to change it.
Enter your app's “package name” for sdmm_package_id. We use this to validate your app's access authority since many developers have lots of apps and Access Type may change over the life of the app.
Your SMS_RECEIVED_CLASS should be the class that has the INTENT-FILTER for SMS_RECEIVED and WAP_PUSH_RECEIVED_CLASS should be for WAP_PUSH_RECEIVED (if your app captures MMS intents). This should be a fully qualified class name (i.e. com.example.receivers.sms_receiver).
4. Change the sdmm_access_type to 3:
<string name="sdmm_access_type">3</string>
5. To register your app with SDMM on the device, include this call in your Application class “onCreate” method (if you do not have one, you can easily create one for example):
public void onCreate() { SDSmsManager.initialize(this); SDSmsManager.getDefault().setReceiverCallback(mCallback); } private SDSmsReceiveCallback mCallback = new SDSmsReceiveCallback() { @Override public boolean onReceive(Intent intent) throws RemoteException { YourAppSmsReceiver receiver = new YourAppSmsReceiver(); receiver.onReceive(SDSmsManager.getContext(), intent); boolean aborted = false; if (intent.hasExtra(abort)) aborted = true; Log.i(TAG, "SDMM integration success! message aborted: " + aborted); return aborted; } @Override public String testCallbackConnection(String text) { Log.i(TAG, "testConnection text:" + text); return "Connection successful for " + TAG; } @Override public boolean reload() { return false; } };
Replace YourAppSmsReceiver with the name of your app's SMS receiver where you receive SMS messages. If you want to modify the SMS/MMS, then you must modify the contents of this intent when it is received. The modified contents will propagate to the SMS/MMS database.
6. With each SMS, SDMM will send a duplicate SMS broadcast with a “DUPLICATE” extra. When your app recognizes an incoming SMS/MMS that should be blocked, check the SMS intent for the SDMM extra “DUPLICATE” so your app can signal SDMM that the message should be aborted. To block the message, check for the DUPLICATE extra and abort the broadcast like this:
String sdmmDup = ""; if (intent.hasExtra(SDSmsConsts.SDSMS_DUPLICATE)) sdmmDup = SDSmsConsts.SDSMS_DUPLICATE; if (!SDSmsConsts.SDSMS_DUPLICATE.equals(sdmmDup)) { // your code here // // // if you want SDMM to abort the message, include the following two lines if (your_code_abort_this_message) { setResultCode(0); setResultData(SDSmsConsts.SDSMS_ABORT); } } else { // like the example above, these codes tell SDMM to ignore the broadcast setResultCode(0); setResultData(SDSmsConsts.SDSMS_ABORT); }
Setting the appropriate result code and result data will tell SDMM that the message should not propagate further. It will not be written to the SMS database. If you do not abort the message, it will be propagate to subsequent plugins and/or the full-featured messaging app to be written to the SMS/MMS database.
7. Replace all SmsManager calls with SDSmsManager calls, like this:
SDSmsManager sms = SDSmsManager.getDefault(); try { sms.sendTextMessage(phoneNumber, null, message, sentPI, deliveredPI); } catch (Exception e) { // error sending message, attempt to resend or ignore }
If you need to intercept MMS messages, please contact us for the appropriate protocol. MMS integration with plugins is more complex.
9. If you use a SqliteWrapper, like many examples that are readily available, simply replace your import statement in those classes with the following:
import com.sdmmllc.superdupersmsmanager.database.sqlite.SqliteWrapper;
The included class does URI resolution normally except that the standard “sms” authority is replaced with the “sdsms” authority. When SDMM is the Default Messaging App, SDMM will handle the call. If another app is the Default Messaging App, it will resolve to the standard “sms” authority and your response message will be written to the SMS database.
10. (New with SDK 0.95) - BETA Feature: SDMM is NOT the Default SMS App
To try to use your app without SDMM as the default messaging app, you:
Remove your “abort” call if SDMM is installed. Do not abort the SMS_RECEIVED intent using the system “abort” call. Only perform the Android system “abort” if SDMM is not installed. To properly abort when SDMM is install only perform the SDMM abort on the SDMM Duplicate message.
SDMM will send a duplicate SMS_RECEIVED message to your app. To properly abort a message, you should not abort the original message. In Android KitKat+, apps are not supposed to be able to abort the SMS_RECEIVED intent, but on some (or most) platforms it can. If it does, then SDMM will not receive any notice of the SMS_RECEIVED (but the Default SMS App will get the SMS_DELIVERED intent). This will create a bad user experience.
To allow for appropriate processing, your app should not abort the SMS_RECEIVED intent. Then, SDMM will query your app with a duplicate SMS_RECEIVED intent and that intent should return the ABORT flag to SDMM as demonstrated here:
<java code> String sdsmsDup = “”;
// look for this string for the duplicate SMS_RECEIVED broadcast if (intent.hasExtra(SDSmsConsts.SDSMS_DUPLICATE)) sdsmsDup = SDSmsConsts.SDSMS_DUPLICATE;
// then check if the SMS_RECEIVED intent is an SDMM duplicate
// then indicate the abort accordingly
if (SDSmsConsts.SDSMS_DUPLICATE.equals(sdsmsDup)) {
// this code will abort the message in SDMM
//
Log.i(TAG, "aborting intent for SDSMS");
setResultCode(0);
setResultData(SDSmsConsts.SDSMS_ABORT);
intent.putExtra(abort, true);
Log.i(TAG, "SDSmsManager found, duplicate intent signal for abort");
} else if (!SDSmsManager.isSdsmsIntstalled()) {
// insert your code to abort intent for non-KitKat+ devices // Log.i(TAG, "SDSmsManager not found, aborting message"); }
</code>
This will appropriately signal SDMM to abort the SMS_RECEIVED intent. When SDMM is not the default, you should not abort the broadcast in order for SDMM to process the intent appropriately.
BETA WARNING
This is in Beta. SDMM will attempt to cancel any notifications related to the SMS message, but we are still working on ways to improve that experience. It appears to work on some platforms fairly well and on some platforms it is a “poor” experience, but it still essentially works on all tested systems.
Please test this since we do not have all devices available. Also, be aware that SDMM will attempt to dismiss any notifications related to the SMS. It my “roll” and the ticker message may be visible briefly, but it should dismiss before being available in the notification drawer. However, we are working on improving the response time so that it will dismiss prior to even being displayed. It may be advisable to warn your users. (We are working on standard messaging for this.)
Please let us know if you have difficulty with this feature. Thanks!