| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should be the last place the new data processing is needed.
MobileInstall is a bit trickier than normal data processing because it's out of
the way. I'm still using ApplicationManifest to wrap the manifest Artifact in a
lot of it, just because that makes more sense than passing around both
ApplicationManifest for use with old behavior and StampedAndroidManifest for
use with the new. Once we switch to entirely the new behavior, we can remove
ApplicationManifest entirely.
RELNOTES: none
PiperOrigin-RevId: 193392923
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The decoupled pipeline is safely hidden behind a flag.
I'm explicitly holding off on the MobileInstall code until next review, so we
sometimes create an ApplicationManifest object even in the new pipeline to pass
data to that code.
I'm not thrilled with the 'just call into the resource processor with different
settings' approach that I've reproduced in ProcessedAndroidData, but I don't
see a better way of doing things, and I think that breaking out the commonly
used settings makes things cleaner.
RELNOTES: none
PiperOrigin-RevId: 193373347
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- Expose manifest merging logic from ApplicationManifest
- Use it to reimplement manifest merging in new AndroidManifest class
- Track merged resources zip in ResourceContainer - we shouldn't be forced to
use hacks to get it
- Clean up return type of ProcessedAndroidData.generateRClass - a ResourceApk
is the general type used to wrap fully processed data.
RELNOTES: none
PiperOrigin-RevId: 193367162
|
|
|
The AndroidResourceProcessingAction does all of asset parsing and merging and
all of resource parsing, merging, and validation except for R class generation,
all in one action. Add class to wrap the intermediate output of this action. It
can trigger R class generation to create a full ValidatedAndroidResources
object.
RELNOTES: none
PiperOrigin-RevId: 193350591
|
asteinb