If the build file contains the apex_test module, but the apex_test
module does not contain the AndroindManifest file, then create the
AndroidManifest file.
In such case, the apexer tool is already generating an AndroidManifest
file. In order to handle the testOnly attribute for apex_test modules, a
--test_only flag is appended to the opt flags.
The apexer tool reads the opt flags and if the --test_only flag is
present then it generate the AndroidManifest file with testOnly
attribute.
Bug: 213310150
Test: m nothing && m test_com.android.sdkext
Test: manually checked the generation of AndroidManifest file in the
unsigned zip file mentioned in the description.
This command allows to read the attribute of the binary xml file -
aapt2 dump xmltree test_com.android.sdkext.apex.unsigned --file
AndroidManifest.xml
Verified the presence of testOnly flag in the output.
Change-Id: Ic47378428b2dba51d73e75d912546c2374f68d57
Bug: 140330870
Test: use bpf{} to install bpf program to vendor and have it
successfully loaded and installed by Android's bpfloader.
Change-Id: If0aac3098e39498f0238516ec839b6ac910cc61e
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
Currently when using sanitizers and building for the device
the -fsanitize= argument is not passed to the linker so that the
linker won't add the runtimes, which have already been added
as explicit dependencies. Pass -fno-sanitize-link-runtime instead
in case the linker has other behaviors when passed -fsanitize=
besides adding the runtimes. Also check for bionic instead of host
so that linux bionic gets the same linker behavior as bionic for
the device.
Test: m USE_HOST_MUSL=true host-native
Test: m checkbuild
Change-Id: I0f2966e2fd4ae8adc5cb21eb116c349bcc0c668f
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
Bug: 215541108
Test: Build libcrypto with Bazel and verify the hash injected, add unit
test
Change-Id: I0375307aab0b1e60a8be298d680e1e0af1ebb454
Change-Id: I9133ce398e2024fe7834a292bf2f5ba3222d630b
This allows us to use relative paths everywhere.
It also produces more accurate emulation of TOPDIR,
which should be an empty string.
Bug: 213508006
Test: go test
Change-Id: Ie4e357687486e84e9f4aad0f6776d8feb2b9fc63
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
* Work around RBE preprocessor bug, which rejects double dash flags.
Bug: 217778010
Test: make tidy-soong_subset
Change-Id: Ic7c0a95ae7afefb49cc9d124fd3c9f38fe2e0f56
