I’ve been exploring Samsung apps on Android, and I’d like to share some of my findings. Let’s start with the File Operations History maintained by the Samsung My Files app.
The My Files app keeps a database that logs actions performed on files and folders throughout the system. This database provides a detailed view of user and/or system activity, capturing events such as file creation, movement, copying, and deletion.
Android Version Tested:
Android 15
Test device:
Samsung Galaxy S23
Database Location:[...]/com.sec.android.app.myfiles/databases/OperationHistory.db
-
/data/data/[...]— system-wide -
/data/user/0/[...]— default user -
/data/user/150/[...]— secure folder
By analyzing this database, you can reconstruct file operations done on the system.
The database structure
Table operation_history
- _id - The primary key, iterating number to identify the operation
- mDate - Time and date in UTC when the operation was done. Not totally clear if it is the start or the end timestamp
- mOperationType - Type of Operation - human readable, e.g. MOVE, MOVE_TO_TRASH, RENAME, COPY, DELETE
- mItemCount - Number of Items the operation is done on. This is the aggregated number of folder and files
- mFolderCount - Number of folders the operation is done on
- mPageType - Location in the App from where the operation was triggered.
- mOperationResult - Result of the operation, not always filled with any data.
Table operation_history_data
- _id - The primary key, iterating number to identify the file/folder used in operation
- operation_id - The foreign key, with this we know which operation from the operation_history is related to this line
- src_path - Source path of the file or folder. Has different meanings for operation. E.g. CREATE_FOLDER -> it is the folder where the new folder is created in
- src_file_id - Always identical with src_path in my test data
- dst_path - Destination path of the file or folder. E.g. the file that is created. Can be empty for operations - e.g. for DELETE or EMPTY_TRASH
- dst_file_id - Always identical with the dst_path in my test data
- file_type - Decimal number - meaning currently not totally clear, seems to be based on some MIME type or extensions type things. Current test data shows the following mapping:
Getting and interpreting the data
SELECT mDate [Operation Date], _id [Operation ID], mOperationType [Operation Type], mItemCount [# of Files], mFolderCount [# of Folder], mPageType [Page Type], mOperationResult [Result] FROM operation_history;
SELECT oh.mdate [Operation Date], ohd.operation_id [Operation ID], ohd.src_path [Source Path], ohd.src_file_id [Source File ID], ohd.dst_path [Destination Path], ohd.dst_file_id [Destination File ID], oh.mOperationType [Operation Type], oh.mItemCount [# of Files], oh.mFolderCount [# of Folders], oh.mPageType [Page Type], oh.mOperationResult [Result], oh.mMemoryFullCapacity [Storage Capacity Info] FROM operation_history_data ohd JOIN operation_history oh ON oh._id = ohd.operation_id
operation_history table.After reviewing the code, I concluded that it would be possible to adapt the parser to support newer Android versions as well. I plan to do this in the future, but for now, I want to focus on my analysis of Samsung apps without interrupting the workflow by refactoring an existing parser.
Meaning of the data / Conclusion
The entries in the File Operations History reflect the file operations performed by the Samsung My Files app. They provide a useful overview of what actions were taken on files and folders within the system.
The data is retained for a long period—in my test dataset, I was able to trace operations going back about one and a half years. I did not observe any triggers that would automatically delete entries from the database.
If I decide to move a folder to a new location, I select the folder in the UI and click “Move.” The File Operations History will store an entry for this folder and the move operation—but it will not create entries for each file inside the folder.
However, it may be possible to reconstruct some file-level operations by looking back at earlier entries. For example, if a file was created in that folder 30 minutes before the move and was not subsequently deleted based on entries in the database, you could infer that it was included in the move operation. But I would like to always double check this with additional data if possible in any way.
I have stored my SQL queries for extracting data from the database in my GitHub repository for later use, such as building a parser:
https://github.com/kalink0/useful_scripts/blob/master/sql/Android/Samsung%20Apps/sMyFiles.sql
I also plan to create additional posts on Samsung apps, sharing my findings step by step.
