On Jelly Bean and above:
- Use the standard notification style for a better and consistent visual
appearance
- Use the JB notification actions API for the locking action
- Use a lower notification priority to prioritize other notifications
over TextSecure
On ICS:
- Use the existing custom notification layout
Everywhere:
- Allow opening the app itself from the notification
- Simplify strings: don't talk about a "cached passphrase" but about the
app being "unlocked"/"locked"
Messages that are not "secure" (encrypted or key exchange) are
automatically marked as read if TextSecure isn't the default
KitKat SMS app.
This change in functionality allows people who aren't using
TextSecure as a default SMS app on KitKat to still receive
notifications when they get incoming encrypted messages.
1) The system does actually enforce having a BROADCAST_SMS
permission on the SMS receiver. Break out the "delivered"
parts of this into a separate Receiver, so the permission
won't trip up GB devices.
2) The system does actually enforce having "quick response"
intents. Add a no-op for now.
3) Add a "make default" prompt.
4) Update settings to reflect what's going on in KitKat.
1) Added a new message status to MmsDatabase to
signify a pending MMS download which requires
APN settings.
2) Added a database method to query MMS messages
based on status.
3) Added login to SendReceiveService for processing
of MMS pending APN information.
4) Moved all APN/MMS settings into ApnPreferencesActivity
and transformed PromptApnActivity into a simple
informational activity.
5) Added logic to check for APN settings on send and
receive of all MMS (media, group, email) and direct
user to PromptApnActivity then ApnPreferencesActivity
if necessary.
6) Vocab/grammar adjustments.
1) ABS is now published as an AAR, so we can eliminate all local
dependencies and bundled jars.
2) Upgrade to ABS 4.4.0 (The Last Release) and deal with the loss
of Sherlock.Dialog by faking it with our own themes.
3) Remove all traces of ant. The modern world is here.
Regardless of which theme is used, the text color for the timeout
interval was being set to black. This made it difficult to
read when using the Dark Theme.
Not really sure how it's possible for the system to give us an
extra block of data, but it does if both the input and output
buffers are sized the same during the first decrypt. This
fixes things, but I wish I better understood why it was broken.
1) There was a regression in the outgoing multipart transport
logic, such that the same 'identifier' byte would be used
for all messages (0). This now works correctly.
2) Added some additional heuristics on the receiving side.
Now mutlipart containers are only valid for 1hr, and are
considered invalid if the container size is different from
the multipart message size.
Removed previous multiple comparisons that were variations of capitalizing the same phrase by converting the original phrase to all uppercase and then comparing
