platform_system_vold/model/ObbVolume.h

54 lines
1.3 KiB
C
Raw Normal View History

/*
* Copyright (C) 2017 The Android Open Source Project
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
#ifndef ANDROID_VOLD_OBB_VOLUME_H
#define ANDROID_VOLD_OBB_VOLUME_H
#include "VolumeBase.h"
#include <cutils/multiuser.h>
namespace android {
namespace vold {
/*
* OBB container.
*/
class ObbVolume : public VolumeBase {
public:
Remove broken code for mounting encrypted OBB files Mounting encrypted OBB files has never worked reliably across devices, partly due to its reliance on Twofish encryption support in the kernel. This is because Twofish support (CONFIG_CRYPTO_TWOFISH) has never been required or even recommended for Android. It has never been enabled in GKI, but even before GKI it wasn't required or recommended. Moreover, this is now the only Android feature that still uses dm-crypt (CONFIG_DM_CRYPT), and some devices don't have that enabled either. Therefore, it appears that this feature is unused. That's perhaps not surprising, considering that the documentation for OBBs (https://developer.android.com/google/play/expansion-files) says that they are deprecated, and also it explains OBBs as being app files that are opaque to the platform; the ability of the platform to mount OBBs that happen to be in a particular format is never mentioned. That means that OBB mounting is probably rarely used even with unencrypted OBBs. Finally, the usefulness of OBBs having their own encryption layer (in addition to what the platform already provides via FBE) is not clear either, especially with such an unusual choice of cipher. To avoid the confusion that is being caused by having the broken code for mounting encrypted OBBs still sitting around, let's remove it. Test: atest StorageManagerTest # on Cuttlefish Test: atest StorageManagerIntegrationTest # on Cuttlefish Bug: 216475849 Change-Id: Iaef32cce90f95ea745ba2b143f89e66f533f3479
2022-03-01 22:19:18 +01:00
ObbVolume(int id, const std::string& sourcePath, gid_t ownerGid);
virtual ~ObbVolume();
protected:
status_t doCreate() override;
status_t doDestroy() override;
status_t doMount() override;
status_t doUnmount() override;
private:
std::string mSourcePath;
gid_t mOwnerGid;
std::string mLoopPath;
DISALLOW_COPY_AND_ASSIGN(ObbVolume);
};
} // namespace vold
} // namespace android
#endif