Allow getting and setting values from different threads in parallel

[MarkVillacampa]

This solves #40

[patrickfav]

LGTM

[MarkVillacampa]

Taking another look at ByteArrayRuntimeObfuscator, I don't see a reason to add synchronized to createAndEncrypt, since it is only called in two places:

• When instantiating the class, which should be thread-safe.
• Inside getBytes, which is already synchronized.

I don't think it'd make much difference in performance, but I'll create If you agree I'll create another PR removing it, just for clarity and cleanliness :)

Also, according to Android studio, the wipe method in EncryptionFingerprint is never called. Is this right? shouldn't it be called after calling getBytes to wipe the unobfuscated bytes from memory?

If this is the case, EncryptionFingerprint would not be thread-safe if wipe and getBytes would be called simultaneously from two threads.

Lastly, any chance you could release a new version including this fix? It'd be really helpful for me, otherwise I'll have to find a way to compile and use a version from master in my app.

[patrickfav]

I don't see a reason to add synchronized to createAndEncrypt

True. Only thing it would guard is the constructor, but constructing is atomic afaik, ie. if it is not constructed nobody can call a method on it.

Also, according to Android studio, the wipe method in EncryptionFingerprint is never called. Is this right? shouldn't it be called after calling getBytes to wipe the unobfuscated bytes from memory?

Yes this is correct. This is more for the user of this library so it easily possible to wipe the fingerprint for them. In ByteArrayRuntimeObfuscatorthe createAndEncrypt after getting the bytes overwrites the internal byte array with a re-obfuscated version, so wipe is not necessary (if we are talking about the same thing)

If you want to apply another patch, pls open another PR. I forgot to tell you before last time, but please add the change in the CHANELOG. I will could release 0.8.0 today.