* changes:
DO NOT MERGE: Fixes NPE when preparing app data during init
Support privileged apps installed in APEX.
Support non-privileged APKs in APEX.
Refactors initial directory scan to be dryer
* changes:
[Tether10]Remove UserManagerInternal usage in Tethering
[Tether07] Migrate Tethering into module
[Tether07] Clean up build rule for libtetheroffloadjni
To be the unbundled application, tethering can not use UserManagerInternal
method anymore. Replace it by listening user restriction change intent.
Also fix some cleanup from
https://android-review.googlesource.com/c/platform/frameworks/base/+/1131002
Bug: 143195885
Test: -build, flash, boot
-atest TetheringTests
-manual test. Add a trigger point to call
UserManager.setUserRestriction(DISALLOW_CONFIG_TETHERING) from
Settings. Open hotspot -> restrict tethering from new adding trigger
point -> hotspot is OFF and Tethering settings are not available.
Change-Id: I4ed08d20f8b7476b8ecd5d018b75806dd2f22cc1
Merged-In: I4ed08d20f8b7476b8ecd5d018b75806dd2f22cc1
Now tethering would be run in dedicated service.
TetheringManager is the interface used to communicate with
TetheringService. The new call flow would be: ConnectivityManager
-> ConnectivityService -> TetheringManager -> TetheringService.
Note: the return value of #tether(), #untether() and #setUsbTethering()
APIs would always be no error. Client can use #getLastTetherError()
or #getTetheredIfaces or listen tether state change to check
status of corresponding interface.
Bug: 136040414
Bug: 144742179
Test: -build, flash, boot
-atest TetheringTests
-atest FrameworksNetTests
Change-Id: I7e78c0e0a3e70f940a749ba2a39ece7c7ec5b9b3
Merged-In: I7e78c0e0a3e70f940a749ba2a39ece7c7ec5b9b3
This change adds initial support for scanning APEX directories looking
for APK, and make them available to the system as normal system APKs.
For now privileged apps and resource overlay are not supported, and the
support will be added in a later CL.
Scanning features are inherited from the partition in which the
preinstalled version of a given APEX module is located.
Supports both flattened and un-flattened APEX configurations.
Bug: 138429615
Test: Compiled a test apex with the Snake app installed in it. Verified
app is correctly scanned and usable. Tried also installing the apex in
/vendor and /product.
Exempt-From-Owner-Approval: Approved in
https://googleplex-android-review.git.corp.google.com/c/platform/frameworks/base/+/9533445
Merged-In: I8fb91317da0296567403b2b62babbb71e4b48938
Change-Id: I8fb91317da0296567403b2b62babbb71e4b48938
For the AIDL compiler to call. Without this, the Java framework can't
pass callbacks to HALs.
Bug: 139325468
Test: use vibrator callback from Java
Change-Id: I147d3e3da699ce740f6589264b37f43f8557719b
Convenience utilities for working with HidlMemory.
Change-Id: I85a46d37de7b89fb48c57f69b1552ca59b802c19
Merged-In: I85a46d37de7b89fb48c57f69b1552ca59b802c19
Bug: 143566068
This change adds support for reading/writing a HidlMemory
instance into / out of a HwParcel and HwBlob, in a format that
is compatible with the hidl_memory C++ type.
This paves the way to be able to exchange shared memory blocks
between native and Java via HwBinder, which will be exposed
as adding Java support for the HIDL 'memory' type.
Change-Id: I6cbbf852218c8a631f9014e7caa7a97d17e11889
Bug: 143566068
Merged-In: I6cbbf852218c8a631f9014e7caa7a97d17e11889
Remove dead code from SystemServer that obstensively protects devices
from negative (< 1970) system clock times, but does not.
In reality, SystemServer calls SystemClock.setCurrentTimeMillis(), which
calls through to the AlarmManager.setTime() binder call. When the code
runs the system server hasn't started any services yet, so this would
always fail.
AlarmManager has similar protections in place that do work: if the
device is earlier than a "build time", then the device's clock is forced
forward. That provides the protection that the code being removed from
SystemServer was trying to achieve.
Test: Added logging to SystemClock to prove AlarmManager is null /
manual debugging
Change-Id: I87dca1062829bc1a10202804fa7ee31e0a6f03a3
This new interface allows Java code to look up property values without
paying for the name->prop_info mapping and, in the case of looking up
scalars, without doing any allocation.
Bug: 140788621
Test: added tests
Test: atest FrameworksCoreSystemPropertiesTests
Change-Id: I46d12f62499e9e124fe9add588376d724b364d5d
A subsequent CL will implement a new prop_info based properties API on
top of this CL.
Test: boots
Test: atest FrameworksCoreSystemPropertiesTests
Bug: 140788621
Change-Id: Id8dd02fff7b1c0815a27ab1dfdde1700447a414c
* changes:
Add new API for Telecom to send phone state
Minor style correction to avoid merge conflict
non-mainline telephony related AIDL refactor/decoupling
1. decouple IOnSubscriptionChangedListener AIDL from telephonyMainline
2. other refactor. moving APIs which will not be included in
telephony mainline to frameworks/base/core/java/android/telephony.
Moving internal classes like AIDL which will not be included in
telephony mainline to
framework/base/core/java/com/android/internal/telephony
Bug: 140908357
Test: Build & unit test
Change-Id: I9413ef758cceadd251d03f3b5ea1054cc48ef044
Merged-In: I9413ef758cceadd251d03f3b5ea1054cc48ef044
This API encourages swallowing errors, and the code to implement it is trivial if apps still want to do it themselves.
Guava's reasoning on deprecating their version of this API:
https://github.com/google/guava/issues/1118
Test: No behavior changes
Bug: 144042891
Change-Id: Ic4cfb7366c65d49c355479f420d9ba4fc1b3f053
These have been the cause of bugs in the past, such as b/10150258,
because it's not always obvious or guaranteed that a calling thread will
always have a looper, or that it's actually the looper you want.
Specifying the looper explicitly, even if it's just Looper.myLooper(),
makes the code clearer. Since callback APIs generally should have
Executor variants added, it might be nice to also deprecate the
constructors or options that rely on the calling thread's looper, but
since I don't have an inventory of all those I'm starting with this.
Bug: 144042891
Test: No behavior changes
Change-Id: I0e7ba80d6b89a866ea715c790dd602ef728bf5bd
This CL uses getGroupUuid() and isOpportunistic() instead to figure
out whether the subscription is visible or not
Bug: 140768340
Test: Manual
Change-Id: Id7215eabe4e6c47a057b747fdbb3027857f2f12c
go/cleanup-greylist-txt
These have already been greylisted, however due to bugs/omissions in the tooling have been kept in go/greylist-txt instead of being annotated in the code.
Bug: 137350495
Test: m
Change-Id: Id6c1f5e403a0e66edb1102ee45f3bf19f244fb09
Merged-In: Id6c1f5e403a0e66edb1102ee45f3bf19f244fb09
See go/UnsupportedAppUsage for more details.
These have already been greylisted, however due to bugs/omissions in the tooling have been kept in go/greylist-txt instead of being annotated in the code.
Bug: 137350495
Test: m
Change-Id: I5aa29a49b193db47aaee4d3a756c17f48cc9f0b1
Merged-In: I5aa29a49b193db47aaee4d3a756c17f48cc9f0b1
This is a preparatory work for mainline. since Intdef is hidden, so we
have to move some annotations (applied in SDK/system API) to a separate
annotation class and having other module statically link to it.
TODO: include telephony annotation in framework-non-updatable-sources
Bug: 140908357
Test: Build
Change-Id: I37f8a0624bbf27f264870ee9dbf03d3aaa5cadc1
(cherry picked from commit c9d4ee112e)
Merged-in: I37f8a0624bbf27f264870ee9dbf03d3aaa5cadc1
(cherry picked from commit 4712711d3d91621083bf92f5a1647b92c20a8b81)
today telephonyRegistry lives in system process
this is intended to persists all telephony listeners when
phone process crash. Telephony today notify system server by
using AIDL APIs directly. Instead, we are exposing a proper API
surface: telephonyRegistryManager where only phone app and
carrier privileged apps are allowed to use APIs in
TelephonyRegistryManger to notify telephony related status update.
Bug: 140908357
Test: Build & Manaul
Change-Id: I1b750751148925b4a7bd94553318907654012fc1
(cherry picked from commit 288b71c8c1)
Merged-in: I1b750751148925b4a7bd94553318907654012fc1
This class is hanging around for UnsupportedAppUsage. Adding additional
method to fix compilation, but it should never be called.
Bug: 135686713
Test: compilation fixed
Change-Id: I58022af86a53239990e057936826d0f1214acc6f
Instead of storing each Locale within a Configuration object's locale
list by its language, country, variant, and script to proto, store the
entire locale list by its language tags representation which accurately
describes each locale.
Bug: 140197723
Test: atest ConfigurationTest
Test: atest UsageStatsDatabaseTest
Test: manually with bad data
Merged-In: I53946ed4e31de0ffe9c84875c391a7dec6f5375a
Change-Id: Idaae690f79a5c680ad0059a52be62160d9dfb5e7
(cherry picked from commit 5e67462971)
ro.build.fingerprint is dynamically generated by deriveFingerprint(),
but its output does not match ro.{system,vendor}.build.fingerprint.
Fixes:
======
E Build : Mismatched fingerprints; system reported \
Sony/aosp_f8331/kagura:10/QP1A.191005.007/eng.builde.20191020.005112:user/test-keys \
but vendor reported Sony/aosp_f8331/kagura:10/QP1A.191005.007/builder10200050:user/test-keys
Example:
========
ro.system.build.fingerprint = Sony/aosp_f8331/kagura:10/QP1A.191005.007/builder10200050:user/test-keys
ro.build.fingerprint = Sony/aosp_f8331/kagura:10/QP1A.191005.007/eng.builde.20191020.005112:user/test-keys
The critical difference is that deriveFingerprint() inserts the value of
"ro.build.version.incremental", while the actual fingerprint produced by
build/make/core/Makefile is:
BUILD_FINGERPRINT := $(PRODUCT_BRAND)/$(TARGET_PRODUCT)/$(TARGET_DEVICE):\
$(PLATFORM_VERSION)/$(BUILD_ID)/$(BF_BUILD_NUMBER):$(TARGET_BUILD_VARIANT)/$(BUILD_VERSION_TAGS)
Where:
BF_BUILD_NUMBER := $(BUILD_USERNAME)$$($(DATE_FROM_FILE) +%m%d%H%M)
Fix:
====
Use ro.system.build.fingerprint instead, which will match
ro.vendor.build.fingerprint.
Test:
=====
make otapackage, flash, boot, verify no warning message is shown in UI.
Change-Id: Ie5e972047d7983b411004a3f0d67c4636a205162
Signed-off-by: Felix <google@ix5.org>
