Android 8 uses stackable file sytem called sdcardfs, which emulates FAT32 on ext4 on the data partition. Does sdcardfs recognize the ext4 file system and journaling?
In other words, files written using sdcardfs has journal history information created?
On Android 8 it's not clear how the journaling works e.g. can it be used to recover data? Is the new data written to empty fresh areas or first the deleted areas are used?
Does Android 8 has journaling enabled in its
ext4files system?
It depends on a few factors. OEMs can possibly disable journaling e.g. on system partition as it's always supposed to be used R/O. These days ext4 and f2fs are commonly used filesystems on Android, so first make sure you have ext4 on userdata partition. f2fs is by-origin a log-structured filesystem which is a circular buffer, that's what a journal is but the functionality differs.
Filesystems are part of Linux kernel, not Android (AOSP) itself. ext4 by default is created with journal, though it depends on mke2fs.conf, and can be disabled with mke2fs or tune2fs option -O ^has_journal. Journaling support can be checked from filesystem features by executing tune2fs -l /dev/block/bootdevice/by-name/userdata | grep has_journal (or use dm-0 block device if userdata has FDE) but it requires root. As alternate if mount | grep 'on /data' shows data={journal|ordered|writeback} option then journal is enabled for sure.
Does
sdcardfsrecognize theext4file system and journaling?
sdcardfs itself doesn't have a journal, but since emulated filesystem is stacked over /data/media (which is ext4), the files created through sdcardfs are recorded in underlying filesystem's journal.
On Android 8 it's not clear how the
journalingworks e.g. can it be used to recover data?
Yes definitely, if you have root already and the data isn't overwritten. We have tools like extundelete which are very effective. But do consider factors like TRIM and others described below and in given links.
Is the new data written to empty fresh areas or first the deleted areas are used?
Well that's a different question, again it has nothing to do with Android. The question is how often a filesystem overwrites deleted data blocks and it's not simple to answer. Create a new ext4 filesystem, create a file foo inside it and delete it. Create new file bar and it will take the inode block and data blocks freed by foo. Delete bar and create file baz, it will occupy the same space. However in actual things are complicated. Will the data blocks of deleted file be immediately overwritten or not depends on whats the size of new file is, how much fragmented your filesystem is, how much free LBAs you have before the logical location of deleted file etc.
PS:
Things are different on f2fs, it's the Flash Friendly FileSystem, so as a wear-leveling strategy it preferably writes data to new empty blocks (free segments), so that FTL doesn't have to Erase cells, trying to reduce the E/P counts on flash memory. Later it does background garbage collection (GC) synchronized with FTL to release LBAs corresponding to deleted data. But the tools like debugfs aren't readily available for f2fs to explore deleted inodes and to lookup corresponding data blocks from journal. So from data recovery's view, f2fs isn't very friendly (AFAIK and experienced).
RELATED: What Makes Recovery of Deleted Data Difficult / Impossible?