)]}'
{
  "commit": "e03e987337accde646e4e86c1fdfe02c0d78d743",
  "tree": "e2f7a74f5462f1083a6e8b00ab3a490c567ddf51",
  "parents": [
    "ecf569bd1623231984e9ec9823edb82f52d7846a"
  ],
  "author": {
    "name": "Eric Biggers",
    "email": "ebiggers@google.com",
    "time": "Fri Mar 04 00:07:43 2022 +0000"
  },
  "committer": {
    "name": "Eric Biggers",
    "email": "ebiggers@google.com",
    "time": "Tue Mar 29 20:48:47 2022 +0000"
  },
  "message": "[RESTRICT AUTOMERGE] Ignore errors preparing user storage for existing users\n\nUnfortunately we can\u0027t rule out the existence of devices where the user\nstorage wasn\u0027t properly prepared, due to StorageManagerService\npreviously ignoring errors from mVold.prepareUserStorage, combined with\nOEMs potentially creating files in per-user directories too early.  And\nforcing these broken devices to be factory reset upon taking an OTA is\nnot currently considered to be acceptable.\n\nOne option is to only check for prepareUserStorage errors on devices\nthat launched with T or later.  However, this is a serious issue and it\nwould be strongly preferable to do more than that.\n\nTherefore, this CL makes it so that errors are checked for all new\nusers, rather than all new devices.  A field ignorePrepareStorageErrors\nis added to the user record; it is only ever set to true implicitly,\nwhen reading a user record from disk that lacks this field.  This field\nis used by StorageManagerService to decide whether to check for errors.\n\nBug: 164488924\nBug: 224585613\nTest: Intentionally made a device affected by this issue by reverting\n      the CLs that introduced the error checks, and changing vold to\n      inject an error into prepareUserStorage.   Then, flashed a build\n      with this CL without wiping userdata.  The device still boots, as\n      expected, and the log shows that the error was intentionally\n      ignored.  Tested that if a second user is added, the error is\n      *not* ignored and the second user\u0027s storage is destroyed before it\n      can be used.  Finally, wiped the device and verified that it won\u0027t\n      boot up anymore, as expected since error checking is enabled for\n      the system user in that case.\nChange-Id: I9bdd1a4bf5b14542adb901f264a91d489115c89b\n(cherry picked from commit 60d8318c47b7b659716d71243d087b34ab327f64)\nMerged-In: I9bdd1a4bf5b14542adb901f264a91d489115c89b\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "fbe8c04bd59cdab4c13d92cabcf6bf99fc9ed926",
      "old_mode": 33188,
      "old_path": "services/core/java/android/os/UserManagerInternal.java",
      "new_id": "8361e0fbf0f6af42e772cb8bdb09a9ab636c24c5",
      "new_mode": 33188,
      "new_path": "services/core/java/android/os/UserManagerInternal.java"
    },
    {
      "type": "modify",
      "old_id": "ebe49cbdf257a055e1af363b00d1d49b490e7aad",
      "old_mode": 33188,
      "old_path": "services/core/java/com/android/server/StorageManagerService.java",
      "new_id": "64aa443bdda2a49063b99bf7c8a5aabe4408f58b",
      "new_mode": 33188,
      "new_path": "services/core/java/com/android/server/StorageManagerService.java"
    },
    {
      "type": "modify",
      "old_id": "27924a68ff485264fbcd606cc4e89fa4a2bdd0a5",
      "old_mode": 33188,
      "old_path": "services/core/java/com/android/server/pm/UserManagerService.java",
      "new_id": "66fc608ead4a7a53b0123a6fbbdada943670705d",
      "new_mode": 33188,
      "new_path": "services/core/java/com/android/server/pm/UserManagerService.java"
    }
  ]
}