UserDataPreparer: fix volume preparation order

Internal storage must be prepared before adoptable storage, since the
user's volume keys are stored in their internal storage.  Previously,
the order depended on the Java hashcodes of the volume IDs.  It seems
that in practice things sort of worked out anyway even with the wrong
order, via a bizarre sequence of events involving the user's storage
being deleted and re-created several times.  Regardless, let's fix it.

destroyUserData() sort of had the reverse bug, although I don't think it
actually mattered.  My concern there was that destroying the internal
storage first would bypass vold's destroyKey() for the volume keys.
However, that's okay since the volume keys don't actually need a special
destruction procedure in this case.  Also, internal storage has already
been locked when destroyUserData() runs anyway.

Test: On Cuttlefish:
      $ sm partition disk:253,32 private
      $ pm create-user 10
      $ pm remove-user 10
      Checked logcat for expected messages.
Bug: 231387956
Change-Id: I146d8c786c6b923aed7f8c748db8a7e90c96687f
(cherry picked from commit a8a53c2615f4f6fe9ba14c920bfd8d0b27b8233f)
Merged-In: I146d8c786c6b923aed7f8c748db8a7e90c96687f

0 files changed, 0 insertions, 0 deletions