Kotlin reflect proguard SmallSortedMap - android-gradle-plugin

Warning: kotlin.reflect.jvm.internal.KClassImpl: can't find referenced class kotlin.reflect.jvm.internal.KClassImpl$kotlin.reflect.jvm.internal.KClassImpl$Data
Warning: kotlin.reflect.jvm.internal.KClassImpl: can't find referenced class kotlin.reflect.jvm.internal.KClassImpl$kotlin.reflect.jvm.internal.KClassImpl$Data
Warning: kotlin.reflect.jvm.internal.KClassImpl$data$1: can't find referenced class kotlin.reflect.jvm.internal.KClassImpl$kotlin.reflect.jvm.internal.KClassImpl$Data
Warning: kotlin.reflect.jvm.internal.KClassImpl$data$1: can't find referenced class kotlin.reflect.jvm.internal.KClassImpl$kotlin.reflect.jvm.internal.KClassImpl$Data
Warning: kotlin.reflect.jvm.internal.impl.protobuf.SmallSortedMap: can't find referenced class kotlin.reflect.jvm.internal.impl.protobuf.SmallSortedMap$kotlin.reflect.jvm.internal.impl.protobuf.SmallSortedMap$Entry
Warning: kotlin.reflect.jvm.internal.impl.protobuf.SmallSortedMap: can't find referenced class kotlin.reflect.jvm.internal.impl.protobuf.SmallSortedMap$kotlin.reflect.jvm.internal.impl.protobuf.SmallSortedMap$EntrySet
Warning: kotlin.reflect.jvm.internal.impl.protobuf.SmallSortedMap$Entry: can't find referenced class kotlin.reflect.jvm.internal.impl.protobuf.SmallSortedMap$kotlin.reflect.jvm.internal.impl.protobuf.SmallSortedMap$Entry
Warning: kotlin.reflect.jvm.internal.impl.protobuf.SmallSortedMap$Entry: can't find referenced class kotlin.reflect.jvm.internal.impl.protobuf.SmallSortedMap$kotlin.reflect.jvm.internal.impl.protobuf.SmallSortedMap$Entry
I'm getting these warnings which break my release build on the task transformClassesAndResourcesWithProguardForAppRelease.
I know I can just ignore the warnings or inform proguard to not warn by using -dontwarn but I was wondering if anyone else had come across this and had actually found the correct fix.
I'm using Kotlin version 1.1.4-2

Quoting Alexander Udalov from issue KT-7652:
In any way, reflection failures when kotlin.* is obfuscated are expected at the moment. What we can do is work on a useful set of rules for proguard to minimize the binary size of the reflection library.
So there is no correct fix at the moment.

Related

Soong build Error: this class can only be used as an annotation or as an argument to #UseExperimental

I am Using soong build system with kotlin and want to opt in for experimental APIs to be used in the code
I have added #file:OptIn(kotlinx.coroutines.ExperimentalCoroutinesApi::class) in kotling file but upon compiling I get error stated as
error: this class can only be used as an annotation or as an argument to #UseExperim
ental
#file:OptIn(kotlinx.coroutines.ExperimentalCoroutinesApi::class)
Can anyone tell me what additional things I need to do to make it work ?

How to disable proguard in javafxports for errors "You should consider keeping the * attributes"

I'm trying to use JavaFX in my android device, with the help of javafxports.
I used the XStream to parse some XML file in my program.
When i compile them, the javafxports outputs the following warnings:
Note: there were 9 classes trying to access annotations using reflection.
You should consider keeping the annotation attributes
(using '-keepattributes *Annotation*').
(http://proguard.sourceforge.net/manual/troubleshooting.html#attributes)
Note: there were 32 classes trying to access generic signatures using reflection.
You should consider keeping the signature attributes
(using '-keepattributes Signature').
(http://proguard.sourceforge.net/manual/troubleshooting.html#attributes)
Note: there were 56 unresolved dynamic references to classes or interfaces.
You should check if you need to specify additional program jars.
(http://proguard.sourceforge.net/manual/troubleshooting.html#dynamicalclass)
Note: there were 3 class casts of dynamically created class instances.
You might consider explicitly keeping the mentioned classes and/or
their implementations (using '-keep').
(http://proguard.sourceforge.net/manual/troubleshooting.html#dynamicalclasscast)
Note: there were 39 accesses to class members by means of introspection.
You should consider explicitly keeping the mentioned class members
(using '-keep' or '-keepclassmembers').
(http://proguard.sourceforge.net/manual/troubleshooting.html#dynamicalclassmember)
Note: you're ignoring all warnings!
The output .apk can be installed and run until it calls the xstream classes to read annotations in my classes. The reason is actually described in the warnings.
So my question is, how can i disable the proguard when generating .apk, or send it a custom proguard.pro configuration.
And my build.gradle is almost the same as that in the helloworld example.
Thanks.

Is all of a static library included in a final product after linking?

Suppose I create an iOS application. I include a static library. I create an object of a class that is defined and implemented in static library. This object doesn't use other classes defined in the library. Will all of the static library be present in the application I build? The idea is that much of the static library contains unused code and wouldn't need to be present.
I believe there a flags that help determine the behavior -- if someone can spell out how this works, I sure would appreciate it.
A static library is an archive of object files. If you link against a static library libfoo.a then
the linker by default will link into your final executable all and only those object files in libfoo.a
that are required to provide definitions for the public symbols that are referenced by the program.
More specifically, if the linker finds the library requested (via the option -lfoo) at a given
point in the commandline sequence of object files and libraries to be linked, then it will
extract from the archive and link into the executable each object file in the archive that provides
a definition for any symbol that remains undefined up to that point in the linkage.
In so doing, definitions of unused public symbols may be redundantly linked into
your program, but only if they are found in an object file (whether free-standing or a member of
a library) that is not completely redundant.
If you do not want to tolerate even those potential redundancies, then a combination of
compiler and linker options can eliminate them: see this answer

Warnings while using a plugin and static library in a cocoa project

I have a scenario where I need to use a plugin as well as a static library into my xcode project. The plugin will be dynamically loaded into the system. Now, the static library is also getting used in creation of the plugin.
While executing my project I am getting a warning saying :
Class A is getting referenced from /staticLibraryPath and plugin. One of them will be used.
Please let me know, how to resolve the warning or a better way of implementing the scenario.
The issue is a name class of the two ClassA types found in both plugin and library
I assume you have control over the source of either plugin / library.
.. rename Class A in one instance to make the names not clash -- I don't think there is another way to get rid of the warning/error

Getting CMake to give an error/warning about unreferenced symbols

I'm wondering how I would go about making CMake produce an error, or at least a warning, when the linker cannot find symbols that are referenced in a source file?
For example, let's say I have foo.c:
#include "bar.h" //bar.h provides bar()
void foo(void)
{
bar()
return;
}
In the case that I am building a static library, if i am not smart about how i have used my add_library() directive, the default behavior seems to be to not even give a warning that bar is an unreferenced symbols in foo's object archive file (.a)
The CMAKE_SHARED_LINKER_FLAGSĀ compiler flags for building shared libraries should get the compiler to do what you want.
set(CMAKE_SHARED_LINKER_FLAGS "-Wl,--no-undefined")
On Unix systems, this will make the linker report any unresolved symbols from object files (which is quite typical when you compile many targets in CMake projects, but do not bother with linking target dependencies in proper order).
Source: http://www.cmake.org/Wiki/CMake_Useful_Variables
There's the -z now for the GCC linker these days, but yeah, this isn't CMake's problem.
The most fool-proof way I've found only works on shared libraries, but what you do is basically write a test for each shared library and it then just does dlopen(path, RTLD_NOW) (and similar for Windows) and then use its return value as the test return value. To get a list of all shared objects, I have a wrapper function around add_library which adds all shared libraries to a global property which then is used to generate the tests dynamically. I remember there being some way to tell if a target was shared or static, but I'm not finding it the docs right now.