e17b445b6c813f6f9bc93a5e3811128a197ef50b |
|
10-Jan-2018 |
Dianne Hackborn <hackbod@google.com> |
Reduce pss collection amount, improve logging. Tuned rates that we collect PSS, to reduce how much we do that heavy operation. Added a new way to determine whether a process has changed to a state for the "first" time -- now this is when it has gone to that state for the first time since it was in a lower state. This will reduce the amount of time we consider a process to be first to only when it has previously gone into a higher state than it had before. Keep track of more fine-grained information about why we collect a PSS sample (not just internal, but for a single process, all processes because of a mem state change, all processes because of a poll). Started collecting RSS in various places, so we can start looking at that w.r.t. PSS and see about transitioning to it is a new primary metric. Added logging for many of the places where the system writes its configuration files, so we can more easily see any bad behavior going on in those areas. Added some currently disabled code to read smaps directly instead of using fgets(). Probably won't help, but want tot test. Bug: 70859548 Test: atest CtsAppTestCases Change-Id: I400dba0f3ae9c024df51c946cfa592561028b598
/frameworks/base/core/java/android/util/AtomicFile.java
|
616541d7016ee4440051738a8f0c7c3b7086d375 |
|
26-Jul-2017 |
Christopher Tate <ctate@google.com> |
Persisted jobs versus incorrect boot-time RTC Devices routinely boot in a state where the RTC is wildly incorrect in the past (2009, 1999, or even at Unix epoch zero). When we have persistent jobs to be scheduled at boot, this presents a problem: when should those jobs run, given that our idea of "now" is incorrect? The previous implementation fell back to rescheduling these jobs "from scratch" in this situation, as though they were newly-introduced, but this turns out to have some emergent pathologies when the jobs were intended to become runnable after long initial delays: the rescheduling behavior could wind up starving jobs out entirely, never running them regardless of how much real uptime the device had, given the "wrong" pattern of reboots. We now preserve the original nominal schedule, but recognize when we have booted in a pathological situation, and correct the schedule for these jobs when the system clock becomes sensible. Bug 63817592 Test: JobScheduler test suite plus manual bogus-boot-time repro Change-Id: Ia36fc5298b68db74e4e07e973b68e68e66206b43
/frameworks/base/core/java/android/util/AtomicFile.java
|
74bf71b23c5deca47166d6627361f26ee5d62a7c |
|
20-Jul-2017 |
Amith Yamasani <yamasani@google.com> |
Handle an edge case that can reset settings provider data If the AtomicFile does the rename and fails when writing the original, make sure we can at least use the backup on reboot. Bug: 63753300 Test: Stop shell, move settings_global.xml to backup, start shell. Change-Id: I2049b48af05161bb2c68717a71c1700a95150a6c
/frameworks/base/core/java/android/util/AtomicFile.java
|
47aafbe033202ccc2c0ea9af2b0f1596ebed4373 |
|
13-Feb-2017 |
Eugene Susla <eugenesusla@google.com> |
Record app<->device association to xml file Bug: 30932767 Test: Ensure file not exists -> query associations -> ensure result is empty list Associate device -> cat xml file -> ensure record appears as extected Disassociate device -> cat xml file -> ensure record is no longer present Change-Id: Ibe456a6d9292e05e2391f5138e43fdaa37f87e1b
/frameworks/base/core/java/android/util/AtomicFile.java
|
683914bfb13908bf380a25258cd45bcf43f13dc9 |
|
15-Jan-2015 |
Svetoslav <svetoslavganov@google.com> |
Rewrite of the settings provider. This change modifies how global, secure, and system settings are managed. In particular, we are moving away from the database to an in-memory model where the settings are persisted asynchronously to XML. This simplifies evolution and improves performance, for example, changing a setting is down from around 400 ms to 10 ms as we do not hit the disk. The trade off is that we may lose data if the system dies before persisting the change. In practice this is not a problem because 1) this is very rare; 2) apps changing a setting use the setting itself to know if it changed, so next time the app runs (after a reboot that lost data) the app will be oblivious that data was lost. When persisting the settings we delay the write a bit to batch multiple changes. If a change occurs we reschedule the write but when a maximal delay occurs after the first non-persisted change we write to disk no matter what. This prevents a malicious app poking the settings all the time to prevent them being persisted. The settings are persisted in separate XML files for each type of setting per user. Specifically, they are in the user's system directory and the files are named: settings_type_of_settings.xml. Data migration is performed after the data base is upgraded to its last version after which the global, system, and secure tables are dropped. The global, secure, and system settings now have the same version and are upgraded as a whole per user to allow migration of settings between these them. The upgrade steps should be added to the SettingsProvider.UpgradeController and not in the DatabaseHelper. Setting states are mapped to an integer key derived from the user id and the setting type. Therefore, all setting states are in a lookup table which makes all opertions very fast. The code is a complete rewrite aiming for improved clarity and increased maintainability as opposed to using minor optimizations. Now setting and getting the changed setting takes around 10 ms. We can optimize later if needed. Now the code path through the call API and the one through the content provider APIs end up being the same which fixes bugs where some enterprise cases were not implemented in the content provider code path. Note that we are keeping the call code path as it is a bit faster than the provider APIs with about 2 ms for setting and getting a setting. The front-end settings APIs use the call method. Further, we are restricting apps writing to the system settings. If the app is targeting API higher than Lollipop MR1 we do not let them have their settings in the system ones. Otherwise, we warn that this will become an error. System apps like GMS core can change anything like the system or shell or root. Since old apps can add their settings, this can increase the system memory footprint with no limit. Therefore, we limit the amount of settings data an app can write to the system settings before starting to reject new data. Another problem with the system settings was that an app with a permission to write there can put invalid values for the settings. We now have validators for these settings that ensure only valid values are accepted. Since apps can put their settings in the system table, when the app is uninstalled this data is stale in the sytem table without ever being used. Now we keep the package that last changed the setting and when the package is removed all settings it touched that are not in the ones defined in the APIs are dropped. Keeping in memory settings means that we cannot handle arbitrary SQL operations, rather the supported operations are on a single setting by name and all settings (querying). This should not be a problem in practice but we have to verify it. For that reason, we log unsupported SQL operations to the event log to do some crunching and see what if any cases we should additionally support. There are also tests for the settings provider in this change. Change-Id: I941dc6e567588d9812905b147dbe1a3191c8dd68
/frameworks/base/core/java/android/util/AtomicFile.java
|
0debc9aff4c0cbc28e083a948081d91b0f171319 |
|
17-Jul-2014 |
Adam Lesinski <adamlesinski@google.com> |
First iteration of a public UsageStats API UsageStats API that allows apps to get a list of packages that have been recently used, along with basic stats like how long they have been in the foreground and the most recent time they were running. Bug: 15165667 Change-Id: I2a2d1ff69bd0b5703ac3d9de1780df42ad90d439
/frameworks/base/core/java/android/util/AtomicFile.java
|
39606a007a5b1309dd000234f2b8cf156c49fd0f |
|
01-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
Make AtomicFile a public API. It's about time! Change-Id: Ib34e294747405b7ab709cb0bbb2d9a0cc80ce86a
/frameworks/base/core/java/android/util/AtomicFile.java
|