[layertracegenerator] be more resilient to unknown layer ids
While unexpected, the layer lifecycle in legacy which is used to
generate the transaction traces is less explicit. We rely on layer
destruction when the object becomes unreachable. The new
front end logic will crash if called with an unknown layer id.
While we have to interop between both sets of logic, log and
ignore the unknown layer ids so we can still generate useful
layer traces.
Fixes: 275630566
Test: presbumit
Change-Id: I5b2a217c78b4a9e94f0772459d6aa0c68a8a51d0
diff --git a/services/surfaceflinger/FrontEnd/LayerLifecycleManager.h b/services/surfaceflinger/FrontEnd/LayerLifecycleManager.h
index 3d9a74c..f258678 100644
--- a/services/surfaceflinger/FrontEnd/LayerLifecycleManager.h
+++ b/services/surfaceflinger/FrontEnd/LayerLifecycleManager.h
@@ -39,7 +39,11 @@
public:
// External state changes should be updated in the following order:
void addLayers(std::vector<std::unique_ptr<RequestedLayerState>>);
- void applyTransactions(const std::vector<TransactionState>&);
+ // Ignore unknown layers when interoping with legacy front end. In legacy we destroy
+ // the layers it is unreachable. When using the LayerLifecycleManager for layer trace
+ // generation we may encounter layers which are known because we don't have an explicit
+ // lifecycle. Ignore these errors while we have to interop with legacy.
+ void applyTransactions(const std::vector<TransactionState>&, bool ignoreUnknownLayers = false);
// Ignore unknown handles when iteroping with legacy front end. In the old world, we
// would create child layers which are not necessary with the new front end. This means
// we will get notified for handle changes that don't exist in the new front end.