FMT_MEC_EXT.1, in PP_APP_v1.4, states that the application must only use the mechanisms recommended by the platform vendor for storing and setting configuration options. In the Evaluation Activity section, it lists the following permissible mechanisms on Android:

1. SharedPreferences

2. PreferenceActivity

Since the SFR was written, Android has come out with a new mechanism called DataStore [0]. They recommend using DataStore instead of SharedPreferences because it's asynchronous, consistent, and transactional. It also supports protocol buffer based schemas, which provide type safety

SharedPreferences, PreferenceActivity and DataStore are not designed to store large quantities of configuration data, but the test activity precludes use of any other platform-provided method.

TD0624 is archived and replaced with the following:

In PP_APP_v1.4, under section FMT_MEC_EXT.1 Supported Configuration Mechanism, the Evaluation Activities, Tests is modified as follows, with red-highlighted strikethroughs denoting deletion and green-highlighted underlines denoting additions:

Platforms:Android...

The evaluator shall inspect the TSS and verify that it describes what Android API is used (and provides a link to the documentation of the API) when storing configuration data. The evaluator shall run the application and make security-related changes to its configuration. The evaluator shall check that at least one XML file at location /data/data/package/shared_prefs/ reflects the changes made to the configuration to verify that the application used SharedPreferences and/or PreferenceActivity classes for storing configuration data, where package is the Java package of the applicationverify that the behavior of the TOE is consistent with where and how the API documentation says the configuration data will be stored.

This makes the evaluation activity work with all methods supported by the platform for storing configuration data and is also more in line with the evaluation activies for the other platforms.