Just dumping some raw notes about the future architecture:
A thing you can call to trigger a heap dump + analysis
That thing is a simple interface which takes a Trigger reason, typed.
Maybe it's an Any? Maybe marker interface. This will make it possible
to tag, but also skip conditions by wrapping them in a "force" condition.
There's a condition that returns Yes or Nope with a reason.
In tests the trigger will likely be "DetectLeaksAssert" and we'd skip any other
DetectLeaksInterceptor looks very much like the conditions we want.
Also somewhat similar to leakcanary.internal.HeapDumpControl.iCanHasHeap
However there the reason is a lazy string, and we have NotifyingNope which triggers
notifications. So we need a way to have silent canceling and noisy canceling.
Thing is, in the general leakcanary case we don't always need the string reason.
Then we trigger.
We also need to pull a directory id.
That requires doing additional prework like saving android ids, storing the dump
Getting a file might fail. Dumping might fail.
There's some notion of parallel threads and multiple jobs here. Every time we
get a request to trigger, we should store that, and make it possible for anyone to
cancel that request / all requests at any time. Maybe the request has a stage? but
maybe not because we want decoupling.
heap dump directory: releases want to have some control over the file itself and delete
it immediately. also wants to run GC. but not check for retained.
After the heap is dumped, we migth want to analyze it, and even double analyze.
Might want to send it to another process. etc.
We're essentially sending a file to the thing.