Status Update
No update yet.
Comments
ch...@google.com
[Deleted User] <[Deleted User]>
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 (
ch...@google.com
ch...@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.
si...@shadowfax.in
We didn't provide a task wiring helper for that case as there's only one thing to wire, but I can see how the inconsistency can be misleading
Description
Version used: 23.1.1, 23.3.0, 23.2.1, 23.3.0
Theme used: Custom theme based on Theme.AppCompat.Light.NoActionBar
Devices/Android versions reproduced on: Wide variety of devices and Android versions, ranging from 4.2.2 to 6.0.1
I recently started seeing the following two crashes, both of which point to problems obtaining the content view:
Relevant Portion of Stack for Crash #1:
Caused by java.lang.NullPointerException: Attempt to invoke virtual method 'int android.view.ViewGroup.getChildCount()' on a null object reference
at android.support.v7.app.AppCompatDelegateImplV7.createSubDecor(AppCompatDelegateImplV7.java:475)
at android.support.v7.app.AppCompatDelegateImplV7.ensureSubDecor(AppCompatDelegateImplV7.java:309)
at android.support.v7.app.AppCompatDelegateImplV7.setContentView(AppCompatDelegateImplV7.java:273)
at android.support.v7.app.AppCompatActivity.setContentView(AppCompatActivity.java:139)
at com.bleacherreport.android.teamstream.activities.HomeActivity.onCreate(HomeActivity.java:181)
Relevant Portion of Stack for Crash #2:
Caused by: java.lang.RuntimeException: Window couldn't find content container view
at com.android.internal.policy.impl.PhoneWindow.generateLayout(PhoneWindow.java:3611)
at com.android.internal.policy.impl.PhoneWindow.installDecor(PhoneWindow.java:3677)
at com.android.internal.policy.impl.PhoneWindow.getDecorView(PhoneWindow.java:1943)
at android.view.Window.findViewById(Window.java:990)
at android.support.v7.app.AppCompatDelegateImplV7.createSubDecor(AppCompatDelegateImplV7.java:460)
at android.support.v7.app.AppCompatDelegateImplV7.ensureSubDecor(AppCompatDelegateImplV7.java:300)
at android.support.v7.app.AppCompatDelegateImplV7.setContentView(AppCompatDelegateImplV7.java:264)
at android.support.v7.app.AppCompatActivity.setContentView(AppCompatActivity.java:129)
at com.bleacherreport.android.teamstream.activities.HomeActivity.onCreate(HomeActivity.java:186)
As you can see, the crash occurs within the onCreate() method of our HomeActivity, which extends android.support.v7.app.AppCompatActivity. Within AppCompatDelegateImplV7.createSubDecor, the call to mWindow.findViewById(android.R.id.content) sometimes returns null (crash #1). This in turn results in a NullPointerException on line 475. In other situations, even on the same version of Android, we see crash #2, with the error message, "Window couldn't find content container view". To me, this suggests a race condition within the appcompat code.
We were able to reduce the frequency of crashes by downgrading Play Services from 8.4 to 7.8. (We use Play Services exclusively for ads.) I can see no connection between Play Services and this crash, except that one version may have a longer startup than the other, which could alter the timing such that a race condition is more likely to occur.
In our experience, the frequency of crashes is also higher on emulator than on device. Similarly, we are unable to reproduce the crash in a debug build, but can recreate it with some frequency in a release build. These seemingly unrelated factors all seem to support the theory that there's a race condition here.
Based on analytical logging, the savedInstanceState parameter passed into onCreate() is always non-null when the crash occurs, suggesting that the problem is specifically related to recreating the HomeActivity. We use android:configChanges="orientation|screenSize|keyboardHidden" in our AndroidManifest.xml file, so I don't think the Activity is being recreated due to rotation. Instead, it seems that the Activity instance is dropped and then recreated as part of memory management. This is consistent with the fact that we can only reproduce the crash with any frequency by setting the "Don't keep activities" developer option.
Any suggestions? Anything we can do to help identify the source of the problem?