Status Update
No update yet.
Comments
al...@android.com
la...@gmail.com
We are currently using AGP internal task types to flag memory-intensive tasks to enforce a reduced parallelism at execution time. I've raised this separately (with a lot more detail) as a feature request (
ni...@google.com
Another use case that we have is to reactively respond to the creation of APKs and AABs. The new AGP APIs allow us to connect out tasks into the artifact pipeline via wiredWith but the best we can come up with to receive the completed artifact is to wire in toTransform. This A) does not guarantee that we will receive the final artifact as more transforms may be applied after our task is called, and B) requires us to copy the input property file/dir to our tasks output property file/dir in order to not break the build cache.
The reactive behavior of the above is the complicating factor.
A non-reactive approach could simply depend upon the task name and then look for a hardcoded path in the build directory (which is still sort of gross, since the build output paths are not documented as public API and change from time to time).
Another approach would be to wire a custom task to consume the output of the build via the built artifacts loader feeding an input property. However, this approach cannot be applied reactively. Either the custom task is included in the build and causes the creation of the binary artifact, or it is not included in the build and never gets invoked.
Description
consider the following code
getSupportFragmentManager()
.beginTransaction()
.disallowAddToBackStack()
.add(android.R.id.content, fragmentA, fragmentA.TAG)
.add(android.R.id.content, fragmentB, fragmentB.TAG)
.commit();
the correct add order of the two fragment should be fragmentA, then fragmentB.
This works fine in previous version of support-v4, however when I updated support-v4 to version 23.3.0.
the order somehow changed to fragmentB, then fragmentA, and as a consequence, fragmentB covered fragmentA completely. (In my case, fragmentA is opaque, while fragmentB is transparent).
this bug only happens on Lollipop or above, since it lays in the fragment transition part.
And I did find out the reason.
The BackStackRecord.java of new version (23.3.0) of support-v4 has an extra line of code at the begining of
private TransitionState beginTransition(SparseArray<Fragment> firstOutFragments,
SparseArray<Fragment> lastInFragments, boolean isBack);
let's see:
===========================
23.3.0:
private TransitionState beginTransition(SparseArray<Fragment> firstOutFragments,
SparseArray<Fragment> lastInFragments, boolean isBack) {
ensureFragmentsAreInitialized(lastInFragments); //this is the new added line of code
TransitionState state = new TransitionState();
...
return state;
}
============================
23.1.1:
private TransitionState beginTransition(SparseArray<Fragment> firstOutFragments,
SparseArray<Fragment> lastInFragments, boolean isBack) {
TransitionState state = new TransitionState();
....
}
===========================
and in the ensureFragmentsAreInitialized() method, it make the last in fragment active:
===========================
/**
* Ensure that fragments that are entering are at least at the CREATED state
* so that they may load Transitions using TransitionInflater.
*/
private void ensureFragmentsAreInitialized(SparseArray<Fragment> lastInFragments) {
final int count = lastInFragments.size();
for (int i = 0; i < count; i++) {
final Fragment fragment = lastInFragments.valueAt(i);
if (fragment.mState < Fragment.CREATED) {
mManager.makeActive(fragment);
mManager.moveToState(fragment, Fragment.CREATED, 0, 0, false);
}
}
}
========================
and the makeActive() method will set the index of fragments according to the order fragments are made active.
So, we successfully make the last in fragment be the first one added!!!!