These trigger a few failure modes (duplicate genrule srcs, failure in
matching config conditions, depending on unconverted soong_zip host
tool).
Test: CI
Bug: 218405924
Change-Id: I15c119803a057e94ef6a941df3b58103d42eb4e4
This will suppress warning like:
system/chre/chpp/app.c:637:3: warning: Call to function 'memset' is insecure
as it does not provide security checks introduced in the C11 standard.
Replace with analogous functions that support length arguments or provides
boundary checks such as 'memset_s' in case of C11
[clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]
Test: WITH_TIDY=1 CLANG_ANALYZER_CHECKS=1 make tidy-system-chre-chpp_subset
Change-Id: I87a7bba31aa10260fc408317a8cd54bf80c03152
Having soong generate a list of makefiles for mk2rbc
to look through is much faster than having mk2rbc search
itself. Profiling the readLinesFromeFile() function that
reads the list of makefiles shows it takes on the order
of 200 microseconds, much faster than the ~5 seconds
it takes for mk2rbc to search the tree itself.
This CL also allows include statements that are prefixed
with a variable. The concern with this was that there
would be a lot of load statemnts emitted for generic
include statements, causing the generated code to look
ugly, and converting and loading all those files could
cause performance issues. On the performance issues
front, there's already a check that it doesn't result
in over 150 potentially included files. We can lower
that number if necessary, but it's probably good for now.
On the generated code front, while it's true that it's
ugly, it's better to have working but ugly generated
code than refusing to generate anything working at all.
To ensure the soong finder step isn't slowed down due
to having to find a bunch of new makefiles, I profiled
the combination of newSourceFinder and FindSources in main.go:
Baseline incremental:
338.011634ms
340.853335ms
348.541762ms
333.229644ms
349.124824ms
Baseline clean:
1.003836419s
1.006203912s
996.193648ms
1.031005604s
1.03691152s
Modified incremental:
349.029285ms
349.264496ms
351.774948ms
337.63187ms
359.425306ms
Modified clean:
1.028238704s
1.053103506s
1.032757506s
1.016631201s
1.04288108s
So we can see the times are barely affected by this change.
Fixes: 213508006
Test: go test
Change-Id: Iab18bfb127ba3b7e63f2c01f69064805a8398764
A number of tests in the cts/tests/signature/api-check check for the
accessibility of classes from the android.test.base,
android.test.runner and android.test.mock libraries. Some tests expect
to find the classes other do not. Unfortunately, the tests use
libraries, specifically compatibility-device-util-axt, that depend on
the android.test... libraries which causes Soong to implicitly add
<uses-library> entries to the manifest so that they will be accessible
at runtime. That causes the tests that do not expect to find the
classes to fail.
Bug: 209607558
Test: m nothing
Change-Id: I54c194ab23d5a70df790ece3fe98f2b3d6a1c1f6
Currently error messages appear like:
&fs.PathError{Op:"open", Path:"..." Err:0x18}
which make them difficult to parse.
Test: CI
Change-Id: I18da18abc43230d0ea37d166179d07e585077f51
CI builds are doing m installclean between them;
which is not causing the system_dlkm to clean
it's build.prop and it is stuck to the first CI
build when feature landed causing ota signing
test to fail.
Local reproduction using:
m installclean && m -j96 && m dist
validate_target_files out/dist/*target_files-*.zip
Bug: 217507332
Test: Local verification, TH & Forrest
Signed-off-by: Ramji Jiyani <ramjiyani@google.com>
Change-Id: I97f2011a61252d3cb798af0fab99221b754328ca
Bug: 151177513
Bug: 210912771
Test: m all dist
Test: flash; About Phone -> Legal Information -> Third-party licenses
Change-Id: I9b9e3a67230dae6236ee5c5d6dc6edbc23c5a91d
This flag has never done anything for ld.lld, since it has this behavior
by default (and actually can't turn it off either). It's now being
removed as a valid flag from ld.lld, so it's time for Android to drop
the unnecessary flags. See https://reviews.llvm.org/D118942.
Test: builds
Change-Id: I22c344b7a55e275c1fbd5fef25f85e97a39de5c4
In case there are two vendor apexes(one with "use_vndk_as_stable:true",
and the other with "use_vndk_as_stable:false") a VNDK lib used by both
will have "APEX" variant and the former APEX will use "apex" variation.
For example,
apex1(use_vndk_as_stable) -> foo -> libvndk
apex2 -> bar -> libvndk
Since foo, bar and libvndk are mutated into two APEX variations("",
"apex10000"), foo will use the apex variation of libvndk.
To fix this, VNDK libs can use "unique" APEX variations. Then, in the
above example, foo will have "myapex1" variation and libvndk will have
two APEX variations("" and "apex2"). So foo will link to ""(non-APEX)
variation as fallback.
Bug: 216847402
Test: m nothing (soong tests)
Change-Id: I116932860ef79e22dc338a58b251e3ca693ab4f3
Even though a vendor APEX sets use_vndk_as_stable:true it was possible
to include a VNDK lib by directly depending on it with
native_shared_libs.
But it's contradictory to have a VNDK lib while declaring not to include
VNDK libs. It was missing since pruning dependencies on VNDK libs was
done only for transitive deps.
Added a check to reject this.
Bug: 216847402
Test: m nothing(running soong tests)
Change-Id: I8d79a434b1bfe8e563cf8968fa76830b0e582f66
Soong modules that are specific for the host platform (e.g.
java_library_host, cc_binary_host, java_genrule_host, etc.) should
not be built on the target platform (Android), so we add a
target_compatible_with attribute to skip this type of module on an
Android target build.
Bug: 215229742
Test: go test ./bp2build
Change-Id: Ifb76ef4e0dc4cb3adb6a64b5c375ce36f7973e48
To unblock mixed builds, uses a common mechanism to determine cc module
type across bp2build and mixed builds.
Test: mixed_droid.sh
Change-Id: I1f69ad0858cda549b7c95dbadd596e46df0f23b2
Currently, mk2rbc is structured around having a global
"receiver" object that accepts all starlarkNodes. As soon
as they are parsed they are added to the receiver.
Returning the parsed nodes to the calling function is more
flexible, as it allows the calling function to restructure
them as necessary. This is the first step to supporting
complicated statements involving $(eval), such as
`$(foreach v,$(MY_LIST),$(eval MY_LIST_2 += $(v)))`
Test: go test
Change-Id: Ia194123cf090d2b9559a25b975ccbc5749357cc0
Also, because java_plugin is only intended to be built for the host
platform to make additions to the javac compiler, a compatibility
requirement is added to java_plugin that ensure that it is not built
for android targets.
Bug: 215229742
Test: go test ./bp2build
Change-Id: I09902215a9f1e8b14d4de5a51328d08a7a0a4450
