| Age | Commit message (Collapse) | Author |
|---|
|
The state change that we reverse in the finally block
should live before the try block, because if it throws
then the finally block is also not needed.
It shouldn't normally throw, so in practice this probably
made no difference so far, but I'm fixing it because it
sets a bad precedent (I've recently seen a draft CL that
was inspired by this code and replicated this antipattern
elsewhere).
Test: Treehugger
Change-Id: I20c679c6f934b1681ce40518c3b5215a1936fd5a
|
|
A *Test.java file that uses @EnableCompatChanges or @DisableCompatChanges
annotations on just one test case runs this rule on every test case. The
rule was enforcing that all test cases must have such an annotation, but
most *Test.java will apply annotations to only some of their test cases.
Therefore, this CL drops the check for whether a test case carries at
least one such annotation.
Test: atest CtsLibcoreTestCases:libcore.junit.util.compat.CoreCompatChangeRuleTest
Change-Id: I62331a99855d348aa8cc9272628f680eac333b53
|
|
This reverts commit d38b50d216334359b9969606cc611b8be217887f.
The art buildbot was previously failing due to a transitive
dependency on "api-stubs-docs" and "framework-res", via the
unneeded "app-compat-annotations". This fix removes that dependency.
Bug: 140367850
Test: atest CoreCompatChangeRuleTest
Test: art/tools/buildbot-build.sh --host
Change-Id: I34ca27ca5c56ebb23bbb858c287809bc93671427
|
|
Test: https://r.android.com/1155184
Change-Id: Ib801c3df3cd0987309c2b5770c301b24261b3e73
|
|
Reason for revert: Breaks master-art builds with this error:
FAILED: out/soong/.intermediates/development/build/android_stubs_current/android_common/turbine-combined/android_stubs_current.jar
echo "module android_stubs_current missing dependencies: api-stubs-docs, framework-res" && false
module android_stubs_current missing dependencies: api-stubs-docs, framework-res
Test: art/tools/buildbot-build.sh --host
Bug: 140367850
Exempt-From-Owner-Approval: Reverting change breaking ART builds
Change-Id: I48f9505342cf035822b445df0fb8b2b778ef36d4
|
|
A separate implementation will be provided in Framework, to prevent
cumbersome dependencies in libcore specific tests.
Bug: 140367850
Test: atest CoreCompatChangeRuleTest
Test: atest PlatformCompatGating
Change-Id: Ieaf64174e016f946ec86c1521771af0a2a0ac3e5
|
|
Reason for revert: breaks https://ci.chromium.org/p/art/builders/ci/angler-armv7-non-gen-cc/443
Change-Id: If849f0d15f121cfe44ba120c82a84c4bb8a5d324
|
|
CompatChangeRule can now be used host-side, which means that the system
server specific api is ignored.
This change also moves it to a different package, to avoid collision
with android.compat.Compatibility.
Bug: 140367850
Test: atest CompatChangeRuleTest
Test: https://r.android.com/1158973
Change-Id: I661daf7dead3245f3b828355c8a2a0243776164a
|
|
Checking for overlap between enabled and disabled changes is redundant,
as the check occurs already in the Compatibility.ChangeConfig
constructor.
Bug: 140367850
Test: http://aosp/1113771
Change-Id: I87526076a58bd33e733eb2bfff95d33822fffc87
|
|
Adds support for toggling gated changes at test time.
Bug: 140367850
Test: http://aosp/1113771
Change-Id: I7980eb4d69d2f012b62731d93f43fa58d5ee7d54
|
|
Android restricts access to a number of deprecated BouncyCastle
algorithms to APKs that target SDK version <= 27. However, those
algorithms still need testing. Rather than set the target SDK version
to be <= 27 (which could have other side effects) tests use
Providers.setMaximumAllowableApiLevelForBcDeprecation(int) to raise
the level to make them accessible at the current target SDK version
and resets it the default value afterwards.
This change adds a JUnit test rule to implement that behavior and
uses it to replace duplicate setUp() and tearDown() code across a
number of tests. It also insulates the tests from having to access
the internal sun.security.jca.Providers and dalvik.system.VMRuntime
classes.
This is intended to be used by external/conscrypt so that the
conscrypt-tests module can stop depending on core-all-systems-module.
Bug: 141539296
Test: atest CtsLibcoreTestCases
Change-Id: If41b5c221c392e9b6d14d500537115d3380c4999
|
|
Refactors code to replace lots of custom code for testing behavior for
specific target SDK versions, whether it is try...finally... blocks or
methods using lambdas with a JUnit 4 TestRule.
As the tests were JUnit 3 that also required switching them from
extending TestCase to extending TestCaseWithRules which adds support
for JUnit 4 TestRules to TestCase.
This is preparation work for some follow up work on ObjectStreamClass.
Test: atest \
core-tests:org.apache.harmony.tests.java.io.ObjectStreamClassTest \
core-tests:libcore.java.lang.OldRuntimeTest \
core-tests:libcore.java.lang.PackageTest \
core-tests:libcore.java.lang.reflect.annotations.AnnotationsTest \
core-tests:libcore.java.util.CollectionsTest \
core-tests:org.apache.harmony.regex.tests.java.util.regex.PatternTest \
core-tests:libcore.junit.util.SwitchTargetSdkVersionRuleTest
Bug: 109930347
Change-Id: I4ea11288eb344eaeb2e6cc9f3225748e518e1827
|
|
The integration of OpenJDK 9 javac into the Android build system
requires non-libcore code to live in non-libcore packages, as
long as that code isn't considered part of the same module as
libcore at javac time.
This CL moves libcore test related classes out of such
packages; since libcore tests could already only test
public (as opposed to package private APIs), no change
other than the package name and imports is necessary.
Because many libcore tests already live below a top-level
package "libcore" (eg., the tests for java.util are in
libcore.java.util), this CL likewise prepends "libcore."
to the package names of affected classes. For classes
relating to libcore.* packages, this results in a package
name of the form "libcore.libcore.*".
Alternative considered but not pursued:
To compile the test classes without moving the out of a libcore
package, javac would need to consider them to be in the same
module as libcore. This would likely be possible via
javac --patch-module, but this has not been explored in detail
because:
- Most luni tests are already in a toplevel package libcore.*,
so this CL makes the test structure more consistent.
- Use of --patch-module would likely cause problems when running
tests under a runtime that implements the OpenJDK 9 module
system; for example, --patch-module cannot add exported
packages to the module, so any new packages added in tests
(such as the libcore.* packages of most existing luni tests)
would not be visible at test runtime.
- Having tests in different packages from code under tests makes
it more obvious (including to IDEs in which the code might be
edited as a single project) that these tests cannot access
package-private identifiers in the code under test.
Test: Treehugger
Test: "make cts" with EXPERIMENTAL_USE_OPENJDK9=true
passes with additional changes present locally
that have not yet been exported as CLs.
Test: CtsLibcoreTestCases
Bug: 68224249
Bug: 68932217 (tracks potential follow-up work)
Change-Id: Ib6b8e6f3bc87093bc219d2108e601163c6e334cd
|
|
Bug: 33613916
Test: make checkbuild
Change-Id: Id85e23928c577515c436f6e6a21fa2afb00b1f83
|
|
Adds examples and adds a check to provide better feedback if it
is used incorrectly.
Test: Ran CTS tests and vogar tests
Bug: 31542223
Change-Id: Ibd45de91e3ee024294a1ee10e22c67039735a461
|
|
Tests that test those classes that use CloseGuard to detect
reosurce leakages are switched to use TestCaseWithRules and
ResourceLeakageDetector.getRule() to detect any resource
leakages and the leaks fixed.
A number of tests could not be fixed due to bugs in the core
classes so a new DisableResourceLeakageDetection annotation was
added as part of this change. A method annotated with that does
not perform resource leakage detection. The affected tests were
annotated with a description and a reference to an associated
bug.
This uses try-with-resources to aid in closing resources. While
that does provide some benefits it is all too easy to change the
behavior of the test unless care is taken. To avoid that it is
important not to merge it with an existing try block such as
those which follow the following pattern:
try {... fail()} catch(..) {}
Merging them could result in the test catching and ignoring
exceptions thrown during the creation of the resource which is
almost certainly not what the test was intending.
Test: Tested with vogar and CTS
Bug: 31542223
Change-Id: Id32bb40fe04eb9719d7e6cd367abb53118b21832
|
|
This change makes various improvements to the support for
testing resource leakage detection.
Adds CloseGuard.Tracker to allow tests to track the lifecycle of
CloseGuard allocation sites directly.
Adds CloseGuardSupport to use CloseGuard.Tracker to provide:
* A BiConsumer that can be used to help check that objects which
own resources protected by CloseGuard correctly detect resource
leakage.
* A TestRule that allows tests to check that system code does
not leak resources, especially under error conditions.
Adds a new ResourceLeakageDetector that uses reflection to
access CloseGuardSupport. This can safely be used in code that
needs to compile and run on OpenJDK.
Adds TestCaseWithRules to allow the TestRule above to be used
with JUnit 3 style tests without converting the whole test to
JUnit 4 style.
Changed libcore.java.lang.ProcessBuilderTest to use TestCase as
ProcessBuilder does not have any CloseGuard protected resources.
That allows AbstractResourceLeakageDetectorTestCase to be
deleted.
Changed RandomAccessFileTest to use TestCaseWithRules and
ResourceLeakageDetector. Fixed issues that it highlighted,
fixed testRandomAccessFileHasCleanupFinalizer test and removed
it from expectations/knownfailures.txt.
Adds core-test-rules/-hostdex targets to encapsulate TestRule
and related classes that can be shared with other projects.
Removes the following now unused classes:
* CloseGuardMonitor
* AbstractResourceLeakageDetectorTest
* The old ResourceLeakageDetector and associated test.
Bug: 31542223
Test: Ran tests on both Vogar and CTS
Change-Id: I8f802b52fdbeac0a30f339a9ceca5d2eaaafd180
|
