Spandan Das 9cad90f966 Broaden the granularity of config_setting from apex_name to api_domain ... The use case for this is for creating a select statement for stub/impl selection. Since Bazel propagates apex_name from the top-level apex, the source apex and test apex builds a specific library in two different configurations. We need select statements for both these two configurations, but this metadata might not always exist in Android.bp since test apexes are not necessary to be listed in Android.bp files. To overcome this, the select statements will be created per api domain instead. This CL uses a naming convention to infer the api domain of apexes. Test: go test ./bp2build Change-Id: Iad2b45f736bc98a24d2ce1cf2f69aad67973092d		2023-05-04 22:06:47 +00:00
..
cquery	Revert "Revert "mixed builds correctly reference stubs libs""	2023-04-25 00:25:20 +00:00
Android.bp	Add a persistent bazel server between builds	2023-03-01 23:30:19 -05:00
aquery.go	Handle aquery build statements in a goroutine	2023-02-15 11:29:49 -05:00
aquery_test.go	Handle aquery build statements in a goroutine	2023-02-15 11:29:49 -05:00
bazel_proxy.go	Refactor and cleanup of bazel handler	2023-04-25 15:53:58 +00:00
configurability.go	Create config_setting per apex_name	2023-04-28 20:37:35 +00:00
constants.go	refactor Bazel variable export	2022-04-06 14:48:32 +00:00
properties.go	Broaden the granularity of config_setting from apex_name to api_domain	2023-05-04 22:06:47 +00:00
properties_test.go	Correct global excludes not always being excluded	2023-01-26 11:16:39 -05:00
testing.go	add unit test for bp2build allowlist	2022-04-14 13:31:09 +00:00