gradles compile command (which is deprecated and should be replaced with implementation) includes the arguments resources into the result jar.
That means that smack-android will contain resources found at the android boot classpath.
This results in a +~11mb increase in size of the resulting apk when including Smack as a composite build. The increase comes from 11mb of Android resources, mainly drawables.
compileOnly (formerly provided) on the other hand will assert that the android.jar classes are provided by the system, which is probably what we want in this case.
there is no reason why we want to store the bytes of the base64
encoded string. Simply store the string itself.
Also add a convenience method to get the decoded bytes of the PubKey.
- Reduce the amount of types that are subtypes of NamedElement. See
javadoc of NamedElement for rationale.
- Work more with XmlEnvironment in XmlStringBuilder.
- Some minor changes to XmlStringBuilder API.
to ensure that javadocAll works correctly. A nice side-effect, this
also ensures that the package-info.java symbolic links are still
correct and haven't been replaced by some IDE or editor with the
content of the link target.
This is needed for javadocAll since otherwhise there will be
smack-core/src/main/java/org/jivesoftware/smack/package-info.java:21:
warning: a package-info.java file has already been seen for
package org.jivesoftware.smack
warnings.
by using PubSubManager.tryToPublishAndPossibleAutoCreate().
This also swaps the parameters of the method.
Thanks to Guus der Kinderen for suggesting this.
Those exception are caused by I/O operations in the OmemoStore, which
is now declaring that it throws those (since it is not uncommon for
I/O operations to cause IOExceptions). After all, this is nicely
demonstrated as this change is caused by switching with this commit to
the Android API 19 compatible methods in FileBasedOmemoStore, which
throw.
The library can not decide what to do in case of those exceptions,
hence it is sensible to expose them to the user.
