Settings needs to access a variant of getInstalledApplications() which
takes a |userId| argument. Since this is not currently exposed by
PackageManager, Settings calls into PackageManagerService directly. This
is ugly and breaks the regular abstraction layer hierarchy.
The CL fixes the problem by exposing the required variant of
getInstalledApplications() as a hidden API, analogously to what was done
before with getInstalledPackages().
Bug: 32692748
Test: Will be CTS-verifier-tested together with Settings
Change-Id: Id9c4e8e18524d312159821f1a4d5527263c7e950
- Remove ModuleClassLoader as it can be replaced with a URLClassLoader
for now.
- Move CustomCalendar and CustomDate to a separate package that can be
used both by the Bridge tests and the actual test app.
- Move empty.xml out of the test app so it compiles.
- Update test app to use the latest build tools and SDK (some attributes
being used by the app weren't supported in API 21).
- Update gitignore to remove the new out directory.
Test: Update to existing tests
Change-Id: Ieb7324d5ae559f9c581771c57f2127cd83909015
Follow-up to commit 896cc3a794, the class file also needed to be
updated. The golden file of testActivity is also updated to be
the one built with jdk1.8.0_60 which is the one running on buildbot.
Test: Run testActivity
Change-Id: I7f3cfc1123160005c3cb5fa4213db6ae3a48457d
(cherry picked from commit aab13aee9a11c340952c24f2410940df59996816)
The date of the calendar is set by converting the epoch time based on
the local time zone. We choose at date at 12:00 GMT so that it will
be on the same day no matter which time zone is considered.
Test: part of testActivity
Change-Id: Ib36a5b45f69323265dd5ceaa17eeac553fc2d071
(cherry picked from commit 896cc3a794bb6e173c1e53e97f70007c3e24de38)
This is following commits f22859757b, 94931bd87e, 4387190d8e
and caa08ff5e9.
Test: Run TestDelegates
Change-Id: If90028492c036fc5f69913e4dcad5a1a5fca4b55
Put android:animateFirstView false in the test application theme
so that the date picker view displays fully.
Update the golden image to reflect the changes.
Change-Id: If57fac5c182dd69b4b4d4fcc30d6f17a8f67ad68
(cherry picked from commit 96970138fc1c8d928a6d3ec362865e6c626f56e4)
Move all the includes for androidfw under
a common base path for that library instead
of frameworks/base/includes.
Also fixes -Werror issues that resulted in
no longer being -isystem.
Test: builds
Change-Id: Ic4312eb61b197af114dded5691d5ae1ec82923f7
Merged-In: Ic4312eb61b197af114dded5691d5ae1ec82923f7
(cherry picked from commit f6113af2d6f6eebee68d3ac510fe96d38a7a39e9)
Move all the includes for androidfw under
a common base path for that library instead
of frameworks/base/includes.
Also fixes -Werror issues that resulted in
no longer being -isystem.
Test: builds
Change-Id: Ic4312eb61b197af114dded5691d5ae1ec82923f7
Added new "ping" method used to detect if the shared
library has already been loaded.
Fixed a few bugs in the implementation (and now it works
from the Java side).
See http://ag/1590668 for the implementation on devtools.
Test: Done on the tools side
Change-Id: Ifa41073dc3b6ac69cdb9f77e655bf261c3b4c3d1
This includes copying and slightly modifying
libnativehelper's ScopedUtfChars' implementation.
Test: Done in studio-master-dev
Change-Id: I2aacc67b444668478aaa5bb0db991a201c571d1f
Window tokens can now only be on one display, so we now require clients
that want to add/remove window tokens to specify the display they would
like the token to be created on. This simplifies the token handling code
in WM and will be useful moving forward for clients that want to add
windows to external displays.
Test: Existing tests pass
Change-Id: I6b2d8d58a913b3624f1a9a7bebbb99315613f103
Cleanup:
- Make sure all the state is nicely dumped.
- Remove some unused stuff.
- Fix a flicker when occluded -> unlocked
Bug: 32057734
Change-Id: Id87e26adccef740d608b325c2dc1f6db14dd4ec3
- Creating a PinnedStackController to keep track of the state of the PIP
to prevent changes in the system (ie. IME showing) and user interaction
from clobbering each other.
- Refactoring calls in AM into WM/controller
Test: android.server.cts.ActivityManagerPinnedStackTests
Change-Id: Ie59dfd45d5c54764ba69a589b3b8148845e92cc3
Signed-off-by: Winson Chung <winsonc@google.com>
PackageParser on the device uses the targetSdkVersion of the
app while it parses <application>. That means that if the
<uses-sdk> tag comes after <application>, the targetSdkVersion
is assumed to be 0.
Test: make libaapt2_tests
Change-Id: I60f2179a7ff44e7419217afb53f3d24f8c030f6e
Use Google3 naming style to match new
projects' and open source google projects' style.
Preferred to do this in a massive CL so as to avoid
style inconsistencies that plague legacy code bases.
This is a relatively NEW code base, may as well keep
it up to date.
Test: name/style refactor - existing tests pass
Change-Id: Ie80ecb78d46ec53efdfca2336bb57d96cbb7fb87
- Ensure we use the right display size when calculating PIP bounds.
- Also update interface to take the display id.
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: #testPinnedStackDefaultBounds
Test: #testPinnedStackMovementBounds
Change-Id: I01fd8ba6dee212c29a9a092673ee8f7843e41af6
Now display-specific settings, such as dimensions and orientation,
are stored in display override config. For default display it is
mirroring the global config. Each time when global config is updated,
override of the default display should be updated too and vice versa.
Test: Existing and manual tests still pass.
Change-Id: Ic6c2190092d328820f314a05bed43c875db18170
Keep styledstrings at the beginning of the StringPool
to reduce the padding in the StyledString array.
Bug:32336940
Test: manual
Change-Id: Iec820c21a54daac40ecc3b2f87517a0f1efc9d3d
This is a cleaned up version of a utility that I've had sitting around
for a while.
The bit tool can run an android platform build, then sync or install
the outputs of that, and then run instrumentation tests. It's better
than what we usually do:
make && adb shell stop && adb sync system && adb shell start
Here's the help text:
usage: bit OPTIONS PATTERN
Build, sync and test android code.
The -b -i and -t options allow you to specify which phases
you want to run. If none of those options are given, then
all phases are run. If any of these options are provided
then only the listed phases are run.
OPTIONS
-b Run a build
-i Install the targets
-t Run the tests
PATTERN
One or more targets to build, install and test. The target
names are the names that appear in the LOCAL_MODULE or
LOCAL_PACKAGE_NAME variables in Android.mk or Android.bp files.
Building and installing
-----------------------
The modules specified will be built and then installed. If the
files are on the system partition, they will be synced and the
attached device rebooted. If they are APKs that aren't on the
system partition they are installed with adb install.
For example:
bit framework
Builds framework.jar, syncs the system partition and reboots.
bit SystemUI
Builds SystemUI.apk, syncs the system partition and reboots.
bit CtsProtoTestCases
Builds this CTS apk, adb installs it, but does not run any
tests.
Running Unit Tests
------------------
To run a unit test, list the test class names and optionally the
test method after the module.
For example:
bit CtsProtoTestCases:*
Builds this CTS apk, adb installs it, and runs all the tests
contained in that apk.
bit framework CtsProtoTestCases:*
Builds the framework and the apk, syncs and reboots, then
adb installs CtsProtoTestCases.apk, and runs all tests
contained in that apk.
bit CtsProtoTestCases:.ProtoOutputStreamBoolTest
bit CtsProtoTestCases:android.util.proto.cts.ProtoOutputStreamBoolTest
Builds and installs CtsProtoTestCases.apk, and runs all the
tests in the ProtoOutputStreamBoolTest class.
bit CtsProtoTestCases:.ProtoOutputStreamBoolTest\#testWrite
Builds and installs CtsProtoTestCases.apk, and runs the testWrite
test method on that class.
bit CtsProtoTestCases:.ProtoOutputStreamBoolTest\#testWrite,.ProtoOutputStreamBoolTest\#testRepeated
Builds and installs CtsProtoTestCases.apk, and runs the testWrite
and testRepeated test methods on that class.
Launching an Activity
---------------------
To launch an activity, specify the activity class name after
the module name.
For example:
bit StatusBarTest:NotificationBuilderTest
bit StatusBarTest:.NotificationBuilderTest
bit StatusBarTest:com.android.statusbartest.NotificationBuilderTest
Builds and installs StatusBarTest.apk, launches the
com.android.statusbartest/.NotificationBuilderTest activity.
Change-Id: I9cff7a23852fa1a67369e7807f7ae9f6e45d6131
Test: none
