DIGEST and HMAC were static variables. Those are initialized by
what ever concrete implementation gets executed first.
(Perform SCRAM-SHA1 first and those variables got initialized with
SHA1 variants)
For subsequent SHA256 executions those variables contained wrong
values.
- With large accounts (such as mine), Conversations starts hitting up against
the default heap limit pretty quickly, at which point it grinds to a halt as
GC pause times increase.
- Furthermore, it's impossible to complete a backup with such an account, since
Conversations will just run out of memory before the backup can complete.
- Enabling the `android:largeHeap` flag asks the OS for a bit more memory, which
hopefully alleviates the problem for larger accounts.
- In some places, we weren't nulling out references to destroyed objects. This
fixes that.
- (These were all discovered via LeakCanary instrumentation, and the fixes are
hopefully rather straightforward-looking.)
- When the `viewHolder.messageBody` `TextView` created by a `MessageAdapter` is
set to selectable, it leaks an `android.widget.Editor` (because that editor
registers a view observer that never gets unregistered).
- This memory leak is really quite problematic, as the message adapter is used
a lot!
- Having the text be selectable is useless anyway, though; there isn't any way
to select it (because long pressing just opens the context menu anyway).
- It looks like the ListSelectionManager was meant to track selections across
multiple messages. However, I'm not sure this feature ever gets used.
- Accordingly, this commit removes the entire feature, thus fixing the memory
leak (since no `Editor` objects are ever created).
- It should also reduce memory usage in general, since we aren't attaching an
`Editor` to every single textview we create.
- A `TextView` only allocates an `Editor` if you ask it to do certain things,
like make the text selectable or register custom selection callbacks.
Daniel Gultsch
Geno
nico