Fixed
Status Update
Comments
je...@google.com <je...@google.com>
ku...@google.com <ku...@google.com> #2
Question to discuss: how come we produce lists inconsistently, so that they have to be sorted.
bu...@google.com <bu...@google.com> #3
About #2:
Since OutputScope.apkDatas is a List, it depends on the order it's inserted on that list.
My first guess would be that methods like ApplicationVariantFactory.populateMultiApkOutputs(...), that receives Sets as inputs, could iterate over those sets in a not-deterministic way* which cause the calls to add outputs to the OutputScope (via the OutputFactory) to add them in a non-deterministic way every time.
*Which indeed is the case, as the abi/densitiy/language filters set are created by BaseVariantData.getFilters(), which returns an HashSet, that does not guarantee an iteration order.
I think a nice way to fix this would be:
1) Make OutputScope immutable.
1b) Move OutputScope's addSplit to a new OutputScope.Builder class.
2) Change the BaseVariantData to:
a) Instead of creating and passing the OutputScope to the OutputFactory object, like it does today:
outputScope = new OutputScope();
outputFactory =
new OutputFactory(
globalScope.getProjectBaseName(), variantConfiguration, outputScope);
To receive a Provider<OutputScope> from the OutputFactory (like outputScopeProvider = outputFactory.getOutputScopeProvider()). This provider will just call the OutputScope.Builder .build() method. (We can make this a cachable-provider, either on the OutputFactory or on BaseVariantData level, tbd how it looks better).
We'll need to move those who directly access scope.outputScope member (10 places? but we don't need to worry about the ones in kotlin :) to something like scope.getOutputScope() that will call the provider instead.
Since OutputScope.apkDatas is a List, it depends on the order it's inserted on that list.
My first guess would be that methods like ApplicationVariantFactory.populateMultiApkOutputs(...), that receives Sets as inputs, could iterate over those sets in a not-deterministic way* which cause the calls to add outputs to the OutputScope (via the OutputFactory) to add them in a non-deterministic way every time.
*Which indeed is the case, as the abi/densitiy/language filters set are created by BaseVariantData.getFilters(), which returns an HashSet, that does not guarantee an iteration order.
I think a nice way to fix this would be:
1) Make OutputScope immutable.
1b) Move OutputScope's addSplit to a new OutputScope.Builder class.
2) Change the BaseVariantData to:
a) Instead of creating and passing the OutputScope to the OutputFactory object, like it does today:
outputScope = new OutputScope();
outputFactory =
new OutputFactory(
globalScope.getProjectBaseName(), variantConfiguration, outputScope);
To receive a Provider<OutputScope> from the OutputFactory (like outputScopeProvider = outputFactory.getOutputScopeProvider()). This provider will just call the OutputScope.Builder .build() method. (We can make this a cachable-provider, either on the OutputFactory or on BaseVariantData level, tbd how it looks better).
We'll need to move those who directly access scope.outputScope member (10 places? but we don't need to worry about the ones in kotlin :) to something like scope.getOutputScope() that will call the provider instead.
ku...@google.com <ku...@google.com>
fj...@gmail.com <fj...@gmail.com> #4
Hola fj de r
fj...@gmail.com <fj...@gmail.com> #5
Hola Helen varón banana
Description