Question: Are there disadvantages/pitfalls when replacing internal base64 class with android.util.Base64?

[GerritDeMeulder]

• I have verified there are no duplicate active or recent bugs, questions, or requests.
• I have verified that I am using the latest version of PiracyChecker.
• I have given my issue a non-generic title.
• I have read over the documentation (before asking questions on how to do something).

Details

• PiracyChecker version: 1.2.3

I know it's always hard to "kill your darlings", especially when I see that probably a lot of work went into the Base64.class. But because of {@link CharBase64} not working, I found on Robert Harder's site link http://iharder.sourceforge.net/base64/ that it is built-in since java 8, and android has android.util.Base64 class.

I'm no expert in this matter, thus my question :
are there disadvantages/pitfalls when replacing this with the standard library?

Edit : searching for Base64 in the entire project, I found that the android library version Base64.encodeToString is already used in LibraryUtils class.
So is there any reason, why not to use Base64.encode for byte-arrays in the classes AESObfuscator, LibraryChecker and LibraryValidator (see below) ?

I tried it on the library app, and the main PiracyCheckerTest ran to success, so it seems to be working fine.
(still have to test on Android play store with a real app later on)

That leads me to a secondary question : How to unzip or use apk in files SampleUnauthorizedApp.zip for the second test, UnauthorizedAppTest because it is locked with a password, and second part of this test fails ?

Changes I made :

1. AESObfuscator class
   method obfuscate
   change to : import android.util.Base64
   change Base64.encode(...) ->Base64.encode(... , Base64.DEFAULT)
   (or maybe better : Base64.URL_SAFE ?)
   method unobfuscate (NB: maybe change to unObfuscate for better camelCase ?)
   change Base64.decode(...) ->Base64.decode(... , Base64.DEFAULT)
   change catch (Base64DecoderException... to catch (IllegalArgumentException...

2. same goes for decodes in LibraryChecker and LibraryValidator classes