Can't Repro
Status Update
No update yet.
Comments
uc...@google.com
Thank you for your feedback. Team may reach out for more feedback in reproducing or triaging this issue.
ag...@google.com
Thanks for the report Carlos. Is this something that you started seeing in connection with updating from Android Studio 3.1 to 3.2 or is this unrelated to updating Android Studio versions? Are you using proguard for your builds?
ca...@instantbits.com
The issue with LocalStrings.properties I've been seeing for a long time, but I was always able to get around it by instantiating the class that uses that resource on the onCreate method of Application. After 3.2 it worked but then after updating some unrelated jars it stopped working. The LocalStrings.properties was no longer in the apk. Finally I was able to fix it by removing another totally unrelated jar (an ad network).
It is working fine for me right now but there seems to be an issue with some properties files getting removed and I haven't found a proguard or multidex way of telling it to keep specific properties files.
It is working fine for me right now but there seems to be an issue with some properties files getting removed and I haven't found a proguard or multidex way of telling it to keep specific properties files.
ag...@google.com
Thanks for the extra context Carlos. Do you have something that reproduces this that you can share? If you cannot share your code, maybe you can share which libraries you are using so we have a little more to go on?
From your description it seems unlikely that this is a D8 or R8 issue. I'm therefore moving this to the gradle component. Ivan, assigning to you for now.
From your description it seems unlikely that this is a D8 or R8 issue. I'm therefore moving this to the gradle component. Ivan, assigning to you for now.
ca...@instantbits.com
Unfortunately I've never been able to reproduce it on a clean sample, and what is worse, I can't even reproduce it on my own code anymore even after reverting the changes. To be clear there were two separate issues.
The first issue which my original stackoverflow posts were about, that would only happen to some phones. The LocalStrings.properties file was in the apk and yet some phones could not find it. I solved that one by putting a call to instantiate one of my servlets on the onCreate of Application. The LocalStrings.properties file is part of the javax.servlet package. I was never able to reproduce this, I could only see it on Crashlytics. I still see an occasional issue on Crashlytics with LocalStrings.properties but very few.
The second issue, which happened last week, is that after months of working fine with the onCreate trick, I updated a totally unrelated jar and all of the sudden it would fail for everyone including me. Reverting the jar would fix it. Analyzing the apks and the bundles, the broken build didn't have LocalStrings.properties in it. I could go back and forward like that for hours and keep on reproducing it. Eventually I figured that I could keep those updates jars but remove a totally unrelated compile line on gradle, for an ad network, and that would fix the issue as well. That worked, I made a beta release, etc. But then I tried to go back to recreate the issue this week and I can't anymore. I've reverted to first broken build and I can't reproduce it anymore. I don't know if some other library updated since I have some libraries with a + on their compile lines.
Anyways, I guess since I can't even reproduce it anymore I'll have to wait until I can reproduce it again. I could upload some of the broken bundles if you want to compare to the non broken ones?
I am also curious on the first issue, what can I do to force LocalStrings.properties to work other than instantiating my servlet on onCreate of Application? I used that trick because I heard that multidex tried to guess what goes into the first dex file by analyzing what code will run on onCreate or something like that.
By the way, these are the compile lines for the servlet stuff:
compile 'org.eclipse.jetty:jetty-server:8.1.12.v20130726'
compile 'org.eclipse.jetty:jetty-servlet:8.1.12.v20130726'
Thanks.
The first issue which my original stackoverflow posts were about, that would only happen to some phones. The LocalStrings.properties file was in the apk and yet some phones could not find it. I solved that one by putting a call to instantiate one of my servlets on the onCreate of Application. The LocalStrings.properties file is part of the javax.servlet package. I was never able to reproduce this, I could only see it on Crashlytics. I still see an occasional issue on Crashlytics with LocalStrings.properties but very few.
The second issue, which happened last week, is that after months of working fine with the onCreate trick, I updated a totally unrelated jar and all of the sudden it would fail for everyone including me. Reverting the jar would fix it. Analyzing the apks and the bundles, the broken build didn't have LocalStrings.properties in it. I could go back and forward like that for hours and keep on reproducing it. Eventually I figured that I could keep those updates jars but remove a totally unrelated compile line on gradle, for an ad network, and that would fix the issue as well. That worked, I made a beta release, etc. But then I tried to go back to recreate the issue this week and I can't anymore. I've reverted to first broken build and I can't reproduce it anymore. I don't know if some other library updated since I have some libraries with a + on their compile lines.
Anyways, I guess since I can't even reproduce it anymore I'll have to wait until I can reproduce it again. I could upload some of the broken bundles if you want to compare to the non broken ones?
I am also curious on the first issue, what can I do to force LocalStrings.properties to work other than instantiating my servlet on onCreate of Application? I used that trick because I heard that multidex tried to guess what goes into the first dex file by analyzing what code will run on onCreate or something like that.
By the way, these are the compile lines for the servlet stuff:
compile 'org.eclipse.jetty:jetty-server:8.1.12.v20130726'
compile 'org.eclipse.jetty:jetty-servlet:8.1.12.v20130726'
Thanks.
ga...@google.com
Please upload working and failing bundles/apks, so we can compare them. Can you also share your build.gradle files (if you are using "android.packagingOptions" in the DSL it might be ignoring some resources)?
In general, multidex does not affect Java resources (and LocalStrings.properties is a Java resources), it only decides whether classes will be in primary (classes.dex) or seconday dex files.
However, if you are using Proguard, it could be changing the Java resources (using -adaptresourcefilenames or -adaptresourcefilecontents flags). I am wondering if the resources are changed, but code is still referring to the original names, which is causing the failure. Examining the APKs should show if this is the issue.
In general, multidex does not affect Java resources (and LocalStrings.properties is a Java resources), it only decides whether classes will be in primary (classes.dex) or seconday dex files.
However, if you are using Proguard, it could be changing the Java resources (using -adaptresourcefilenames or -adaptresourcefilecontents flags). I am wondering if the resources are changed, but code is still referring to the original names, which is causing the failure. Examining the APKs should show if this is the issue.
ca...@instantbits.com
Is there a way for me to share the files so that only you can get them?
Thanks.
Thanks.
ga...@google.com
You can send them to gavra@google.com, or upload it to Google Drive and share them with me.
ca...@instantbits.com
I have shared stuff on drive and sent an email as well with some more info. Thank you.
ga...@google.com
Comparing working (1512) and broken (1514) bundles, there are 220 Java resources missing from the 1514. Dex is mostly the same, there is a slight difference in naming, and 1512 has 2 classes more. I was unable to reproduce, and the build files reporter shared look ok.
If you see the issue again (some of the Java resources files not showing up in the APK or bundle), can you please examine the Proguard output, as it should contain those files. Proguard output is under "mainModule/build/intermediates/transforms/proguard/debug/0.jar". I will close the issue for now, but if you manage to reproduce the issue again, please update it with new findings.
If you see the issue again (some of the Java resources files not showing up in the APK or bundle), can you please examine the Proguard output, as it should contain those files. Proguard output is under "mainModule/build/intermediates/transforms/proguard/debug/0.jar". I will close the issue for now, but if you manage to reproduce the issue again, please update it with new findings.
Description
Version of Gradle Plugin: 3.2
Version of Gradle: 4.6
Version of Java:
java 10.0.2 2018-07-17
Java(TM) SE Runtime Environment 18.3 (build 10.0.2+13)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode)
OS: Ubuntu 18.04.1 LTS
I made a stackoverflow post since I'm not sure if it is my issue or a bug (
Here is most of the text of the post:
I have an issue which I'm pretty sure is related to multidex. Basically one of the libraries I use has a .properties resource bundle in a jar. As my application started growing I started having issues with it. I've made a couple of posts about it in the past but never had any solutions (
Basically this resource is missing unless I force some of the code on that Jar to run on the Application onCreate method. At least that was the issue until yesterday. I am attaching a picture from Android Studio showing the missing resource.
Yesterday I update a jar that has nothing to do with this but is now larger than it used to be (which I'm assuming means it has more methods), and now the code fails again on this same issue java.util.MissingResourceException: Can't find bundle for base name javax.servlet.LocalStrings, locale en_US but now it fails for everyone, not just some users.
I took apart the apks using apktool for one that works and one that doesn't (basically downgrading those unrelated jars) and there is an unknown folder in both apks but the one that works has those LocalStrings.properties in that folder and the one that doesn't work doesn't have them in that folder. I have unzipped those unrelated jars just to make sure and they don't have that javax.servlet package in there and they are jars so they don't have anything else that might affect the gradle build.
Basically my theory right now is that those jars are just large enough to push the javax.servlet stuff out of the first dex file, but that isn't entirely right because the properties files don't even go in the dex file. If I just unzip the apk, I can see the javax package on the root folder and the resource files inside the right place but not LocalStrings.properties whereas if I do that for an apk that works, I can see LocalStrings.properties in there.
I have once again gotten around the issue by removing a compile dependency that I am not longer using, an ad network. I realized I still had that dependency when I used dex2smali to look at the first dex file and saw it was there. So it definitely appears to be an issue with the size of the jars it puts on the first dex file.
I've been testing multiDexKeepProguard and I got all javax.servlet to go in the main dex file but I still can't get LocalStrings.properties to show up in the apk, even with:
-keepclassmembers class **$Properties
I've also tried a few other crazy things like putting the LocalStrings.properties files inside my main app package using the javax.servlet package and it didn't help either.
So what else can I try? Is this a bug or am I doing something wrong?
If needed I can provide an apk or aab file with and without the properties files for comparison.