Apparently, storing the draft state header in the encrypted payload
introduces difficulties in Enigmail due to restrictions from
Thunderbird. To stay compatible, this commit keeps the draft state in
the outer header for now, but we should move it into the encrypted
payload if the issue with Thunderbird is somehow resolved.
see: https://github.com/autocrypt/autocrypt/pull/376#issuecomment-384293480
This commit is a hack. It assumes that if a draft is encrypted, the user
chose to encrypt at some point and sets the status based on that
assumption. This is only an assumption though, which becomes a problem
e.g. if some other MUA encrypts all drafts. At some point we should
remember the actual user choice.
A thing to note is that the permission request will only show up when the targetsdk is upped >23.
Old commit message that explains the change:
--
The approach was to make it so that any K9Activity can easily request
whatever permission in the future.
The Contacts permission is now requested in two locations:
1. When a list of Messages is displayed
2. When a new message is first started to be composed.
The permission request is displayed ONCE per onCreate(). Any more than this
and it got really annoying. A typical user who reads or writes emails
WILL see the request, trust me. Once they see the message 2x, they
also have the option to block the requests from appearing.
If they DECLINE the request (or decline + DENY any further attempts),
the app should continues to work, albeit without incorporating contact data
(thumbnails, autocomplete, etc.). Contacts may still be added to the
Contacts app, as this uses an Intent and does not require any permission.
Once the Read Contacts permission is enabled, the app immediately begins
to use it.
To add other permissions in the future (such as External Storage access),
the request can be made in a similar way and the permission request result
handled appropriately by just adding it to K9Activity (or overriding in
a particular Activity).
