* changes:
Add synchronized to UidRange getter and dump methods
Deal with permission update on handler thread
Running PermissionMonitor#startMonitoring on handler thread
* This will include all of the java files needed to build cronet java.
Test: m cronet_aml_components_cronet_android_cronet
Change-Id: Idc0f61a5f290eca1a03253b622c416c65eba04c9
* `source_set` were converted to cc_defaults and this would pose a huge problem if those cc_defaults had rtti on since it affected all of the dependencies of the source target.
* The solution here would be to compile the `source_set` independently as a static/shared library with rtti on then link it.
Test: m cronet_aml_components_cronet_android_cronet
Change-Id: I28bbe0947d0dc87c2d602514a2759a3171b68aa2
- The UidRange getter and dump methods which is to access
mVpnInterfaceUidRanges and mVpnLockdownUidRanges need to guard
with synchronized to ensure the value won't be changed during
accessing.
- Also make getVpnLockdownUidRanges() to be a package-private
method. It's accessed from PermissionMonitorTest only.
Bug: 232048835
Test: FrameworksNetTests CtsNetTestCases
Change-Id: I850f155a01c309f9d75f5143dc0a46a1505415bd
To ensure that permission cannot change while CS is doing works,
scoring networks, sending callbacks, etc. So making all
permission update are running on handler thread.
Bug: 232048835
Test: FrameworksNetTests CtsNetTestCases
Change-Id: I5380ec8ff1282a1056d9063848e0fff8b3a570ec
Most permission update functions are running on the handler
thread. So the startMonitoring() should be running on handler
thread as well to ensure the permission won't change while
processing CS's works.
However, startMonitoring() has a dependency with
MultipathPolicyTracker. It needs to call and complete the
permission update before calling MultipathPolicyTracker#start.
Thus, we need to check the startMonitoring done in the end of
systemReadyInternal because we are processing it on the handler
thread.
Bug: 232048835
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: I41fef14d6c163eb5676eab3ccd43416ea1fe1414
* changes:
gn2bp: Add `-Wno-null-pointer-subtraction` to the default flags
gn2bp: Add genrules to their respective architecture sink
gn2bp: Generate per-architecture genrule for `action_foreach`
and get rid of some macros while we're at it.
This is just slightly easier to read.
(side note: this is all resolved at compile time!)
Bug: 259199087
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I7b38afd4b6f9d73b4f34a90040639f0780544ac8
* changes:
gn2bp: create one action per arch
gn2bp: support multiple jni registration modules
gn2bp: get rid of local_include_dir hacks
gn2bp: remove jni_headers from jni_generator genrule
gn2bp: add common header dependencies to defaults
gn2bp: unconditionally remove -DANDROID for all host targets
In current code, the test will call pressHome before show
network notification but it does not verify the home screen
is shown. The test might be failed due to the notification
shade is still opened. Thus adding an assertion to verify
the launcher is shown.
Bug: 255643296
Test: FrameworksNetTest:NetworkNotificationManagerTest
Change-Id: Iee3476a26030b9ba72994dee624e0e6974c9369f
Action modules can have different args depending on target_cpu
(specifically, the buildflags action). Therefore, we create one action
per target os & arch.
Test: //components/cronet/android:cronet
Change-Id: I6025abba8eb9f1974ef0fa6b62f79998305374a3
My next change will start appending ARCH to module names, so this
function needs to support multiple jni registration modules.
Test: //components/cronet/android:cronet
Change-Id: I7788a6bbd8807e527f2e1c6981b5f6219eea9a45
Those should not be needed anymore, as we are using glibc and bionic
headers, not the chromium packaged sysroot.
Test: //components/cronet/android:cronet
Change-Id: I4fe381a2aa1bb35857e70f90b283895dc7f570e2
Chromium builds get these headers directly from sysroot, so they do
not explicitly list the dependency. While this is probably an upstream
bug (or at least a limitation), it is easiest to just add them to
cc_defaults.
This also adds jni_headers which are required by multiple targets.
Test: //components/cronet/android:cronet
Change-Id: Ifb8843aaa60b2454544886b3e60aae42f9a5388e
It turns out, -DANDROID was not consistently applied across the chromium
code base, so it was removed for some targets where it shouldn't have
been.
Adding it to the host defaults solves this problem.
Test: //components/android/cronet:cronet
Change-Id: Ieff81727410c47a0d90d22b56348c6773f653a25
* Deleted the dependency on chromium libc and Android NDK.
* This is a tweak for an upstream problem as libbase has a dependency on libmedia without declaring it.
Change-Id: I77655b8d550a51d256d9b33c07d6eb69971f3811
Test: m cronet_aml_base_base
This change addresses API review feedback and improves documentation.
Specifically, it adds documentation for the newly added getMtu() and
getMacAddress() methods, describes under which conditions the MAC
address is null and adds a short blurb on how (or in what context) this
class is used.
Test: TH
Bug: 236187143
Change-Id: I349897fd55f3085ce88c8b94c84ec636bb5eb2a6
