-
Notifications
You must be signed in to change notification settings - Fork 564
[Xamarin.Android.Build.Tasks] added filter to proguard commands #1049
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
@jonathanpeppers, |
|
Should this be a public MSBuild property at all? I'm not sure that this is an extension point that we want to support, or -- alternatively -- I don't fully foresee what we may be signing ourselves up for by exposing this as a public property. Additionally, I'm not sure about the longevity of ProGuard, given that Google is working on d8/etc. as a replacement. I'd feel better if this were a private -- |
0004a63 to
efd16f5
Compare
efd16f5 to
f4e9266
Compare
|
🤦♂️ my two new tests are failing because of this PR's description being passed as an environment variable I put I think the easiest thing is to clear out |
Context: https://bugzilla.xamarin.com/show_bug.cgi?id=56834 A default multi-dex application will print a warning to the console such as: ``` Warning: can't write resource [META-INF/MANIFEST.MF] (Duplicate zip entry [android-support-multidex.jar:META-INF/MANIFEST.MF]) ``` This is due to most jar files containing a `META-INF/MANIFEST.MF`, which really just needs to be excluded from the proguard command. We can do this by adding a filter to the end of each jar file passed via the `-injars` command line option. Changes: - Added a `$(_AndroidProguardInputJarFilter)` internal property, which defaults to `(!META-INF/MANIFEST.MF)` so we ignore the most common warning by default - Added a `ProguardInputJarFilter` property to the `<Proguard />` and `<CreateMultiDexMainDexClassList />` tasks - Added assertions to multi-dex unit tests making sure we aren't getting the warning anymore - Minor fix to clear the `ghprbPullLongDescription` environment variable during tests, otherwise my PR/commit message causes my new test assertions to fail
f4e9266 to
5ac1a69
Compare
I noticed on Windows, the `Desugar(True, True, True)` test was failing with: ``` java.io.IOException: Can't read [E:\A\_work\1\s\bin\TestDebug\temp\Desugar(True,True,True)\obj\Release\android\bin\classes\classes.zip(!META-INF\MANIFEST.MF)] (No such file or directory) ``` However, running locally proved the file does exist. Somehow dotnet#1049 introduced a case where proguard is failing due to the combination the new `(!META-INF/MANIFEST.MF)` filter and the parameters passed to proguard in this test. Looking into it, we had an odd form of how the paths were being passed on Windows using a combination of single and double-quotes: ``` -injars "'path1(!META-INF/MANIFEST.MF)';'path2(!META-INF/MANIFEST.MF)'" ``` The way these paths were passed was not working on Windows after adding this new filter. It worked correctly on Windows when specified as: ``` -injars "path1(!META-INF/MANIFEST.MF)";"path2(!META-INF/MANIFEST.MF)" ``` So keep things consistent, I refactored the code to use " on Windows and ' on other platforms. This also resolved the issues in the `Desugar` test on Windows, for which I also added an additional assertion.
I noticed on Windows, the `Desugar(True, True, True)` test was failing with: ``` java.io.IOException: Can't read [E:\A\_work\1\s\bin\TestDebug\temp\Desugar(True,True,True)\obj\Release\android\bin\classes\classes.zip(!META-INF\MANIFEST.MF)] (No such file or directory) ``` However, running locally proved the file does exist. Somehow dotnet#1049 introduced a case where proguard is failing due to the combination the new `(!META-INF/MANIFEST.MF)` filter and the parameters passed to proguard in this test. Looking into it, we had an odd form of how the paths were being passed on Windows using a combination of single and double-quotes: ``` -injars "'path1(!META-INF/MANIFEST.MF)';'path2(!META-INF/MANIFEST.MF)'" ``` The way these paths were passed was not working on Windows after adding this new filter--but only for this `Desugar` test... Most cases were working, such as our tests around multi-dex and proguard. It worked correctly on Windows when specified as: ``` -injars "path1(!META-INF/MANIFEST.MF)";"path2(!META-INF/MANIFEST.MF)" ``` So keep things consistent, I refactored the code to use " on Windows and ' on other platforms. This also resolved the issues in the `Desugar` test on Windows, for which I also added an additional assertion.
I noticed on Windows, the `Desugar(True, True, True)` test was failing with: ``` java.io.IOException: Can't read [E:\A\_work\1\s\bin\TestDebug\temp\Desugar(True,True,True)\obj\Release\android\bin\classes\classes.zip(!META-INF\MANIFEST.MF)] (No such file or directory) ``` However, running locally proved the file does exist. Somehow dotnet#1049 introduced a case where proguard is failing due to the combination the new `(!META-INF/MANIFEST.MF)` filter and the parameters passed to proguard in this test. Looking into it, we had an odd form of how the paths were being passed on Windows using a combination of single and double-quotes: ``` -injars "'path1(!META-INF/MANIFEST.MF)';'path2(!META-INF/MANIFEST.MF)'" ``` The way these paths were passed was not working on Windows after adding this new filter--but only for this `Desugar` test... Most cases were working, such as our tests around multi-dex and proguard. It worked correctly on Windows when specified as: ``` -injars "path1(!META-INF/MANIFEST.MF)";"path2(!META-INF/MANIFEST.MF)" ``` So keep things consistent, I refactored the code to use " on Windows and ' on other platforms. This also resolved the issues in the `Desugar` test on Windows, for which I also added an additional assertion.
I noticed on Windows, the `Desugar(True, True, True)` test was failing with: ``` java.io.IOException: Can't read [E:\A\_work\1\s\bin\TestDebug\temp\Desugar(True,True,True)\obj\Release\android\bin\classes\classes.zip(!META-INF\MANIFEST.MF)] (No such file or directory) ``` However, running locally proved the file does exist. Somehow dotnet#1049 introduced a case where proguard is failing due to the combination the new `(!META-INF/MANIFEST.MF)` filter and the parameters passed to proguard in this test. Looking into it, we had an odd form of how the paths were being passed on Windows using a combination of single and double-quotes: ``` -injars "'path1(!META-INF/MANIFEST.MF)';'path2(!META-INF/MANIFEST.MF)'" ``` The way these paths were passed was not working on Windows after adding this new filter--but only for this `Desugar` test... Most cases were working, such as our tests around multi-dex and proguard. It worked correctly on Windows when specified as: ``` -injars "path1(!META-INF/MANIFEST.MF)";"path2(!META-INF/MANIFEST.MF)" ``` So keep things consistent, I refactored the code to use " on Windows and ' on other platforms. This also resolved the issues in the `Desugar` test on Windows, for which I also added an additional assertion.
I noticed on Windows, the `Desugar(True, True, True)` test was failing with: ``` java.io.IOException: Can't read [E:\A\_work\1\s\bin\TestDebug\temp\Desugar(True,True,True)\obj\Release\android\bin\classes\classes.zip(!META-INF\MANIFEST.MF)] (No such file or directory) ``` However, running locally proved the file does exist. Somehow dotnet#1049 introduced a case where proguard is failing due to the combination the new `(!META-INF/MANIFEST.MF)` filter and the parameters passed to proguard in this test. Looking into it, we had an odd form of how the paths were being passed on Windows using a combination of single and double-quotes: ``` -injars "'path1(!META-INF/MANIFEST.MF)';'path2(!META-INF/MANIFEST.MF)'" ``` The way these paths were passed was not working on Windows after adding this new filter--but only for this `Desugar` test... Most cases were working, such as our tests around multi-dex and proguard. It worked correctly on Windows when specified as: ``` -injars "path1(!META-INF/MANIFEST.MF)";"path2(!META-INF/MANIFEST.MF)" ``` So keep things consistent, I refactored the code to use " on Windows and ' on other platforms. This also resolved the issues in the `Desugar` test on Windows, for which I also added an additional assertion.
I noticed on Windows, the `Desugar(True, True, True)` test was failing with: ``` java.io.IOException: Can't read [E:\A\_work\1\s\bin\TestDebug\temp\Desugar(True,True,True)\obj\Release\android\bin\classes\classes.zip(!META-INF\MANIFEST.MF)] (No such file or directory) ``` However, running locally proved the file does exist. Somehow #1049 introduced a case where proguard is failing due to the combination the new `(!META-INF/MANIFEST.MF)` filter and the parameters passed to proguard in this test. Looking into it, we had an odd form of how the paths were being passed on Windows using a combination of single and double-quotes: ``` -injars "'path1(!META-INF/MANIFEST.MF)';'path2(!META-INF/MANIFEST.MF)'" ``` The way these paths were passed was not working on Windows after adding this new filter--but only for this `Desugar` test... Most cases were working, such as our tests around multi-dex and proguard. It worked correctly on Windows when specified as: ``` -injars "path1(!META-INF/MANIFEST.MF)";"path2(!META-INF/MANIFEST.MF)" ``` So keep things consistent, I refactored the code to use `"` on Windows and `'` elsewhere. This also resolved the issues in the `Desugar` test on Windows, for which I also added an additional assertion.
Context: https://bugzilla.xamarin.com/show_bug.cgi?id=56834
A default multi-dex application will print a warning to the console
such as:
This is due to most jar files containing a
META-INF/MANIFEST.MF,which really just needs to be excluded from the proguard command.
We can do this by adding a filter to the end of each jar file passed
via the
-injarscommand line option.Changes:
$(_AndroidProguardInputJarFilter)internal property, whichdefaults to
(!META-INF/MANIFEST.MF)so we ignore the most common warningby default
ProguardInputJarFilterproperty to the<Proguard />and<CreateMultiDexMainDexClassList />tasksthe warning anymore
ghprbPullLongDescriptionenvironment variable duringtests, otherwise my PR/commit message causes my new test assertions to fail