Fixed
Status Update
Comments
ap...@google.com <ap...@google.com> #2
Also this should be handled like Activities with results. Some stubbing of intent should be possible and then checking permission result. just like the espresso intents are done.
ap...@google.com <ap...@google.com> #3
I've implemented a solution which leverages wrapper classes, overriding and build variant configuration. The solution is quite long to explain and is found over here: https://github.com/ahasbini/AndroidTestMockPermissionUtils .
It is not yet packed in an sdk but the main idea is to override the functionalities of ContextWrapper.checkSelfPermission and ActivityCompat.requestPermissions to be manipulated and return mocked results tricking the app into the different scenarios to be tested like: permission was denied hence the app requested it and ended with granted permission. This scenario will occur even if the app had the permission all along but the idea is that it was tricked by the mocked results from the overriding implementation.
It is not yet packed in an sdk but the main idea is to override the functionalities of ContextWrapper.checkSelfPermission and ActivityCompat.requestPermissions to be manipulated and return mocked results tricking the app into the different scenarios to be tested like: permission was denied hence the app requested it and ended with granted permission. This scenario will occur even if the app had the permission all along but the idea is that it was tricked by the mocked results from the overriding implementation.
na...@google.com <na...@google.com> #4
This bug has not been updated in over a year. Please reopen if this is still an issue or requires addition inspection.
Description
Some more details in b/388353336
Start of trace:
This happens because when we draw we use a shared ContentDrawScope implementation that we render all DrawModifierNodes in. We do this by mutating a property as we draw successive nodes. However, this means that if anyone captures a reference to this draw scope and tries to draw it later on, this will cause a NPE error as we don't know what the 'current node' that needs to be drawn in.
For the general case this is an error and scopes shouldn't be captured and stored outside the scope in this way, but for GraphicsLayer this is needed when recording drawContent to support some edge cases, such as when we need to draw a layer implementation that can't be drawn in software, within software rendering (such as drawing to a Bitmap). For this we just end up re-invoking the draw block we captured.
We considered some solutions where we would allocate a new draw scope instance per modifier, but this adds some overhead and 'storing' these draw scopes for future use is challenging. (we considered putting them on the node object, in a map on the node coordinator, or some other chain structure on the node coordinator, but none of these are really great)
Instead we can explicitly support the GraphicsLayer.record case by overriding the DrawScope#GraphicsLayer.record function and making it handle this case properly. This can still cause issues if using the non-DrawScope scoped record function, but developers should move to the DrawScope one instead.