clipboard clear doesn't work on Samsung Galaxy S2

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Configure a clipboard clear of 30 seconds or 1 minute on a Samsung Galaxy S2 
handset
2. Copy any password to the clipboard
3. Wait for the clipboard clear to trigger
4. A popup is seen indicating that the clipboard was cleared
5. Try pasting the copied password somewhere

What is the expected output? What do you see instead?
It is expected that the password should have been cleared from the clipboard. 
It is observed that it hasn't been cleared.

What version of the product are you using? On what operating system?
Version 1.9.3.1 downloaded from Android market. Running on 2.3.3 Gingerbread 
XWKF3.

Please provide any additional information below.

Original issue reported on code.google.com by junaidah...@gmail.com on 7 Jul 2011 at 11:17

[GoogleCodeExporter]

Any news about this. I want to use it because I use keepass on Linux and 
Windows. This issue stops me using it though. And of course I can't recommend 
it to others having Galaxy S2.

Original comment by cbu...@gmail.com on 14 Aug 2011 at 12:02

[GoogleCodeExporter]

This is a bug with the Samsung Galaxy. It doesn't accept setting the clipboard 
to a blank value. I could try setting it to a space instead.

Original comment by bpel...@gmail.com on 5 Sep 2011 at 5:59

[GoogleCodeExporter]

I reckon this would be an acceptable solution.

Original comment by junaidah...@gmail.com on 5 Sep 2011 at 6:18

[GoogleCodeExporter]

The same for galaxy s2.
it's really a problem because you can have almost unlimited clipboard space and 
all your passwords are there as long as you don't actively remove them...
I hope you can fix this.
i am using version 1.9.5.

Original comment by ar...@stekla.ch on 24 Nov 2011 at 6:44

[GoogleCodeExporter]

Same for the Samsung Galaxy Tab. If you copy the username and password to the 
clipboard then after the time out two empty entries are added to the clipboard. 
It would be better if keepassdroid could simply clear the whole clipboard 
instead of adding empty entries but maybe the API doesn't have that 
functionality.

Original comment by hooge...@gmail.com on 31 Dec 2011 at 8:07

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

The issue also exists on a Samsung Galaxy S3.

Original comment by iesperie...@gmail.com on 7 Jul 2012 at 9:36

[GoogleCodeExporter]

The issue also exists with the Galaxy Note (Android 4.0.4).

Original comment by slubman@gmail.com on 16 Aug 2012 at 3:33

[GoogleCodeExporter]

The issue also exists with the Samsung Galaxy Ace 2 (GT-I8160)

Original comment by tilo.fic...@googlemail.com on 18 Aug 2012 at 5:52

[GoogleCodeExporter]

I have an SGS2 and found a way to solve this.
The mentioned Samsung devices have, in addition to the ClipboardService, an 
additional ClipboardServiceEx service which manages the history automatically 
and that can't be programmatically controlled, which would be required to 
remove the sensitive entries such as passwords.
I looked into the code and found that it will "promote" the main clipboard 
entries to the history only for predetermined mime types, such as text/plain, 
some image types, etc.

If I create a ClipItem with an explicit mime type of, say, "text" (not 
text/plain), it will be placed on the main clipboard, it will be available in 
*some* paste situations, and it won't be sent to the history manager.
Now, the behavior will be different depending on where I'm long-pressing to get 
the "Paste" button.
Inside a browser (both Chrome and the stock one), on the text entry fields 
*inside* a page, long-pressing will only show a "PASTE" option, which will 
fetch such entry placed on the clipboard even with that mime type, and the text 
is correctly pasted (either on a Username field, a Password, etc.).
When pasting everywhere else - in the address bar, in the Accounts and sync, in 
application (non-browser) forms, etc., the enhanced clipboard will kick in and 
display the 2 buttons "Paste" and "Clipboard". And both of these will ignore 
the unexpected data and go to the history entries, pasting the last valid entry 
that was there.

One of the workarounds that could perhaps be implemented, subject to a 
configuration option, would be to place info of username and password (probably 
not URL, for instance) in the clipboard using this explicit mimetype so it's 
not picked up by Samsung's extended clipboard.
It could be an experimental / advanced setting, only to be used by the folks 
having this particular set of devices. And even there, it won't cover all 
situations as some of the fields where one would paste a password (such as 
entering data on "Accounts and Sync") will forcibly use the extended clipboard 
rather than the standard one. But at least forms on web pages would be 
protected in regards to not having the passwords be kept in the history.

Original comment by Tungstwe...@gmail.com on 29 Aug 2012 at 10:47

[GoogleCodeExporter]

Issue 381 has been merged into this issue.

Original comment by bpel...@gmail.com on 12 Sep 2012 at 5:18

[GoogleCodeExporter]

Similar problem on SonyE Xperia Arc S running And. 4.0 
Entries copy to clipboard ok but does not close or lock even after many hours.
Icons still appear in top bar.
Attempt to run Keepass requires password but copy already open entry does not.

Original comment by singingo...@gmail.com on 14 Sep 2012 at 9:34

[GoogleCodeExporter]

(sorry - this started on a merged report)

I have another data-point:

On my Droid3, the status bar item seems to DECAY. If I don't use them 
immediately, they remain and appear to be functional, but they do not replace 
the content of the clipboard.

I recall seeing (in previous versions) a notice that items were no longer 
available. I don't know if that was because the KeePass app itself timed-out or 
if it was an obvious safety protocol. This notice was in addition to the notice 
that the value was cleared from the clipboard (also which I don't seem to see 
now).

Perhaps looking at the operations that clear the clipboard and status bar links 
will prove useful.

Cheers

Original comment by richardc...@gmail.com on 21 Sep 2012 at 11:37

[GoogleCodeExporter]

I have finally found a permanent solution for this.
It involves manipulating the extra Clipboard service added by Samsung, which 
keeps track of past clipboard entries.

I have created an Xposed module to make all clipboard history be cleared 
whenever an empty string is copied, which KeePassDroid does.
The Xposed framework needs to be installed (root required during installation 
only) and the module should then be installed and enabled.

Xposed Framework: http://forum.xda-developers.com/showthread.php?t=1574401
Secure Samsung Clipboard mod: 
http://www.villainrom.co.uk/forum/index.php?microdownloads/14/viewfile
Other assorted modules can be found here: 
http://forum.xda-developers.com/showthread.php?t=2012770

Original comment by Tungstwe...@gmail.com on 27 Mar 2013 at 1:29

[GoogleCodeExporter]

samsung galaxy tab 7.7 (android 4.0.4)
similar problem.

may be solution, that disables this crazy Samsung feature exists?

Original comment by falcon....@gmail.com on 9 May 2013 at 11:34

[GoogleCodeExporter]

Same problem on Galaxy Note 10.1 (2014 version)(android 4.4.2).  The Xposed 
module from Tungstwe** would be the ideal solution except for one bug.  On 
Galaxy Note it does clear the entire clipboard history, but unfortunately 
causes the device to reboot about 5 seconds later. 

Original comment by ncs...@gmail.com on 1 Jul 2014 at 8:12

[GoogleCodeExporter]

I have been appalled to find that this issue still exists in 2015 (version 
2.0.3) having been reported in 2011. I have been using Keepassdroid for some 
time on a Galaxy S2 with Android 4.1.2 and have just found that my clipboard 
was full of usernames and passwords copied there by Keepassdroid. This seems to 
me a CRITICAL issue rendering the app very insecure. The clipboard can be fully 
cleared in other apps which uses the clipboard, but this will not be done if 
users do not realise that Keepassdroid fails to do this itself, either at its 
timeout or when the app is closed. This issue needs urgent rectification.

Original comment by cigeof...@gmail.com on 11 Jul 2015 at 12:29