E/StrictMode(9278): A resource was acquired at attached stack trace but never released. See java.io.Closeable for information on avoiding resource leaks.
E/StrictMode(9278): java.lang.Throwable: Explicit termination method 'close' not called
E/StrictMode(9278): at dalvik.system.CloseGuard.open(CloseGuard.java:184)
E/StrictMode(9278): at android.os.ParcelFileDescriptor.<init>(ParcelFileDescriptor.java:179)
E/StrictMode(9278): at android.os.ParcelFileDescriptor.<init>(ParcelFileDescriptor.java:168)
E/StrictMode(9278): at android.os.ParcelFileDescriptor.createPipe(ParcelFileDescriptor.java:362)
E/StrictMode(9278): at org.openintents.openpgp.util.ParcelFileDescriptorUtil.pipeFrom(ParcelFileDescriptorUtil.java:34)
E/StrictMode(9278): at org.openintents.openpgp.util.OpenPgpApi.executeApi(OpenPgpApi.java:222)
E/StrictMode(9278): at org.openintents.openpgp.util.OpenPgpApi$OpenPgpAsyncTask.doInBackground(OpenPgpApi.java:189)
E/StrictMode(9278): at org.openintents.openpgp.util.OpenPgpApi$OpenPgpAsyncTask.doInBackground(OpenPgpApi.java:1)
E/StrictMode(9278): at android.os.AsyncTask$2.call(AsyncTask.java:288)
E/StrictMode(9278): at java.util.concurrent.FutureTask.run(FutureTask.java:237)
E/StrictMode(9278): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
E/StrictMode(9278): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
E/StrictMode(9278): at java.lang.Thread.run(Thread.java:841)
This gives the openpgp-api-library an Eclipse
project name consistent with the names used for
the other plugins. This helps with initial
project setup and avoids project naming collisions.
Create .project files for all the Ecplipse projects
so they will all have project names and can
all be brought into Ecplipse together with a single
'File -> Import -> Android ->
Existing Android Code Into Workspace'.
(Not bothering to remove the .project exclusion from
all .gitignore files. Once the .project files are
checked in, they will no longer be ignored.)
Modify the top .project file so that Eclipse knows
k9mail's dependence on it plugins, and thus will
build everything in the correct order.
With the latest Android SDK Rev. 22, the top .classpath file
needs modification or else K9 will not run (see parent commit 53fcdd1).
But the initial import of k9mail into Eclipse works more cleanly if the
.classpath file doesn't exist on import, in which case Eclipse creates it
automatically. So rather than modify the .classpath file, remove it
from git and leave it untracked.
(For an existing Eclipse project, this commit will remove the file from
the working directory. A corrected version can be restored with:
git checkout 53fcdd1 .classpath
git rm --cached .classpath)
Add .classpath to the top .gitignore, now that no
.classpath files are being tracked (with one exception,
see below).
Create a tests/.classpath so that Java can find the k9mail
project in order to build the k9mail-tests project.
Merge branch 'jb-notifications' of https://github.com/maniac103/k-9
* 'jb-notifications' of https://github.com/maniac103/k-9:
Strip off signatures from preview.
Reset list of unseen messages when the user clears the notification.
In the new-style notification, directly go to message if new message count is 1.
Cancel notification when viewing message by clicking on notification.
Directly go to message when clicking on a single-message notification.
Fix message overflow.
Incorporate review comments.
Some fixes to notification behaviour.
Add German translation for message delete notification action.
Add delete action to notification.
Update summarized notification if a message is deleted or read remotely.
Fixed deprecation warnings.
Simplify code and beautify pre-jellybean notifications by using bold sender span for those.
Respect "Show contact names" option when determining sender for notification.
Fix marking messages as read from notification.
Add German translation for new strings.
Add actions to notifications.
First stab at new notifications.
Remove own Notification.Builder abstraction.
Update android support library to latest version.
When restoring a mode != DISABLED with the current mode being DISABLED
the header and/or footer layout weren't added to the view. That's why we
now call setMode() instead of setting mMode directly.
