User Tools

Site Tools


install

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
install [2014/02/24 23:24]
superdupersms
install [2015/01/05 02:37] (current)
superdupersms
Line 1: Line 1:
-===== Installing Super Duper SMS Manager =====+===== Installing Super Duper Messaging ​Manager =====
  
 1. Download the [[SDK|SDK]] 1. Download the [[SDK|SDK]]
Line 5: Line 5:
 2. In a strings file in /res, add your SDSMS_ID: 2. In a strings file in /res, add your SDSMS_ID:
  
-'' ​   ​<string name="​SDSMS_ID">​UNREGISTERED_APP</​string>​ +<code java><string name="​SDSMS_ID">​com.yourpackage.name</​string>​ 
-''​+</​code>​
  
-If you have a registration ID, enter it here. Otherwise, this can be anything you want it to be (or leave it alone). Setting it to a unique value is recommended.+If you have a registration ID, enter it here. Otherwise, this can be anything you want it to be (or leave it alone). Setting it to a unique value is recommended ​because if it is the same as another app, your app may not function properly and may be denied access to SDMM features.
  
-3. Determine the appropriate ​interface type for your app based on these values: +3. Determine the appropriate ​Access Type for your app based on these values ​as indicated here[[Access ​Types|Access Types]]
- +
-  * **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 "​SMS_DELIVERED"​ - if you do, you will be denied this permission level and it will default to "​unregistered"​ and your app will not work. This will also help with backward compatibility. Also, SDSMS will send duplicate messages to your app to confirm if the broadcast should be aborted based your user settings. You will not have SMS/MMS write access to the SMS provider. +
- +
-  * **ACCESS_TYPE_PLUGIN** - SMS / MMS preprocessing for special features. +
- +
- ​Plugin apps should not request "​SMS_DELIVERED"​ - if you do, you will be denied this permission level and it will default to "​unregistered"​ and your app will not work. This will also help with backward compatibility. Also, SDSMS will send duplicate messages to your app to confirm if the broadcast should be aborted or modified by your app. You will not have SMS/MMS write access to the SMS provider, so modifications must be made to the broadcast intent. +
- +
-  * **ACCESS_TYPE_AUTORESPONDER** - SMS Autoresponders +
- ​Autoresponder apps should not request "​SMS_DELIVERED"​ - if you do, you will be denied this permission level and it will default to "​unregistered"​ and your app will not work. This will also help with backward compatibility. Do not write the received message to the SMS provider.  +
- +
-  * **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 first "​messaging"​ app to either abort or write the message will be the last in this group to receive it. +
- +
-//It is important to follow Android'​s recommendation to disable all features when you are not the "​default sms app". However, SDSMS allows you to do the same "​checks"​ to determine if you are the SDSMS "​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 (in the event that Android changes that going forward). If you integrate with SDSMS, you will be able to provide full backup/​recovery without user intervention or action. +
- +
-  * **ACCESS_TYPE_OBSERVER** - Observers will simply receive an additional SMS_RECEIVED broadcast. +
- +
-  * **ACCESS_TYPE_UNREGISTERED** - Reserved for apps that integrate and do not request an appropriate ​Access ​Type (either based on their requested permissions,​ behavior, SDSMS review, attempting to modify the SMS tables with authorization,​ etc.)+
  
  
 4. Replace SmsManager wtih SDSmsManager anywhere you use it in your project. If you set it globally in an Application class, that will work too. For example replace: 4. Replace SmsManager wtih SDSmsManager anywhere you use it in your project. If you set it globally in an Application class, that will work too. For example replace:
  
-'' ​       ​SmsManager mSmsManager = SmsManager.getDefault();​ +<code java>SmsManager mSmsManager = SmsManager.getDefault();​ 
-''​+</​code>​
  
 with this: with this:
  
-'' ​       ​SDSmsManager mSDSmsManager = SDSmsManager.getDefault(context,​ context.getString(R.string.SDSMS_ID),​ +<code java>SDSmsManager mSDSmsManager = SDSmsManager.getDefault(context,​ context.getString(R.string.SDSMS_ID),​ 
-         SDSmsManager.ACCESS_TYPE_MESSAGING);​ +      SDSmsManager.ACCESS_TYPE_MESSAGING);​ 
-''​+</​code>​
  
-5. Replace all SmsManager calls with mSDSmsManager, like this:+5. Replace all SmsManager calls with SDSmsManager calls, like this:
  
- SDSmsManager sms = SDSmsManager.getDefault(context,​ context.getString(R.string.SDSMS_ID),​+<code java> SDSmsManager sms = SDSmsManager.getDefault(context,​ context.getString(R.string.SDSMS_ID),​
         SDSmsManager.ACCESS_TYPE_MESSAGING);​         SDSmsManager.ACCESS_TYPE_MESSAGING);​
  try {  try {
Line 63: Line 34:
      sendError(msgId,​ phoneNumber);​      sendError(msgId,​ phoneNumber);​
  }  }
 +</​code>​
  
-6. If you use a SqliteWrapper like many examples ​provide, simply replace you import statement in those classes with the following:+6. If you use a SqliteWrapperlike many examples ​that are readily available, simply replace you import statement in those classes with the following:
  
-''​import com.sirisdevelopment.superdupersmsmanager.database.sqlite.SqliteWrapper;​ +<code java>import com.sdmmllc.superdupersmsmanager.database.sqlite.SqliteWrapper;​ 
-''​+</​code>​
  
-The included class does URI resolution normally except that the standard "​sms"​ authority is replaced with the "​sdsms"​ authority when SDSMS is the Default Messaging App. +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. 
  
-Also included in the SDSMS SqliteWrapper is the SDContentResolver class. This class simply checks to see if you URI should be converted to SDSMS Uri's prior to being resolved. This can be used to Replace the standard ContentResolver class+Also included in the SDMM SqliteWrapper is the SDContentResolver class. This class simply checks to see if you URI should be converted to SDMM Uri's prior to being resolved. This can be used to Replace the standard ContentResolver class and will resolve "​sms"​ related authorities appropriately. For example, if this is your code:
  
-Also, this class will make the appropriate calls to SDSMS to acknowledge your proper integration.+<code java>​ContentResolver contentResolver = getContentResolver();​
  
-7. In some casesyou may reference ​Uri's from Telephony or even statically. All MmsSms ​Uri's need to be determined via methods that are providedFor example to get the Sms.Inbox Uri replace the following:+final String[] projection = new String[] { "​retr_st"​"​date",​ "​_id",​ "​ct_t"​ }; 
 +Uri uri = Uri.parse("​content://​mms-sms/​conversations"​);​
  
-''​Sms.Inbox.CONTENT_URI +Cursor cursor = contentResolver.query(uri,​ projection, null, null, "_id DESC"​);​ 
-''​+</​code>​ 
 + 
 +Then that source code can be rewritten as follows and the "​sdsms"​ authority will use the Super Duper Messaging Manager provider when it is the "​Default SMS App" and it will use the standard "​sms"​ authority when it is not: 
 + 
 +<code java>​SDContentResolver sdContentResolver = new SDContentResolver(context);​ 
 + 
 +final String[] projection = new String[] { "​retr_st",​ "​date",​ "​_id",​ "​ct_t"​ }; 
 +Uri uri = Uri.parse("​content://​sdmms-sdsms/​conversations"​);​ 
 + 
 +Cursor cursor = sdContentResolver.query(uri,​ projection, null, null,"​_id DESC"​);​ 
 +</​code>​ 
 + 
 +This is a convenience method only. We do not require that you use SDContentResolver unless you are currently using the Android ContentResolver for querying SMS content. 
 + 
 +Also, this class will make the appropriate registration calls to SDMM to ensure SDMM identifies and handles your app appropriately. 
 + 
 +7. In some cases, you may reference Uri's from Telephony or even statically. All MmsSms Uri's need to originate from dynamic methods that are provided. For example to get the Sms.Inbox Uri replace the following:​ 
 + 
 +<code java>Sms.Inbox.CONTENT_URI 
 +</​code>​
  
 with this code (and import SDSmsManager into any classes that do not already have it): with this code (and import SDSmsManager into any classes that do not already have it):
  
-''​SDSmsManager.Sms.Inbox.CONTENT_URI() +<code java>SDSmsManager.Sms.Inbox.CONTENT_URI() 
-''​+</​code>​
  
-As a side note, if you create or make static references to these Uri's, this **will not work** because the methods will only execute as the app is instantiated. If the user changes the default SMS app, then your app may not behave properly. These **must** be runtime references. ​These are static ​methods, so your compiler will not complain but it will most likely result in problems.+As a side note, if you create or make static ​variable ​references to these Uri's, this **will not work** because the methods will only execute as the app is instantiated. If the user changes the default SMS app, then your app may not behave properly. These **must** be runtime/dynamic method ​references. ​If you use static ​or variable references ​your compiler will not complain but it will most likely result in runtime ​problems ​for users.
  
-8. Implement the SDSMS callback for received messages. This allows you to tell SDSMS if your app attempted to abort the incoming SMS. Here is an example:+8. Implement the SDMM callback for received messages. This allows you to tell SDMM if your app attempted to abort the incoming SMS. Here is an example:
  
- private ISDSmsReceiveCallback.Stub mCallback = new ISDSmsReceiveCallback.Stub() {+<code java> private ISDSmsReceiveCallback.Stub mCallback = new ISDSmsReceiveCallback.Stub() {
  @Override  @Override
  public boolean onReceive(Intent intent) throws RemoteException {  public boolean onReceive(Intent intent) throws RemoteException {
Line 106: Line 98:
   
  };  };
 +</​code>​
 +
 +In this example, the intent is processed and will be passed back to SDMM unless the callback returns a value of "​true"​ - indicating that your app aborted the SMS broadcast.
 +
 +9. **(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 must do the following:
 +
 +Remove your "​abort"​ call if SDMM is installed. Only perform the SDMM "​abort"​ if SDMM is not installed except 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+, an app is **not** supposed to be able to abort the SMS_RECEIVED intent, but on some (or all) 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 is not how the documentation says it should perform, so it may not do this on your test device.
 +
 +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.
  
 +This is currently a **BETA** feature. 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, 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.)
  
-In this example, the intent is processed and will be passed back to SDSMS unless the callback returns a value of "​true"​ - indicating that your app aborted the SMS broadcast. 
install.1393284283.txt.gz · Last modified: 2014/02/24 23:24 by superdupersms