Status Update
No update yet.
Comments
ha...@google.com
ha...@google.com
Thank you for the nice reproduction. The problem is in the library that defines a service loader implementation file incorrectly. The file META-INF/services/org.xmlpull.v1.XmlPullParserFactory contains:
org.kxml2.io.KXmlParser,org.kxml2.io.KXmlSerializer
The spec clearly states that it should be one per line:
A service provider is identified by placing a provider-configuration file in the resource directory META-INF/services. The file's name is the fully-qualified binary name of the service's type. The file contains a list of fully-qualified binary names of concrete provider classes, one per line...
R8 also gives a warning regarding that:
Warning in /usr/local/google/home/mkroghj/dumps/b279996549/dump/program.jar:META-INF/services/org.xmlpull.v1.XmlPullParserFactory:
Unexpected reference to missing service implementation class in META-INF/services/org.xmlpull.v1.XmlPullParserFactory: org.kxml2.io.KXmlParser,org.kxml2.io.KXmlSerializer.
The reason the context is FastServiceLoader.load is because that is where we enqueue the potential services that can be loaded. I guess this could try and figure out the concrete types that could be loaded instead of all types, but that is difficult since the method takes a class as argument.
R8 will read the type in the implementation as a type with name org.kxml2.io.KXmlParser,org.kxml2.io.KXmlSerializer. You therefore, in principle, need to write -dontwarn org.kxml2.io.KXmlParser,org.kxml2.io.KXmlSerializer. Now the problem here is that -dontwarn takes a list of classes as argument, so we parse that into something similar to:
-dontwarn org.kxml2.io.KXmlParser
-dontwarn org.kxml2.io.KXmlSerializer
The only thing you can write is a prefix, so you could do -dontwarn org.kxml2.io.KXml* and that will silence the compiler and succeed.
Regarding the library, I checked if the error was still present, but the service file was corrected over 3 years ago:
You could see if an update of the library you are using is available or use the -dontwarn pattern above. Will be marking this as WAI.
ko...@gmail.com
I have tried above pattern but that also fail
-dontwarn org.kxml2.io.KXml*
Can you please confirm from sample file with corrected pattern and working solution ?
ha...@google.com
It should be two **. You can decide on any prefix you desire as long as it matches the path.
-dontwarn org.kxml2.io.KXml**
ko...@gmail.com
Thanks mk@, using that pattern issue resolved for now.
ha...@google.com
ko...@gmail.com
ha...@google.com
java.lang.IncompatibleClassChangeError: Class 'android.content.res.XmlBlock$Parser' does not implement interface 'org.xmlpull.v1.a' in call to 'int org.xmlpull.v1.a.next()' (declaration of 'androidx.core.content.FileProvider' appears in base.apk). Gradle 8.0 AGP 8.1.4
I solved it setting this proguard rule.
-keep class org.xmlpull.v1.** {*;}
ha...@google.com
org.xmlpull.v1 in your input. Classes in that namespace are also in the Android runtime,
Description
"action.devices.traits.OnOff" ,"action.devices.traits.TemperatureSetting"
In TestSuite, on "action.devices.traits.OnOff" test, a dialog box appears asking to select "Yes" or "No." Selecting "Yes" will result in success.
But, on "action.devices.commands.ThermostatSetMode" in "action.devices.traits.TemperatureSetting" test, a dialog box to enter characters appears . I tried entering "Yes" or "はい" to the dialog box, but it failed.
I checked at the logs of endpoint Firebase function.
I found that when testing "action.devices.commands.ThermostatSetMode" in TestSuite, endpoint didn't recieve request including "challenge":{"ack":true} .
Therefore, mode change request was not executed and the result was Fail.
The logs when the same operation using the Google Assistant app instead of running TestSuite showed that after I responded "はい"("はい" means "Yes" in Japanese) to secondary user verification, a request including "challenge":{"ack":true} was sent to the endpoint, and the mode change was executed.
Because our air conditioner require secondary user verification to change mode, the endpoint returns an error response like this when it receives a request to change the mode.
{"ids":["XXXXXXXXXXX"],"status":"ERROR","errorCode":"challengeNeeded","challengeNeeded":{"type":"ackNeeded"},"states":{"thermostatMode":"heat","thermostatTemperatureSetpoint":16}}
After user verification , a request including "challenge":{"ack":true} is sent to the endpoint again.
When I changed the mode using my voice in the Google Assistant app, this process was recorded in the log, but when I ran the TestSuite, there was no log of a request including "challenge":{"ack":true}.