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
1) Allow imports from the stock SMS database at any time.
2) Provide plaintext export support, in a format compatible with
the "SMS Backup And Restore" app.
3) Fix the DB weirdness on encrypted restore that previously
required killing the app.
1) Broke out the UI elements of the major Activites into stylable
attributes.
2) Created a 'light' and 'dark' theme for the newly stylable attrs.
3) Touched up some of the UI spacing.
4) Implemented dynamic theme switching support.
1) Fixed the "Unsupported Encoding!" problem.
2) Workaround for the Sprint issue, where the MMSC is adding a single
extra byte to the end of each encrypted message.
3) Fixed the "large blob of base64 text" on encrypted MMS problem.
1) There is no longer a concept of "verified" or "unverified."
Only "what we saw last time" and "different from last time."
2) Let's eliminate "verify session," since we're all about
identity keys now.
3) Mark manually processed key exchanges as processed.
On some systems, the DB upgrade was failing because there were
too many rows for the cursor window. This moves some looping
operations into single update statements by using the substr()
command, and chunks the rest using a series of LIMITs.
