Fix regression introduced by Commit 3fe5af48 where the
hearing aid profile is not stored in BtHelper.
Bug: 211530990
Test: make
Merged-In: Ie3f8757f5fec78df2da028791e9ba2ebb5833675
Change-Id: Ie3f8757f5fec78df2da028791e9ba2ebb5833675
I discovered this error in documentation while I needed to capture "PasteAsPlainText" in an android app.
I suspect it might be missing in other folder too, but I’m not familiar enough with Android to be sure
Change-Id: I77af9b06eb602c4ba60b0744cc02f7449bc4f500
We now allow OEMs to extend the window to cutout area in below cutout
mode, only if the cutout overlaps at most 16dp with the app windows.
- LAYOUT_IN_DISPLAY_CUTOUT_MODE_DEFUALT
- LAYOUT_IN_DISPLAY_CUTOUT_MODE_SHORT_EDGES
Bug: 218603390
Test: make
Change-Id: I8c83cde40f321de2a301b5865445ff765c824d43
Merged-In: I8c83cde40f321de2a301b5865445ff765c824d43
byte(255) converts to int(-1). This is not what we want, we want
int(255), in other words unsigned conversion.
This bug is causing premature EOF when read() is called, because when a
byte(255) is returned, it gets sign-extend to int(-1), causing the
caller to think EOF is reached.
Bug: 217427392
Test: Presubmit
Change-Id: I8ee864816c77cfe2900f5e300d7d4411cce6753a
LockdownVpnTracker gets system_notification_accent_color from
com.android.internal.R. This is not stable across releases, so it
can crash ConnectivityCoverageTests when run on older releases.
Use the system API constant instead, since that is guaranteeed to
be stable. The constant was added in ag/5795405.
Test: atest ConnectivityCoverageTests
Change-Id: I956f9fac4b89cf8429bf46682b52c0203cc4210e
Add safer Bundle APIs that take an extra Class<T> argument that checks
that the type about to be deserialized is a child of the type passed in
parameter *before* actually deserializing it, while also deprecating old
APIs.
This allows use to reap the benefits of the new typed Parcel APIs and
enhances security.
Only the APIs that could involve custom object injection are modified.
So, besides the obvious ones that have that design (eg.
readParcelableList()), subtler cases such as readIntegerArrayList()
could result in custom object deserialization, and since it's all
generics, even the casting inside Bundle wouldn't fail, only after the
client unpacked the list items would it blow up. Now those are checked
beforehand.
Since Bundle always calls Parcel.readValue() under the hood (instead of
specialized APIs such as readParcelable() etc), we had to augment that
method (that's used by LazyValue when retrieving the item) to accept
item types now for containers, which I implemented as a vararg of
Class<?> parameters (this is all private/@hide). This way we could
retrieve a list of intents like readValue(.., List.class, Intent.class),
or a map of string to intents like readValue(.., Map.class,
String.class, Intent.class). For non-container items, we can just pass
no arguments for the vararg. This is explained in internal javadocs.
Inside readValue() now, we also check the container types before
calling the internal methods for deserialization. So, if the thing on
the wire is a VAL_MAP and we know the method we're about to call will
return a HashMap, we verify that the type passed in parameter is a super
type of that (if it's non-null, if it's null it means "perform no
check").
Now, LazyValue became a BiFunction<Class<?>, Class<?>[], Object> to
receive those extra "item types" for containers. The reason for
separating the first from the rest is that the first defines the return
type in the new APIs and inside Parcel, so we need the T from Class<T>
to ensure type-safety.
(I was torn here between using BiFunction or just exposing LazyValue as
@hide for Bundle since it feels like we're missing meaning/abstraction,
but end up leaving this way, advise if you'd prefer the other way)
There was a bit of a refactor in Parcel so readValue() could call
internal methods that accepted nullable Class<?> parameters with the
meaning that null = "no verification" and non-null = "check against
type provided" (because the external APIs all require non-null
parameters).
Now we can return null in all cases when there is a type mismatch. Note
that the Bundle APIs catch ClassCastException to return null, but that
only works for non-generic types (eg. getSizeF()). For generic types
wrapping "return (T) o" with try-catch doesn't work because the type
gets erased to its bound at runtime, so the type mismatch escapes that
try-catch to the caller, potentially causing a crash. Now they happen
inside the getters, as the non-generic ones.
Test: Boots for now
Test: Working on CTS
Test: atest -d android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest
CTS-Coverage-Bug: 219980813
Change-Id: Ifcbeb34b4684d7de105756b9d414162a9205ffaa
When uid is removed, NetworkStatsService will iterate CookieTagMap and
delete the corresponded uid socketTag value. But not only
NetworkStatsService would detete CookieTagMap entries. There are other
threads may also delete CookieTagMap entries such as #unTagSocket in
bpfHandler and desctroy socket listener in TrafficController. System
server crash as NPE because the CookieTagMap entry it iterate just be
removed by other threads at the same time. This is just a simple fix to
prevent the crash. Will have follow up CL for formal fix.
Bug: 220084230
Test: m
Change-Id: I08cad87f537fb09499faf1ff5cfd443fcb8ce436
Fix references for local_include_dirs for aidl support.
BUG: 171106157
Test: Local build and TH
Merged-In: Ice516a0ab0819c4a076c394c05be1643461d4309
Change-Id: I3625bf1e262a031263d500b2c6129bf3c18cdeb2
The current api-versions.xml shipped in the SDK and used internally in
the android build system is generated by the framework-doc-stubs target.
This CL adds a new target that generates an (almost) equivalent database
in a different way. There are a few upshots of using this method to
generate them:
- using the framework-doc-stubs target is inefficient. It runs late in
the build but also takes a long time, extending the critical path of
the modules that depend on api-versions.xml
- the framework-doc-system-stubs target is using module sources as
input, which is desireable to avoid because we want to separate
module sources from the rest of the platform.
Bug: 187398174
Bug: 186197911
Test: m api_versions_{public,system} && diff with "originals"
Change-Id: I8adab94ee7ca0bee4fc0be8d99f1125360387d89
This change populates the VCN type string used in NetworkInfo. While
the NetworkInfo API has long been deprecated, some apps apparently still
use this API. Even more unusually, some apps use the NetworkInfo's type
strings, and perform string comparisons on the type string, as opposed
to the type integer/enums to determine network types.
This change ensures maximum backward compatibility.
Bug: 219287843
Test: atest FrameworksVcnTests
Change-Id: I059dbc997f97482f7355fdc29d464d5452933ce3