Vendor JNI libraries already have stable APIs enforced by the VNDK,
they shouldn't use SDK variants.
Bug: 156225490
Test: TestJNISDK
Change-Id: I21ba67e8e9fb05016caf5888129adc1a939545c2
Visibility rules can be 'inherited' in one of two ways. Either from
defaults or from a module that called ctx.CreateModule(...).
Previously, in both cases the inheriting module could only append
additional visibility rules to the end of the inherited rules. That
made it impossible to restrict the visibility by removing or ignore
inherited rules.
The //visibility:override rectifies that by allowing the inheriting
module to ignore all the rules that they would have inherited. It can
only go at the beginning of a list of rules specified in a module but
after defaults are applied it can end up in the middle of a list of
rules. In that case it behaves as if all the rules up to and including
the //visibility:override rule were discarded.
It can be used with //visibility:private to override
//visibility:public and vice versa.
Bug: 155787200
Test: m nothing
Merged-In: I8a9c9c5a1bdceaee387c08864ae2b34629e0d46f
Change-Id: I8a9c9c5a1bdceaee387c08864ae2b34629e0d46f
(cherry picked from commit 51084ff6cf)
Visibility rules can be 'inherited' in one of two ways. Either from
defaults or from a module that called ctx.CreateModule(...).
Previously, in both cases the inheriting module could only append
additional visibility rules to the end of the inherited rules. That
made it impossible to restrict the visibility by removing or ignore
inherited rules.
The //visibility:override rectifies that by allowing the inheriting
module to ignore all the rules that they would have inherited. It can
only go at the beginning of a list of rules specified in a module but
after defaults are applied it can end up in the middle of a list of
rules. In that case it behaves as if all the rules up to and including
the //visibility:override rule were discarded.
It can be used with //visibility:private to override
//visibility:public and vice versa.
Bug: 155787200
Test: m nothing
Change-Id: I8a9c9c5a1bdceaee387c08864ae2b34629e0d46f
Checks the syntax of the Android.bp file generated for the sdk
snapshot. While this will not detect all possible problems with the
generated Android.bp file it will detect some and it is far better to
detect those issues during generation than when it is unpacked and
used.
Bug: 155628860
Test: m nothing
Change-Id: Ieec86a7a49fa2e3bd8b9f83aca540114232a3476
Adds a filter mechanism that can exclude property values from being
included in the common value extraction. That is needed to prevent the
snapshot mechanism from generating invalid output for properties that
are ignored on host (and have their values cleared) and which are not
tagged with `android:"arch_variant"`.
Changes:
* Updates the documentation of SdkMemberType to explain what effect
the 'ignored-on-host' tag has.
* Adds some tests for this new mechanism.
Bug: 155628860
Test: m nothing
Merged-In: Ibafdb6e921ba5abe505bd8a91ca5a1d9c9b5d0cb
Change-Id: Ibafdb6e921ba5abe505bd8a91ca5a1d9c9b5d0cb
(cherry picked from commit c459f89fb4)
Previously, the snapshot code did not know whether a specific property
could be arch specific or not and assumed that they all were which
meant that it could generate snapshots containing arch specific values
for properties that are not arch specific and so would fail when
unpacked.
This change requires arch specific fields in SdkMemberProperties to be
tagged as such using `android:"arch_variant"` (just as in module input
property structures). Any property without that must have properties
that are common across all variants.
Bug: 155628860
Test: m nothing
Merged-In: I3df60f0b53ba02ec2c55a80c7da058eac5909d26
Change-Id: I3df60f0b53ba02ec2c55a80c7da058eac5909d26
(cherry picked from commit 864e1b45db)
Adds a filter mechanism that can exclude property values from being
included in the common value extraction. That is needed to prevent the
snapshot mechanism from generating invalid output for properties that
are ignored on host (and have their values cleared) and which are not
tagged with `android:"arch_variant"`.
Changes:
* Updates the documentation of SdkMemberType to explain what effect
the 'ignored-on-host' tag has.
* Adds some tests for this new mechanism.
Bug: 155628860
Test: m nothing
Change-Id: Ibafdb6e921ba5abe505bd8a91ca5a1d9c9b5d0cb
Previously, the snapshot code did not know whether a specific property
could be arch specific or not and assumed that they all were which
meant that it could generate snapshots containing arch specific values
for properties that are not arch specific and so would fail when
unpacked.
This change requires arch specific fields in SdkMemberProperties to be
tagged as such using `android:"arch_variant"` (just as in module input
property structures). Any property without that must have properties
that are common across all variants.
Bug: 155628860
Test: m nothing
Change-Id: I3df60f0b53ba02ec2c55a80c7da058eac5909d26
* changes:
Revert "Detect invalid arch specific properties in snapshot"
Revert "Adds support for 'ignored-on-host'"
Revert "Fix snapshot of a host/device cc_library with stubs"
Revert submission 1302576
Bug: 156054601
Reason for revert: Presumed root cause of build break.
Reverted Changes:
Ifc8116e11:Detect invalid arch specific properties in snapsho...
I7ebd33307:Adds support for 'ignored-on-host'
I167b47a13:Fix snapshot of a host/device cc_library with stub...
Change-Id: Id7eba0bdde5c579e10e9b42d94a7cfab5f34995f
Revert submission 1302576
Bug: 156054601
Reason for revert: Presumed root cause of build break.
Reverted Changes:
Ifc8116e11:Detect invalid arch specific properties in snapsho...
I7ebd33307:Adds support for 'ignored-on-host'
I167b47a13:Fix snapshot of a host/device cc_library with stub...
Change-Id: I2a7ac0ef0232177eefc26542c11dc675d6f4cab2
Adds a filter mechanism that can exclude property values from being
included in the common value extraction. That is needed to prevent the
snapshot mechanism from generating invalid output for properties that
are ignored on host (and have their values cleared) and which are not
tagged with `android:"arch_variant"`.
Changes:
* Updates the documentation of SdkMemberType to explain what effect
the 'ignored-on-host' tag has.
* Adds some tests for this new mechanism.
Bug: 155628860
Test: m nothing
Change-Id: I7ebd333079619dba546bc8c4911d567e0287b676
Previously, the snapshot code did not know whether a specific property
could be arch specific or not and assumed that they all were which
meant that it could generate snapshots containing arch specific values
for properties that are not arch specific and so would fail when
unpacked.
This change requires arch specific fields in SdkMemberProperties to be
tagged as such using `android:"arch_variant"` (just as in module input
property structures). Any property without that must have properties
that are common across all variants.
Bug: 155628860
Test: m nothing
Change-Id: Ifc8116e11d987cfe7aec2eeaa964f3bbf36b5dc2
Previously, the only way for a module type to create modules (other
than defining its own mutator) was to register a LoadHook. However,
that is called before defaults are applied so any properties used in
that hook cannot take advantage of defaults, e.g. java_sdk_library
cannot use defaults to set its sdk_version property and have that
affect its child modules.
This change adds a new SetDefaultableHook() to DefaultableModule to
register a hook that is called after any defaults have been applied.
Also adds some tests to ensure that errors in the visibility property
introduced in a DefaultableHook are reported in the gather phase of
visibility processing.
A follow up change will switch java_sdk_library to use that instead
of the AddLoadHook() mechanism.
Bug: 155295806
Test: m checkapi
Merged-In: I13df3115f9e225f7324b6725eaeb16a78cc2538a
Change-Id: I13df3115f9e225f7324b6725eaeb16a78cc2538a
(cherry picked from commit afa9fa104d)
A follow up change will add a mechanism for a module to register a hook
that is called after any defaults have been applied. That is intended
for use by modules like java_sdk_library that create child modules that
are dependent upon properties that could be supplied by defaults.
Creating those child modules after prebuilts mutators are run will
cause problems if those child modules clash with prebuilts modules.
Moving the prebuilts mutators after the defaults mutators will fix
that.
Tests are currently being run with the mutators in different orders so
this change also cleans that up so they are consistent with the actual
code that is being run.
Bug: 155295806
Test: m checkbuild
Merged-In: I825c6df09058fb3a45db196661959eb332aca2f3
Change-Id: I825c6df09058fb3a45db196661959eb332aca2f3
(cherry picked from commit c988c8e202)
The method is a thin wrapper around GetWalkPath and GetTagPath to make
it easy to construct a string representation of the current path.
It was originally inlined in the apex package. This change makes it a
function and moves it to the android package so make it more useful.
Bug: N/A
Test: m
Change-Id: I7e2bc2074baed759d67d9097151c9ac10e34ed31
Previously, the only way for a module type to create modules (other
than defining its own mutator) was to register a LoadHook. However,
that is called before defaults are applied so any properties used in
that hook cannot take advantage of defaults, e.g. java_sdk_library
cannot use defaults to set its sdk_version property and have that
affect its child modules.
This change adds a new SetDefaultableHook() to DefaultableModule to
register a hook that is called after any defaults have been applied.
Also adds some tests to ensure that errors in the visibility property
introduced in a DefaultableHook are reported in the gather phase of
visibility processing.
A follow up change will switch java_sdk_library to use that instead
of the AddLoadHook() mechanism.
Bug: 155295806
Test: m checkapi
Change-Id: I13df3115f9e225f7324b6725eaeb16a78cc2538a
A follow up change will add a mechanism for a module to register a hook
that is called after any defaults have been applied. That is intended
for use by modules like java_sdk_library that create child modules that
are dependent upon properties that could be supplied by defaults.
Creating those child modules after prebuilts mutators are run will
cause problems if those child modules clash with prebuilts modules.
Moving the prebuilts mutators after the defaults mutators will fix
that.
Tests are currently being run with the mutators in different orders so
this change also cleans that up so they are consistent with the actual
code that is being run.
Bug: 155295806
Test: m checkbuild
Change-Id: I825c6df09058fb3a45db196661959eb332aca2f3
This was not previously possible due to LoadHooks being run after the
module was registered.
Bug: 155462403
Test: m nothing
Merged-In: Ia8383b9d1272bb12c8a83948753a0e4b0d98a650
Change-Id: Ia8383b9d1272bb12c8a83948753a0e4b0d98a650
(cherry picked from commit cdfcec98bb)
