Mounting encrypted OBB files has never worked reliably across devices,
partly due to its reliance on Twofish encryption support in the kernel.
This is because Twofish support (CONFIG_CRYPTO_TWOFISH) has never been
required or even recommended for Android. It has never been enabled in
GKI, but even before GKI it wasn't required or recommended. Moreover,
this is now the only Android feature that still uses dm-crypt
(CONFIG_DM_CRYPT), and some devices don't have that enabled either.
Therefore, it appears that this feature is unused. That's perhaps not
surprising, considering that the documentation for OBBs
(https://developer.android.com/google/play/expansion-files) says that
they are deprecated, and also it explains OBBs as being app files that
are opaque to the platform; the ability of the platform to mount OBBs
that happen to be in a particular format is never mentioned. That means
that OBB mounting is probably rarely used even with unencrypted OBBs.
Finally, the usefulness of OBBs having their own encryption layer (in
addition to what the platform already provides via FBE) is not clear
either, especially with such an unusual choice of cipher.
To avoid the confusion that is being caused by having the broken code
for mounting encrypted OBBs still sitting around, let's remove it.
Test: atest StorageManagerTest # on Cuttlefish
Test: atest StorageManagerIntegrationTest # on Cuttlefish
Bug: 216475849
Change-Id: I6e6a6462ab8343299dc5e0145b87dc28b16b0bc1
Currently, we create sdk directories for all apps. This means during
boot time, when we create app data directory for system apps, we are now
creating twice the amount of directories as before. This has significant
impact on boot time.
In order to avoid the regression, we are now limiting the creation to
only when app actually consumes an sdk and needs these directories. We
have introduced a new installd flag: FLAG_STORAGE_SDK, which needs to be
passed to installd when sdk directory should be created for the app.
Bug: 220095381
Bug: 217543371
Test: atest SupplementalProcessStorageHostTest
Change-Id: I72af7c9460892bf7ac6d908a6a7ca6912167b894
Guest users name was stuck with the language when it was created,
and it wasn't changing with the active language setting.
To solve that, removed name parameter from UM.createGuest() and
created the guest user with a null name, then made changes
in UMS.userWithName() to fill the name of guest user with the active
language's translation when it has a null name.
Creating a guest with a specific name is still supported
through UM.createUser API.
Bug: 185309160
Test: atest com.android.server.pm.UserManagerTest
Change-Id: I2745aed0ea722765a11c6da40fb4159146da54c7
Merged-In: I2745aed0ea722765a11c6da40fb4159146da54c7
(cherry picked from commit c556777ca4)
Much usage of isManagedProfile should probably really be isProfile instead, so have the javadoc explicitly point to it.
Bug: 170249807
Change-Id: Ia6c3cc6d052f2b9f6581fd160410b9ef601c3bcf
Test: N/A (just doc)
In order to test MODULE_LIBRARIES System APIs, the
@TestApi annotation needs to be explicitly added. Also adds
some whitespace changes which were autogenerated when
updating the APIs. Also renames Process.toAppUid().
Test: atest ProcessTest
Bug: 218723058
Change-Id: I49bee200c267550b9616ad0b43022126d2d7cc4b
This change fixes a number of interconnected issues in memory safety
(MTE, GWP-ASan, nativeHeapZeroInit) runtime flags.
* Exported services use the hosting app UID to locate the process
definition, and fail 100% of the time. Use the defining app UID and
package name instead.
* Isolated services process name does not match the name in the defining
app manifest, because it includes a class name and an instance number.
Pass the defining process name in HostingRecord to address this.
* Exported service ApplicationInfo.packageName refers to the hosting
app, again. As a result, wrong compat feature overrides are applied.
This has been fixed before for AppZygote services; extend the fix to all
external services.
* Pass correct memory runtimeFlags to WebViewZygote. This is important
because both MTE and GWP-ASan have a one-way disable switch; they are
enabled in the Zygote and disabled in the apps that do not opt-in.
Passing 0 runtimeFlags to WebViewZygote (and AppZygote) makes it
impossible to enable these features later in their child processes.
This change moves runtimeFlags logic from ProcessList to os.Zygote to
make it available to WebViewZygote.
Bug: 208910418
Test: CtsTaggingHostTestCases
Test: atest in frameworks/base
Test: CtsWebkitTestCases
Test: manual install WebView with android:memtagMode tag
Change-Id: I232d35344f4cd34226ff11324421904b35251525
So they are consistent with Parcel and allow for patterns where the
client specifies a more narrow type to perform the check while returning
or populating a list of a broader type.
Test: atest -d android.os.cts.BundleTest
Bug: b/220872166#comment3
Change-Id: Ie0d430bb0ecd7fe4ee4bbbd245e38ff2813cc4eb
Change validation of user input parameters to create a VibrationEffect
to avoid build the error message string unless the validation fails, do
fix regression on allocation count perf metric.
Fix: 215985428
Test: fixed regression on metric
Change-Id: Ibbcfd450f0b25b88e071f3781952f24a72473575
Build.Version.RELEASE_OR_PREVIEW_DISPLAY propagates a string that
contains a user-friendly version name for preview releases, or the
Build.Version.RELEASE version for final releases.
Test: manual
Bug: 221950960
Change-Id: I31f8f67996e3e5e7edc00704b16b8df0db17d3a3
Signature of readParcelableList() new API is inconsistent with rest,
Changing it to allow using Child class as the required type.
Bug: 221069460
Test: Build and boot.
Change-Id: Ic01c9c8011977d75e3be73f55597dd1bfcd524da
setupBcb() is called before allocating space, if space allocation
failed, we should clearBcb() to properly release resources.
Test: th
Bug: 221001516
Change-Id: Idce67925503cf910ab226b193a4387c32225c0bb
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
