1# Problem 2On Android S, AdServices code is part of the ExtServices APK. During normal functioning of AdServices, it generates multiple data files (e.g., adservices.db, adservices-msmt.db etc.). These files are stored in the APK’s data directory for the current user (e.g., /data/user/0/com.google.android.ext.services/). 3 4When the device receives an OTA from S to T, the AdServices apex gets installed and the AdServices code gets removed from the ExtServices APK on T. After OTA, the consent state, blocked-topics, and blocked-apps are migrated because they’re stored in AppSearch. The data in the APK’s directory is not migrated, and the PPAPIs within AdServices behave as if it’s a fresh user. 5 6User data within AdServices is cleaned up by scheduled jobs that run periodically. However, because the AdServices code is removed from the ExtServices APK, it does not clean up all the files that were generated during normal operation before the OTA. It therefore results in multiple orphaned files within the ExtServices APK post-OTA. Some of these files contain user data and must be deleted. 7 8There is also non-AdServices code within ExtServices, and those could be creating files within the data directory as well. These files must be preserved post-OTA and should not be deleted. 9 10# High-Level Strategy 11After an OTA to T, we need to do the following: 121. Identify the AdServices files within the ExtServices data directory 132. Trigger code within ExtServices that is responsible for cleaning up the orphaned files. 143. Record successful deletion, and do not trigger this cleanup code subsequently. 15 16Edge cases to also consider: 171. New files may be added to the AdServices code over the next few years that would also need to be cleaned up if the device OTAs from S running the new AdServices version. 182. Any manual identification of the generated files may miss something, for which we’ll need to be able to update the cleanup logic and execute it again. 19 20# Identifying AdServices files 21To distinguish between files generated by AdServices and non-AdServices code in ExtServices, we’ll rename all the files being created to have a prefix of adservices. In some cases, the files already contain this prefix, so those can be left as-is. Files that don’t contain this prefix will be renamed only on R/S to instead start with adservices_. We cannot rename or change the location of current files on T+ since that would break existing functionality. 22 23# What will be deleted 241. Any folder that begins with adservices will be deleted completely (i.e., all files, recursive). 252. Any file in any folder that begins with adservices, even if the folder name does not have adservices in it. 26## Examples of files that will be deleted: 27* /data/user/0/com.google.android.ext.services/files/adservices.db 28* /data/user/0/com.google.android.ext.services/files/nested/adservices.db 29* /data/user/0/com.google.android.ext.services/databases/adservices-data/fledge.db 30* /data/user/0/com.google.android.ext.services/cache/adservices_cache/nested/temp.xml 31## Examples of files that will NOT be deleted: 32* /data/user/0/com.google.android.ext.services/files/textclassifier.xml 33* /data/user/0/com.google.android.ext.services/databases/textclassifier/model.db 34 35# Preventing future issues 36The biggest risk comes from engineers accidentally not following the naming conventions for new files that will be added in the future. In order to minimize the risk of that happening, all new files and databases should be added to a sub-folder named adservices-data within each of the top-level folders (e.g., .../files/adservices-data/ and .../databases/adservices-data/). 37 38To enforce this automatically, we have created this lint rule that prohibits the direct use of context.getFilesDir(), context.getDatabasePath() and Room.databaseBuilder. We should instead use helper utility classes that will ensure that the location of the files & databases lie within the adservices-data sub-folder. 39