4th step in trying to make the WindowList private to DisplayContent
Have the rest of the system call DisplayContent when they need to
adjust the position of the wallpaper windows in the window list
instead of calling WallpaperController directly. That way the display
content can control the window list that the wallpaper controller sees.
Test: Existing tests pass and manual testing.
Change-Id: Iaa7f421d7cd24d36e5a83e091f77b4a08d0ae123
3rd step in trying to make the WindowList private to DisplayContent.
The method was another an indirect way to the the window list
from the display content.
Test: Manual testing and existing tests pass.
Change-Id: Ifb0548a91b5bc64461e14f63256b61b8fa5e2e0c
This makes the policy for mixed HTTP/HTTPS content match Chrome.
This allows us to display login pages where unimportant
subresources are HTTP.
Bug: 32171569
Change-Id: Ic8bc1440f1f26898ddbc0984fd1ddd2155c9588b
Properly account for VPN apps that make heavy use of the tun
interface. Prior to this change a VPN app could be incorrectly charged
for more data than it actually used if it sent more traffic through
the tun interface than the underlying interface.
This change excludes VPN app traffic on the tun interface from the
adjustment pool and doesn't redistribute traffic to the VPN app.
Instead all of the redistributed traffic is deducted from the VPN app
which effectively represents any overhead incurred by the VPN app.
BUG: 30557871
Change-Id: I62a75a0c0c0111e052b7903baa9f5d6d94ef57fd
- In WindowContainer set parent of the child after it is actually
added. This way if the child class depends on this in overridden
methods it will be in correct state.
- Reconfigure display only if it is attached. Otherwise there is no
corresponding DisplayContent record with configuration.
Change-Id: I20c51522d82f9d0ca98f098070585e6472a23e98
Test: Updated WindowContainerTests.
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
This patch removes the static singleton looper used by
ConnectivityManager and instead uses the common ConnectivityThread.
This allows to removes the static atomic counter used to track
the number of registered NetworkCallback in ConnectivityManager, because
the looper is not turned off anymore when no callbacks are registered.
Also an overloaded version of sendRequestForNetwork is added taking as a
new parameter a Handler. This will allow to overload various callback
and request related API calls with user provided Handlers.
Test: ConnectivityServiceTest passes
Bug: 26749700
Bug: 28537383
Bug: 32130437
Change-Id: I431afcee7c7155bd7bac23a2e1e97fd5d6520c74
Move over the Runnable Class into android.telecom and turn on the
framework's usage in Telecom.
CP from: https://android-review.googlesource.com/#/c/287291/
Test: All Telecom unit tests pass. Manual Log testing has also been
confirmed to be working as it did before.
Bug: 26571395
Change-Id: If7e2036c746c5a953f3a77e2d625a423ce5bf8f3
(cherry picked from commit 9fbbd4052dee1dfa74b87502cec91cc51170d69d)
Before it was showing up in "Other mmap" instead. Now it is correctly
showing up in ".dex mmap".
Bug: 30937355
Test: N6P booting, dumpsys meminfo -d
Change-Id: I335dbb77414b395b14259aa7c68068f845a5eca1
- Pinned stacks were being treated as full screen tasks, and bounded
(incorrectly) to the display rect leading to negative insets. In
turn, this caused the view root to have negative insets, which caused
layout to be extended (width - (-inset)) when measured.
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: #testPinnedStackOutOfBoundsInsetsNonNegative
Change-Id: I3339d982667c981a3c8ca56fb3542188de1d6714
