The return result from starting activity actually represents two
pieces of information. First, it conveys whether the activity
started. Secondly, it conveys whether there was a fatal error if
the activity did not start. Many parts of the code assume that a
value greater than or equal to the defined success means that the
activity successfully started. This is not the case as there are a
number of results greater than success where the activity does not
start.
This change addresses the issue by introducing three distinct
result ranges. The first represents results where the activity
could not start due to a fatal error. The second represents results
where the activity did not start due to a non-fatal error. The last
range represents successful activity starts. Two convenience methods
have been added to ActivityManager to return whether the result
represents a fatal error and whether the result was successful.
Change-Id: Ifaf844c353641a28b03b3c2d7b6be053fd9b8b44
Fixes: 38021882
Test: cts-tradefed run cts-dev --module DevicePolicyManager --test com.android.cts.devicepolicy.DeviceOwnerTest#testLockTask_deviceOwnerUser
Some users never get switched to (managed profile/work profile) so the
overlay state for a user would never be setup (but they could still show
UI and apps).
This change ensures that user state is setup after an OTA to android O,
and whenever a user is added.
Bug: 37899201
Test: manual (add user via Device Admin sample: vendor/google/tools/DeviceAdminSample)
Change-Id: If214e26e39b18c2861794baf5c608a47d536e5ff
- Fixed PFLAG3_NOTIFY_AUTOFILL_ENTER_ON_LAYOUT value - it was overlapping with
PFLAG3_ASSIST_BLOCKED.
- Added missing permission on methods called by Shell command.
- Improved debugging.
Bug: 38173625
Test: android.autofillservice.cts.MultipleFragmentLoginTest#loginOnTwoFragments
Change-Id: Ie7880c97d38298e06134709c5c2e9e38fa1bacbb
After discussion about how best this could fit in the API we
discovered many disagreements that we couldn't resolve in the
time available. Pulling the feature from the API until we
can resolve issues.
Test: builds
Change-Id: I6d36a1dea8ce9816fad497b992a347188d3ac88e
This CL includes the new Java API that supports async network scans.
Applications could get faster network scan results with this new API.
The long-term goal is to support Subsecond Switching which is separate
from what this CL is doing.
Bug: 30954762
Test: Unit test, run runtest -x NetworkScanRequestTest.java
Change-Id: I78cadaf838dee8439fe7417ef39f689990bf5705
(cherry picked from commit fdfb6f4d2f6db943d648adec6cc96530f2f70fe6)
This keeps the install flow fast, and also happens to mean that
there is feature parity in this regard between pre-O and O+
instant app handling.
Fix#38263351
Test: manual
Change-Id: I8eb08c12d800f5288583e792621920c9876efdfc
RIL_UNSOL_MODEM_RESTART will be sent by vendor RILs when it detects
a modem restart along with the reason for restart which could be a
crash signature if the modem restarted due to a crash or a some
other string such as a user-initiated restart or AT command
initiated restart.
Test: Manual
Merged-In: Idf08e20a49e82d40f6aa0854d23384c35c2efc3a
Change-Id: Idf08e20a49e82d40f6aa0854d23384c35c2efc3a
This shouldn't change any behavior, but improve the reason we
report for each process's oom_adj / proc state level. There are
two significant things going on here:
1. We now consider a bump up in proc state to be just as significant
as a change in oom_adj, and accordingly update the reason when this
happens. Given how many proc stats we now have mapped to some of
the single oom_adj levels, this matches your expectation to have the
reason be why it is at that proc state and not just some random
other thing at that level.
2. There is special handling of an app at the top state connecting
to another app, deciding the actual state to apply at the end. This
was not at that point updating the reason, so anything the top app
is connected to would get the top state but myseriously have some other
reason, looking very broken. We now propagate the reason over.
Test: manual
Change-Id: Idecbe206d73e7c4cbd989ef6faf3b1679e06c088
Set imeOptions to be actionNext for the hour field of TimePicker to
allow users to jump to the next field using the keyboard.
Bug: 36863243
Test: Manual, keyboard now shows next button instead of enter that moves
focus to the next field.
Change-Id: Ia9d6137d14579ba5b99fbb714a78423cc75b5fa0
