Add checks during boot in case the persist.sys.timezone property is set
to a bad ID.
This can happen in the rare case of a mainline rollback: i.e. if a device has
been set to a new ID and then the update is rolled back. Using GMT as a
fallback probably works without this change (it does in java.util.TimeZone),
but relies on all code, including native code that uses
persist.sys.timezone directly, knowing to interpret a bad ID as "GMT".
This commit makes that choice more explicit and defensive.
This change also removes the possibility of IOException, which is never
thrown, from some ZoneInfoDb methods.
Bug: 155738410
Test: boot with a valid id, verify persist.sys.timezone is unchanged
Test: boot with an invalid id set, verify persist.sys.timezone is "GMT"
Merged-In: I6dc0f4f81848efbbaec6a11a62014471a0ef01fd
Change-Id: I6dc0f4f81848efbbaec6a11a62014471a0ef01fd
Exempt-From-Owner-Approval: Approved / landed internally
Seems that the doc-comment-check-docs wasn't in presubmit.
Bug: 6963924
Bug: 155825675
Test: make doc-comment-check-docs
Change-Id: I018a50cd76b0fd5f8c3642efa1374e53f1b746a6
Merged-In: Ib2e4360493275b79c72487ee1cb173bb5e0fd35f
Previously, we generally required fully qualified names for referring
to inner class constructors (like #Notification.Builder()) despite that
not being valid javadoc. Now, we properly support #Builder() syntax and
the old syntax will error.
Bug: 6963924
Test: make doc-comment-check-docs
Change-Id: Ib2e4360493275b79c72487ee1cb173bb5e0fd35f
Merged-In: Ib2e4360493275b79c72487ee1cb173bb5e0fd35f
These were previously being suppressed by doclava but with this change,
all failures are fixed and the suppression logic has been removed.
To fix the issues, there were a few possible changes made:
- broken reference to a public API (such as incorrect parameters): fixed
- unnecessary @link inside an @see tag: fixed
- @see referring to an @hide or @SystemApi: reference removed
- broken references to inner class constructors
- worked around by fully qualifying the constructor
Bug: 6963924
Test: make doc-comment-check-docs
Change-Id: Ifbdce2de96cdffa560bd90f549fa7184d1f9af85
Merged-In: Ifbdce2de96cdffa560bd90f549fa7184d1f9af85
The APIs were added in b/144351078, b/148097978 and b/148116922.
b/151665796 is used to revert them.
Bug: 151665796
Bug: 144351078
Bug: 148097978
Bug: 148116922
Test: build
Change-Id: I08db8c5c0161747a7e775a8de0daa7077b513f10
Merged-In: I08db8c5c0161747a7e775a8de0daa7077b513f10
1. Clarify the distinction between the prioritized and non-prioritized
intents.
2. Make the priority ordering and choice of them more clear.
Test: make -j offline; preview updated docs for formatting.
Fixes: 150685399
Change-Id: I493bca75db44f25eedb07964e3dc8c8ab38827c2
When creating a LoadedApk in a zygote context (app zygote or WebView
zygote), don't add the app's data dir to the list of paths the dynamic
linker is allowed to load libraries from, because the linker's attempt
to canonicalize the path causes SELinux access denials. The process
can't access the data directory at all, so cannot load libraries from
there in any case.
Fixes: 149481620
Test: check for avc denials from webview_zygote
Change-Id: I9aceecaf6067e748cc2251782b0f41661cbb35d8
Merged-In: I9aceecaf6067e748cc2251782b0f41661cbb35d8
Instead, have a dedicated method in android.net.NetworkStack allowing to
fetch the stable AIDL token for the service.
This avoids returning IBinder from getSystemService, as getSystemService
should generally return manager classes.
Test: atest FrameworksNetTests NetworkStackTests
Fixes: 151243982
Merged-In: I58a6e1f27aff052050197d1901f43a98d7aa1167
(clean cherry-pick from internal branch)
Change-Id: I75aba269595f3e315dd5e0693c878b2026e8e299
Block TYPE_PRESENTATION windows on default display
... and any other display that isn't considered a public presentation
display, as per Display.isPublicPresentation()
Bug: 141745510
Test: cts-tradefed run cts -m CtsWindowManagerDeviceTestCases -t android.server.wm.PresentationTest
Change-Id: I2aaab1903dee54190338f7b6e49888aa51437108
(cherry picked from commit 60a6583adf)
In common cases, to resume the next activity we need to wait for the
current one to be paused. Since starting a process for activity is
asynchronous, if we already know the process of next activity has not
started yet, we can start the process earlier so the time waiting for
the pause to complete can be saved.
Also if the launching activity is going to be the top app, we can set
the top schedule group right after its process is started so the start
time before actually launching the activity can be improved.
Although before the current activity is paused, the next top activity
may still change and results some empty processes. That should not be
a common case and the process is still useful when going back the stack,
and the empty background processes are easier to be reclaimed.
Bug: 123043091
Test: AppLaunchTest
Test: Launch calculator from launcher, the event log am_proc_start will
show "pre-top-activity".
Test: Cold launch a top activity, the system log should not show
"not expected top priority".
Test: Use startActivities to start serveral activities in a sequence.
Check "adb shell cat /proc/$pid/task/$pid/cgroup" for each process.
Only the last one has top-app, others are background.
Change-Id: I9601b66e7cc0855fd7c2b573ded31fcf8d0711ae
Merged-In: I9601b66e7cc0855fd7c2b573ded31fcf8d0711ae
The permission check is already implemented server side.
Test: m
Bug: 150471082
Change-Id: I63d807be84bccb237f69562cdbce22f99a964d1a
Merged-In: I63d807be84bccb237f69562cdbce22f99a964d1a
with appOp as String and options as Bundle
Bug: 139077993
Bug: 146423958
Test: Build
Change-Id: I5325e08d60016741139251813a5df9b42f2efc82
Merged-In: I5325e08d60016741139251813a5df9b42f2efc82
Add support for "adb shell cmd time_zone_detector".
This allows platform developers and future host tests to simulate
clients like telephony / SettingsUI and make changes to the
TimeZoneDetectorService state to mimic various real-world situations.
Example adb shell invocations:
Withdraw a previous telephony suggestion from slot_index=0:
cmd time_zone_detector suggestTelephonyTimeZone --suggestion --slot_index 0 \
--zone_id "_"
Make a new telephony suggestion from slot_index=0, with a quality of
TelephonyTimeZoneSuggestion.QUALITY_SINGLE_ZONE, and a matchType of
TelephonyTimeZoneSuggestion.MATCH_TYPE_NETWORK_COUNTRY_ONLY:
cmd time_zone_detector suggestTelephonyTimeZone --suggestion --slot_index 0 \
--zone_id "Europe/London" --quality single --match_type country
Make a manual (user) suggestion as if from SettingsUI:
cmd time_zone_detector suggestManualTimeZone --suggestion --zone_id America/Los_Angeles
Bug: 140712361
Test: Various command line invocations.
Test: atest core/tests/coretests/src/android/app/timezonedetector
Change-Id: I0f16868a526d2ea4b17acbd274cb2359f93166f5
Currently, registerNetworkStatsProvider requires the
UPDATE_DEVICE_STATS permission. This is a privileged permission
so it can be granted to preinstalled apps. Thus, apps like
GmsCore, or preinstalled apps will be able to update network stats.
This change checks for a new permission that would only allow
signature apps to declare that. Also check
MAINLINE_NETWORK_STACK permission to allow NetworkStack process
to use it.
Test: adb shell dumpsys netstats
Test: atest FrameworksNetTests
Bug: 149652079
Change-Id: Idfebd0a1988c3dcfd812d87e30f6a2034d6fbf6b
Reason for revert: cache needs to be cleared on package install.
This is much simpler to do in internal master with recent changes
(ag/10172190) so I'm reverting the cache from aosp to keep it correct,
and cherrypicking this into internal master.
Change-Id: I71757a5b60fbdba3c69322b95a20527a1e3a66e9
Original commit:
[DexLoadReporter] Report classloader contexts directly from classloader
At the moment classloader contexts are incorrectly computed in the
PackageManager for secondary dex files. There are two issues:
(1) The wrong computed classLoaderContext will be reported for a secondary
dex file if it was loaded at the same time as a primary dex file
- This is due to the continue statement that doesn't increment
dexPathIndex
(2) If a secondary dex file was loaded with a shared library then that
shared library info isn't passed through the dex load reporting
infrastructure, and thus its classloader context is incorrectly computed
in PackageManager.
In order to fix the issues described above & prevent further classloader
context computation divergences between the package manager and the
runtime, lets compute the classloader context in the runtime at dex load
time and report the expected classloader context directly to
DexLoadReporter (and thus the package manager).
Notes: This is mostly just a refactor (i.e. there are a lot of line
changes, but functionally speaking this set of CLs doesn't do much
except change where the classloader context is computed)
Addendum: The bugs described above could also be fixed by:
- changing DexLoadReporter to report information about shared libraries that
the reported classloaders depend on to PackageManager
- Teach DexoptUtils.processContextForDexLoad about shared libraries
- Fix dexPathIndex calculation in DexManager
I opted for this set of changes instead because this reduces the
possibility of context computation divergence between the framework and the
runtime. Additionally it feels more "solid" that the classloader context
is now computed directly when a dex file is loaded, rather than the
context recreated later on in the PackageManager.
Test: atest com.android.server.pm.dex.DexManagerTests
Test: atest com.android.server.pm.PackageManagerServiceTest
Test: Install app depending on shared library & uses secondary dex
files; adb shell pm bg-dexopt-job; launch app and see odex file
successfully loaded (from smaps/no logcat errors)
Bug: 148494302
Exempt-From-Owner-Approval: This is a pure re-revert, previously owner approved.
Reason for revert: Re-land
Reverted Changes:
I295a6e99e:Revert "Fix shared libraries not being reported vi...
Ib58066e8f:Revert "[DexLoadReporter] Report classloader conte...
Change-Id: I8d1af791f93a3f8fa6eca78df50891cd2ebbb4a3
