Three careful passes. One setting made them unnecessary.

The plan had five phases. Build the 243 music clips into a separate bundle, load music from that bundle, move the fight screen over, wire the bundle into an install-time asset pack, then take the music out of the base.

The part worth keeping was phase two. About 30 places in the game call the audio manager to play music. Rather than change them, the function kept its exact signature and changed underneath: load from the bundle first, asynchronously, and fall back to the old loader on any failure, so the music could never simply stop. A request token discarded late loads, so a slow clip couldn't start over a newer one.

Before calling it done, I built the bundle (562 MB, 243 clips), checked both load paths against real tracks, and loaded and released 20 clips to confirm the bundle didn't hold on to memory the old path would have freed. It didn't. Nothing was left behind.

The next day, three phases in, I switched on Split Application Binary in Unity's player settings. It moves everything under Resources, the streaming assets and every scene after the first into install-time asset packs, and the existing loading code keeps working unchanged. The base went from over 740 MB to 25 MB, with 682 MB in the install-time pack. Play accepted it.

The three phases came out the same day. Both edited files were restored byte for byte from their snapshots, the bundle builder was deleted, and so was the 562 MB build artifact. Phase four was cancelled.

For an Android base-size problem, check Split Application Binary first. It's Unity's standard mechanism for builds over 200 MB, and it would have saved three passes. The careful refactor wasn't wrong, it was unnecessary, and keeping it would have left about 150 lines of loader to maintain for nothing.