Currently, this is with a 1.4 -> aidl shim, but this will be removed
when the 1.4 HAL interface is removed.
Bug: 141828236
Test: the following:
- device w/ aidl vibrator (cuttlefish) - see logs
- device w/o aidl vibrator, HIDL vibrator still used
Change-Id: Ib4d9841bae1e0bff3c4196959a9a20e03a4297eb
Broke up the halCall() API into two components, one that implements the
initial service retrieval and one that implements the retry on
connection loss. This allows the service retrival API to double as test
for supported version with little overhead.
Test: Manually via CLI
Change-Id: I12cf8838e933187d473157c9576d1b13b03913d4
Signed-off-by: Harpreet \"Eli\" Sangha <eliptus@google.com>
(cherry picked from commit e0b7951d632a5334f17b7e16cdf4bc4cfe9b2196)
Merged-In: I12cf8838e933187d473157c9576d1b13b03913d4
Both of services.net and services.core statically link
netd_aidl_interface. But they use different version.
Since services.core already include service.net, removing
netd_aidl_interface from service.core.
Bug: 143560726
Bug: 139280289
Test: -build, flash, boot
-Off/On tethering
Change-Id: Ifa83880ee7ee88ed67f8b638228ef1b0887e201e
These apis are required for adding UI in the Developer options for
modifying compatibility change overrides.
Bug: 138280620
Test: atest CompatConfigTest
Change-Id: If55aa68f9bdd6bed0765324e972de3683bacb553
This ensures that any calls made (intentionally or not) in the system
server using the Compatibility (in-app process) gating APIs will always
return true, and log the gated feature.
Bug: 143591326
Test: m
Merged-In: I96792cf852f4167fc39d5055704f8617efaae25e
Change-Id: I96792cf852f4167fc39d5055704f8617efaae25e
android.test.mock is built with its own sources plus a small number of
framework sources that provides private APIs that the library's APIs
have references to. Previously, it was built with the entire framework
sources which is too many and should have slowed the build performance.
Bug: 141149570
Test: m
Change-Id: I165ffdfc053a71b323ef7058651d5908df06870f
Added getSmscAddress() and setSmscAddress() to access SMSC address in
(U)SIM through the SmsManager.
getSmscAddress() requires that the calling app is the default SMS app,
or has READ_PRIVILEGED_PHONE_STATE or the carrier privileges.
setSmscAddress() requires that the calling app is the default SMS app,
or has MODIFY_PHONE_STATE or the carrier privileges.
Test: Manual
Change-Id: Icb21aff450f71b30ef6a1181834014bf7b85b8e1
Signed-off-by: Taesu Lee <taesu82.lee@samsung.com>
1) Adds new system APIs that provide more access to IMS state.
2) Remove dependence on IPackageManager, which is not accessible
in mainline.
Bug: 141457496
Bug: 122098288
Test: atest FrameworksTelephonyTests
Merged-In: I17cbad4642ad3099668a354bb2588f2b55602311
Change-Id: I17cbad4642ad3099668a354bb2588f2b55602311
This CL is to fix a bug that found in
TransitionSelectionTests#testCloseTask_BothWallpaper_SlowStop may flaky
because when TopActivity launched & call finish(), the activity will destroy
too soon before BottomActivity resume & idle.
When TopActivity launched, suppose BottomActivity's nowVisible state should
be false because both activities are fullscreen activity & TopActivity should
cover BottomActivity.
After TopActivity called finish(), normally the activity should wait for
BottomActivity visible and then destroy, and this test is to verify if
TRANSIT_WALLPAPER_INTRA_CLOSE state will coming when opening & closing animation
target with wallpaper theme are animating case.
But the flakiness may happen if device is in low-performance stage, when
TopActivity launched, system calls setClientHidden for BottomActivity's all
windows to update its viewVisibility but can't update in time, and then
the next relayoutWindow comes, mis-detected BottomActivity's Floating child
window as drawn state, so that can't update BottomActivity's nowVisible
state as invisible with onWindowsGone().
So when TopActivity called finish(), TopActivity will soon going to destroy
state since BottomActivity is still in nowVisible state.
The fix is to add isNextNotYetVisible, if the next activity the nowVisible or visible
is not yet true, which means we need to add the current finishing
activity into stopping list and destory until the next activity idle.
Bug: 140088359
Test: atest TransitionSelectionTests
Change-Id: If1907d71135158bafea69881205f351ab666025e
Merged-In: If1907d71135158bafea69881205f351ab666025e
Problem & Root cause:
the mInterfaceBroadcastAddr.sll_protocol is not assigned when the
interface initializes, sll_protocol is 0x0000 by default.
This causes packets to be filtered incorrectly in packet capture,
typically with tcpdump. The previous API is used by DhcpClient, causing
DHCP tx messages to not be recognized properly.
Background: inside the kernel packets carry both an ethertype metadata
(skb->protocol) and may also carry a real ethertype in the mac header.
Previously skb->protocol would be inherited from the socket either from
the protocol from socket() creation or from bind(). This was zero,
so skb->protocol would end up 0, even though the DHCP packets we actually
wrote would have the right on-the-wire ethertype populated in the bytes
passed to send().
As such DHCP packets would look correctly on the wire, but were lacking
the skb->protocol metadata to correctly tag them as IPv4.
This results in 'tc' and packet hooks potentially not triggering
correctly, and can thus result in tcpdump 'ipv4' filters discarding
these packets leading to confusing/erroneous tcpdump output.
In newer kernels (somewhere around 5.3), if socket protocol is 0, we
actually parse out the right ethertype from the mac header during send().
However, for old kernels we can't rely on this kernel magic, and the
right fix is simply to make sure that socket bound protocol is correctly
set to ipv4 [htons(ETH_P_IP)] in the bind() system call.
Solution:
Add a new constructor in SocketUtils to set the protocol parameter.
Bug: 133196453
Test: manual test
Change-Id: I07887b82e0e32aadb0cbb9f930f2b2fa3e277ca9
The metalava fix 09094fc5e566a380b7aa1a4c3948ac66cebc0aba allows us to
not include source files having class definitions that are referenced by
private constructors of the API classes.
Removing the now uncessary source files from the input list so that
metalava can run faster.
Bug: 141149570
Test: m
Change-Id: Ib203221600baa0e57393b0d448125676d01bcb8e
The system shouldn't be granting read URI permissions as itself. This
means that heap dumps aren't successfully shared. Moving the heap dump
sharing mechanism to SHELL, which already has the permission to dump
heaps so that dumps can be shared properly.
The ActivityManagerService changes are submitted separately.
Bug: 126885951
Bug: 135150619
Test: collect a heap dump and confirm it's successfully shared with an app
Test: do manual test on a secondary user & confirm it's not available to
other user
Change-Id: I6fad69280b5124c8ec2d3b4bef0f7dddb6a9422c
Original symptom: Cuttlefish devices would crash when the "recent apps"
tray was swiped up from the bottom.
Root cause: Raising the "recent apps" tray triggers a vibration. Close
to the bottom of the call stack responsible for this action in
VibratorService is the native function vibratorPerformEffect(). The
Java Language signature for this function has a long as the type of the
second parameter, as does the JNI signature that is registered with the
environment. The native function, however, uses an int type for this
parameter. As a result, when the arguments are passed via the stack on
x86 devices the high bits of the second long argument are read as the
contents of the third argument, which is a jobject reference. When the
code attempts to convert this NULL local reference into a global
reference the JNI code aborts the runtime for the process. Because the
VibratorService is part of the SystemServer, when it crashes the Zygote
is notified and restarts the entire shell.
Why this wasn't an issue on ARM devices: ARMs calling conventions pass
many of a function's arguments via registers instead of via the stack.
This means that the long argument is passed in a register, preventing it
from stomping on any other arguments. When the native function uses the
argument it simply reads the lower bits from the register and ignores
the higher bits.
Why this wasn't previously an issue on X86 hosts: ag/9158254 introduced
a new parameter to the vibratorPerformEffect() function. This new
parameter is located after the mis-typed parameter and will be aliased
to the high bits of the mis-typed long argument.
Fix: Correct the type signature of the native vibratorPerformEffect()
function.
Bug: 143082450
Test: Build -> start cuttlefish -> raise recent apps tray -> no crash
[adelva: port to AOSP to close potential ASAN issues]
Change-Id: If50f68df9579f84bddc9d70a0a30cd73f4485e96
Merged-In: If50f68df9579f84bddc9d70a0a30cd73f4485e96
Earlier we disabled the reboot free feature and always have
getSupportedModemCount return the same value with getActiveModemCount.
Now that we've enbaled reboot free switch, we will return correct value
based on system property.
Bug: 142514392
Test: manual - change PROPERTY_REBOOT_REQUIRED_ON_MODEM_CHANGE and test
what getSupportedModemCount returns.
Change-Id: I34e172c747dd52aa498037e64b758393793fddba
Merged-In: I34e172c747dd52aa498037e64b758393793fddba
To have better names reflecting what getPhoneCount / getMaxPhoneCount
actually represent, we replace them with getActiveModemCount and
getSupportedModemCount. As getPhoneCount is public API, we mark
it as @Deprecated.
Bug: 141388730
Test: build
Change-Id: If086c50ae803b384691f709057bceeac2fc1d9d5
Merged-In: If086c50ae803b384691f709057bceeac2fc1d9d5
ACTION_MULTI_SIM_CONFIG_CHANGED will be sent when multi-SIM
variants change.
Bug: 141388730
Test: test app
Change-Id: I717482ea05571afdfe6b04318d3f1fbda0c177ed
Merged-In: I717482ea05571afdfe6b04318d3f1fbda0c177ed
A memfd file can be created with any name, but to protect ourselves
from unintended leakage, check that it's the name ART uses.
Test: boots
Bug: 119800099
Change-Id: Ibc684d09dd05f38933c6808b72fb402fc9d5e4eb
