Implement "Quick Responses"

[MatejKovacic]

Android has an useful option for rejecting call with SMS. When you receive a call, you can reject it with pre-prepared or custom SMS.

However, this SMS is not sent through TextSecure but through default Android application for sending SMS's.

Can this be changed?

[kenneththomasbrown]

This will become possible with Android 4.3.

See "Intent for handling Quick Responses" at https://developer.android.com/about/versions/jelly-bean.html

[BernhardPosselt]

I've got Android 4.4 and this is not possible yet, one of the problems that bugs me the most and why I dont run it as default SMS app

[mcginty]

Renamed issue to "Implement 'Quick Responses'" since that's the feature that needs to be added. This would be a great Pull Request if somebody wants to pick it up. On our list.

[santa4nt]

The skeleton is already in place. See: QuickResponseService.java in src/org/thoughtcrime/securesms/service/QuickResponseService.java and within AndroidManifest.xml:

<service android:name=".service.QuickResponseService"
         android:permission="android.permission.SEND_RESPOND_VIA_MESSAGE"
         android:exported="true" >
    <intent-filter>
        <action android:name="android.intent.action.RESPOND_VIA_MESSAGE" />
        <category android:name="android.intent.category.DEFAULT" />
        <data android:scheme="sms" />
        <data android:scheme="smsto" />
        <data android:scheme="mms" />
        <data android:scheme="mmsto" />
    </intent-filter>
</service>

I can take a gander at it if you'd like.

[moxie0]

Fair warning, it's actually a deceptively difficult change. The code is fairly well setup for the scenario where you receive an incoming message and don't have a cached MasterSecret, but it's not clear what to do when sending a message without a cached MasterSecret. If you actually have a passphrase configured, there will be no way to send the message using a secure session, for instance.

[santa4nt]

That's the first thing that came to my mind, too. Especially after reading the documentation that the implementing service should not spawn any activity and everything has to be done in the background.

[moxie0]

Easiest thing to do would be to start off by supporting the case where the passphrase is cached or there's no passphrase configured. Would at least be an improvement.

[asafh]

Hi, please take a look at #962 and let me know what you think

[SanderGit]

The word QuickResponse was not mentioned in this issue yet but is in the error message when trying to send one:

Adding this keyword for findability.

[uniquePWD]

Two things, this issue seems to be getting conflated with the quick reply issue. This issue however is for "Reject Call and Send Text Reply".

@moxie0 I'm in agreement with you. Get the functionality for general users in place and then think about the implementation of the passphrase methodology. Which I'd simply suggest a popup password box proceeds the selection dialog of the quick message.

But as things stand, this is functionality that's suggested by all Android phones as standard and by not having something in place, it makes TextSecure look amateurish.

[fajabird]

Hi,
seems this issue still persists. What about implementing a small toast-message after someone tries to reject a call with a message that this funtionality is not supported yet because I already had some people asking me (the guy who recommended TS) what happened to their reject-messages. Or is someone already working this out?

[fajabird]

Ohh - I just took a look at the code and a "not supported yes" toast-message seems to be already implemented:

Toast.makeText(this,
getString(R.string.QuickResponseService_sorry_quick_response_is_not_yet_supported_by_textsecure),
Toast.LENGTH_LONG).show();

BUT it does not show up for me? Someone else getting that toast?

[McLoo]

@fajabird shows up for me. Rejecting call with text ends up in rejecting with 'not supported' toast following :)

[merkste]

I'd like to see the quick reply feature working, too. Any news for us on this one?

[asafh]

@merkste, unfortunately I don't see myself tackling this in the immediate future - since I don't want to uninstall TextSecure from my daily phone. When I get a secondary phone (not too long I hope, but I can't promise nothing) I'll look into this again.

[JavaJens]

@asafh You could:
a) Install two TextSecure versions in parallel and test with the browser extension (very buggy)
b) Specify what needs to be done to continue your development efforts and maybe point others in the right direction

[asafh]

@JavaJens what I've done and moxie's input on what needs to be done is described pretty well over PR #962. Basically, what needs to be done is trying to get the key from the key caching service directly, if it is available go ahead with sending the message, otherwise show a toast with the "TextSecure is currently locked. Quick Response messages are disabled." or similar.

Since the code base has already changed quite a bit, I would the code in that PR's commit as a reference. It will be easier to simply do the similar work on a new branch from main.

If you decide to tackle this, and have questions you want to consult me about - feel free to send me a message here or at ["hello",String.fromCharCode(31*2+2)/regex scrapper/,"ous",".im"].join("")