Fabricated Overlays Backend Support.

[Tharow]

TODO:

• [ ] Flesh out FabricatedOverlayBuilder
• [ ] Fully Documentation of FabricatedOverlayBuilder.
• [ ] Update HiddenApi with proper version codes for new apis added
• [ ] Way to delete Fabricated Overlays.

References: Add Fabricated Overlays to OMS

Functional Details:

Any Fabricated Overlay owned by the current shell android.R.string.config_systemShell will be removed during init of the OverlayManagerService. Fabricated Overlays have to be owned by a package allowed to overlay it, via OverlayConfig, this is worked around by setting the owner to the android package.

FabricatedOverlayBuilder

The Internal Builder for FabricatedOverlay requires advanced knowledge to use. the builder greatly simplify the adding of resources to the overlay.

Fuctionality

• Res to Res Overlay: Takes Res of Target and Overlays it with a res value from with-in AM
• Invert Resources Api: copy Resources Api but instead it sets the Resources.
• Create Known Xml Config files.

[Tharow]

@MuntashirAkon I apologize for the slow updates to this, it has been a lot of work, and the public doc's are complete lies. the doc for setOwningPackage a fine example of the problem.

The other more difficult issue is the rewrite due to overlaymanager having annoying defaults for creation when it sends it off to the idmap service. So when we need to the builder allows bypassing of all restrictions assoc'd with the overlaymanager as it directly interacts with idmap2 and some daemon nonsense on top of it. to deal with the fact that we can't leave it running nor is it running by default.

Idmap is what converts Res Numbers to res and it was directly handles how overlays are "loaded" (converted to @​idmap) then loaded by assetmanager but still.

But i should be able to post an update to it soon.

[MuntashirAkon]

Please take your time. We're not in a hurry on this. Public docs in the AOSP are frequently outdated or simply absent.