When we cared only about 32-bit Monochrome, and before modules were a thing, it wasn't relevant to track which file symbols belonged to because there was only:
* 1 native library
* 1 dex file
* 1 apk.

This doesn't hold true in a few places now:
1. 64-bit monochrome is no longer using apk_merger.py, so has two libmonochrome's (32-bit and 64-bit)
2. We have 2 dex files (webapk.dex, and classes.dex). We may have more in the future if we hit the multidex limit.
3. With bundles, we'll also have multiple APK files!

Things I'd like to maintain:
- That the fundamental data remains a flat list of symbols
  * e.g. alternative is to introduce a hierarchy, but hierarchies complicate filtering & diffing logic.

Idea #1 - add a "container" field to each symbol, which is a string.

Example container names:
container="Monochrome.apk/libmonochrome.so"
container="Monochrome.apk/classes.dex"
container="Monochrome.apk/chrome_100_percent.pak"  <-- But don't split locale paks.
container="Monochrome.apk/other"
container="Monochrome.apk/webapk.dex"
container="VrModule.apk/classes.dex"

Pros:
* Simple addition to what we have now
Cons:
* Requires file-format change (to both .size and .ndjson)
  * Should be able to store this info similar to how section_name is stored.
* Need to update semantics of section: addresses are unique within sections within container.



Idea #2 - Store container as prefix on section_name

section_name="Monochrome.apk/libmonochrome.so/.text"
section_name="Monochrome.apk/classes.dex/.dex.method"
section_name="Monochrome.apk/chrome_100_percent.pak/.pak.nontranslated"
section_name="Monochrome.apk/other/.pak.translated"
section_name="Monochrome.apk/other/.other"
section_name="Monochrome.apk/webapk.dex/.dex.method"
section_name="VrModule.apk/classes.dex/.dex.method"

Pros:
 - no file format change
 - no extra fields
 - Matches existing semantics of section: addresses are unique within sections.
Cons:
 - Need to update all section_name uses to use .endswith()
 - Can no longer uniquely map from single-letter section name -> full section_name
 - Supersize UI would also need to be updated, and likely also ndjson format


Currently leaning towards the first idea, since it's generally easier to leave things in separate fields.
 

When we cared only about 32-bit Monochrome, and before modules were a thing, it wasn't relevant to track which file symbols belonged to because there was only:
* 1 native library
* 1 dex file
* 1 apk.

This doesn't hold true in a few places now:
1. 64-bit monochrome is no longer using apk_merger.py, so has two libmonochrome's (32-bit and 64-bit)
  * We should consider not breaking armeabi-v7a/libmonochrome.so into symbols when arm64-v8a/libmonochrome.so exists.
  * It doubles the size / runtime, and captures information already available from the 32-bit .apk
2. We have 2 dex files (webapk.dex, and classes.dex). We may have more in the future if we hit the multidex limit.
3. With bundles, we'll also have multiple APK files!

Things I'd like to maintain:
- That the fundamental data remains a flat list of symbols
  * e.g. alternative is to introduce a hierarchy, but hierarchies complicate filtering & diffing logic.

Idea #1 - add a "container" field to each symbol, which is a string.

Example container names:
container="Monochrome.apk/lib/armeabi-v7a/libmonochrome.so"
container="Monochrome.apk/classes.dex"
container="Monochrome.apk/assets/webapk.dex"
container="Monochrome.apk/assets/chrome_100_percent.pak"  <-- But don't split locale paks.
container="Monochrome.apk" <-- for everything else
container="VrModule.apk/classes.dex"

Pros:
* Simple addition to what we have now
Cons:
* Requires file-format change (to both .size and .ndjson)
  * Should be able to store this info similar to how section_name is stored.
* Need to update semantics of section: addresses are unique within sections within container.



Idea #2 - Store container as prefix on section_name

section_name="Monochrome.apk/lib/armeabi-v7a/libmonochrome.so/.text"
section_name="Monochrome.apk/classes.dex/.dex.method"
section_name="Monochrome.apk/assets/webapk.dex/.dex.method"
section_name="Monochrome.apk/assets/chrome_100_percent.pak/.pak.nontranslated"
section_name="Monochrome.apk/.pak.translated"
section_name="Monochrome.apk/.other"
section_name="VrModule.apk/classes.dex/.dex.method"

Pros:
 - no file format change
 - no extra fields
 - Matches existing semantics of section: addresses are unique within sections.
Cons:
 - Need to update all section_name uses to use .endswith()
 - Can no longer uniquely map from single-letter section name -> full section_name
 - Supersize UI would also need to be updated, and likely also ndjson format


Currently leaning towards the first idea, since it's generally easier to leave things in separate fields.