Return to Answer

exFAT has been natively supported since A13:

1. Why not earlier?

   In August of 2019, Microsoft published the technical specification for exFAT and endorsed its addition to the Linux kernel. While Microsoft still holds patents on exFAT, its announcement means that the thousands of members of the free-to-join Open Invention Network — of which Microsoft is a part of — can freely use the technology in their Linux-based products as it’s covered under the OIN’s Linux System definition.

   Immediately following Microsoft’s announcement, an old version of Samsung’s exFAT Linux driver that was in legal limbo for years was submitted to the staging area of Linux 5.4. Many kernel maintainers were unhappy with the code quality of the old driver, however, so several alternative implementations started to pop up, one of which was from Paragon Software. Eventually, though, the Linux kernel community settled on a newer exFAT driver developed by Samsung, the same one they’ve been shipping on their own products already. Samsung’s implementation of Microsoft’s exFAT officially landed in Linux 5.7.

2. How?

   With a Microsoft-endorsed exFAT driver finally available in the upstream Linux kernel, shipping exFAT support in Android became a lot less complicated for Google and OEMs. Since an Android Common Kernel fork of Linux kernel 5.7 doesn’t exist, the first ACK branch to include the new exFAT driver was based on Linux 5.10, hence the line mentioned at the beginning of the article about exFAT being supported in kernel 5.10 and later. CONFIG_EXFAT_FS has been set in GKI builds for over a year now, including kernels based on the android12-5.10 branch, which is why the kernel on my Pixel 6 Pro running Android 12L reports support for exFAT. However, there’s one missing piece of the puzzle to actually get Android to mount exFAT drives, and it involves Vold.

   Vold is short for “volume daemon”, and it’s the service that handles the mounting and unmounting of storage media. Vold actually added basic support for exFAT all the way back in early 2018, provided it detects that the kernel supports it and “helper binaries” are present. Those “helper binaries” are mkfs.exfat and fsck.exfat, tools that respectively build and check the consistency of exFAT file systems. They’re included as part of exfatprogs, a set of userspace utilities for creating, fixing, and debugging exFAT file systems. If those helper binaries aren’t detected, then the file system check will fail, and the volume won’t be mounted.

3. Why not A12?

   If you haven’t guessed by now, those helper binaries aren’t present in any stable Android 12L builds for the Pixel 6 Pro, but they are present in the Android 13 beta builds.

   

   The Android Platform Manifest, which Google’s repo tool uses to find the various repositories in AOSP when checking out a specific branch, added external/exfatprogs to the default manifest in the AOSP master branch last year. This means that anyone checking out the AOSP master branch during their build process will have included the necessary helper binaries to pass vold’s file system check for exFAT. The default manifest in the android-12.1.0_r8 branch, however, does not pull external/exfatprogs, so those builds will lack the helper binaries.

As this article explains, exFAT has been natively supported since Android 13:

Why not earlier?

In August of 2019, Microsoft published the technical specification for exFAT and endorsed its addition to the Linux kernel. While Microsoft still holds patents on exFAT, its announcement means that the thousands of members of the free-to-join Open Invention Network — of which Microsoft is a part of — can freely use the technology in their Linux-based products as it’s covered under the OIN’s Linux System definition.

Immediately following Microsoft’s announcement, an old version of Samsung’s exFAT Linux driver that was in legal limbo for years was submitted to the staging area of Linux 5.4. Many kernel maintainers were unhappy with the code quality of the old driver, however, so several alternative implementations started to pop up, one of which was from Paragon Software. Eventually, though, the Linux kernel community settled on a newer exFAT driver developed by Samsung, the same one they’ve been shipping on their own products already. Samsung’s implementation of Microsoft’s exFAT officially landed in Linux 5.7.

How?

With a Microsoft-endorsed exFAT driver finally available in the upstream Linux kernel, shipping exFAT support in Android became a lot less complicated for Google and OEMs. Since an Android Common Kernel fork of Linux kernel 5.7 doesn’t exist, the first ACK branch to include the new exFAT driver was based on Linux 5.10, hence the line mentioned at the beginning of the article about exFAT being supported in kernel 5.10 and later. CONFIG_EXFAT_FS has been set in GKI builds for over a year now, including kernels based on the android12-5.10 branch, which is why the kernel on my Pixel 6 Pro running Android 12L reports support for exFAT. However, there’s one missing piece of the puzzle to actually get Android to mount exFAT drives, and it involves Vold.

Vold is short for “volume daemon”, and it’s the service that handles the mounting and unmounting of storage media. Vold actually added basic support for exFAT all the way back in early 2018, provided it detects that the kernel supports it and “helper binaries” are present. Those “helper binaries” are mkfs.exfat and fsck.exfat, tools that respectively build and check the consistency of exFAT file systems. They’re included as part of exfatprogs, a set of userspace utilities for creating, fixing, and debugging exFAT file systems. If those helper binaries aren’t detected, then the file system check will fail, and the volume won’t be mounted.

Why not A12?

If you haven’t guessed by now, those helper binaries aren’t present in any stable Android 12L builds for the Pixel 6 Pro, but they are present in the Android 13 beta builds.

The Android Platform Manifest, which Google’s repo tool uses to find the various repositories in AOSP when checking out a specific branch, added external/exfatprogs to the default manifest in the AOSP master branch last year. This means that anyone checking out the AOSP master branch during their build process will have included the necessary helper binaries to pass vold’s file system check for exFAT. The default manifest in the android-12.1.0_r8 branch, however, does not pull external/exfatprogs, so those builds will lack the helper binaries.

exFAT has been natively supported since A13.

Why not earlier?

In August of 2019, Microsoft published the technical specification for exFAT and endorsed its addition to the Linux kernel. While Microsoft still holds patents on exFAT, its announcement means that the thousands of members of the free-to-join Open Invention Network — of which Microsoft is a part of — can freely use the technology in their Linux-based products as it’s covered under the OIN’s Linux System definition.

Immediately following Microsoft’s announcement, an old version of Samsung’s exFAT Linux driver that was in legal limbo for years was submitted to the staging area of Linux 5.4. Many kernel maintainers were unhappy with the code quality of the old driver, however, so several alternative implementations started to pop up, one of which was from Paragon Software. Eventually, though, the Linux kernel community settled on a newer exFAT driver developed by Samsung, the same one they’ve been shipping on their own products already. Samsung’s implementation of Microsoft’s exFAT officially landed in Linux 5.7.

How?

With a Microsoft-endorsed exFAT driver finally available in the upstream Linux kernel, shipping exFAT support in Android became a lot less complicated for Google and OEMs. Since an Android Common Kernel fork of Linux kernel 5.7 doesn’t exist, the first ACK branch to include the new exFAT driver was based on Linux 5.10, hence the line mentioned at the beginning of the article about exFAT being supported in kernel 5.10 and later. CONFIG_EXFAT_FS has been set in GKI builds for over a year now, including kernels based on the android12-5.10 branch, which is why the kernel on my Pixel 6 Pro running Android 12L reports support for exFAT. However, there’s one missing piece of the puzzle to actually get Android to mount exFAT drives, and it involves vold.

Vold is short for “volume daemon”, and it’s the service that handles the mounting and unmounting of storage media. Vold actually added basic support for exFAT all the way back in early 2018, provided it detects that the kernel supports it and “helper binaries” are present. Those “helper binaries” are mkfs.exfat and fsck.exfat, tools that respectively build and check the consistency of exFAT file systems. They’re included as part of exfatprogs, a set of userspace utilities for creating, fixing, and debugging exFAT file systems. If those helper binaries aren’t detected, then the file system check will fail, and the volume won’t be mounted.

Why not A12?

If you haven’t guessed by now, those helper binaries aren’t present in any stable Android 12L builds for the Pixel 6 Pro, but they are present in the Android 13 beta builds.

The Android Platform Manifest, which Google’s repo tool uses to find the various repositories in AOSP when checking out a specific branch, added external/exfatprogs to the default manifest in the AOSP master branch last year. This means that anyone checking out the AOSP master branch during their build process will have included the necessary helper binaries to pass vold’s file system check for exFAT. The default manifest in the android-12.1.0_r8 branch, however, does not pull external/exfatprogs, so those builds will lack the helper binaries.

exFAT has been natively supported since A13:

1. Why not earlier?

   In August of 2019, Microsoft published the technical specification for exFAT and endorsed its addition to the Linux kernel. While Microsoft still holds patents on exFAT, its announcement means that the thousands of members of the free-to-join Open Invention Network — of which Microsoft is a part of — can freely use the technology in their Linux-based products as it’s covered under the OIN’s Linux System definition.

   Immediately following Microsoft’s announcement, an old version of Samsung’s exFAT Linux driver that was in legal limbo for years was submitted to the staging area of Linux 5.4. Many kernel maintainers were unhappy with the code quality of the old driver, however, so several alternative implementations started to pop up, one of which was from Paragon Software. Eventually, though, the Linux kernel community settled on a newer exFAT driver developed by Samsung, the same one they’ve been shipping on their own products already. Samsung’s implementation of Microsoft’s exFAT officially landed in Linux 5.7.

2. How?

   With a Microsoft-endorsed exFAT driver finally available in the upstream Linux kernel, shipping exFAT support in Android became a lot less complicated for Google and OEMs. Since an Android Common Kernel fork of Linux kernel 5.7 doesn’t exist, the first ACK branch to include the new exFAT driver was based on Linux 5.10, hence the line mentioned at the beginning of the article about exFAT being supported in kernel 5.10 and later. CONFIG_EXFAT_FS has been set in GKI builds for over a year now, including kernels based on the android12-5.10 branch, which is why the kernel on my Pixel 6 Pro running Android 12L reports support for exFAT. However, there’s one missing piece of the puzzle to actually get Android to mount exFAT drives, and it involves Vold.

   Vold is short for “volume daemon”, and it’s the service that handles the mounting and unmounting of storage media. Vold actually added basic support for exFAT all the way back in early 2018, provided it detects that the kernel supports it and “helper binaries” are present. Those “helper binaries” are mkfs.exfat and fsck.exfat, tools that respectively build and check the consistency of exFAT file systems. They’re included as part of exfatprogs, a set of userspace utilities for creating, fixing, and debugging exFAT file systems. If those helper binaries aren’t detected, then the file system check will fail, and the volume won’t be mounted.

3. Why not A12?

   If you haven’t guessed by now, those helper binaries aren’t present in any stable Android 12L builds for the Pixel 6 Pro, but they are present in the Android 13 beta builds.

   

   The Android Platform Manifest, which Google’s repo tool uses to find the various repositories in AOSP when checking out a specific branch, added external/exfatprogs to the default manifest in the AOSP master branch last year. This means that anyone checking out the AOSP master branch during their build process will have included the necessary helper binaries to pass vold’s file system check for exFAT. The default manifest in the android-12.1.0_r8 branch, however, does not pull external/exfatprogs, so those builds will lack the helper binaries.

exFAT is natively supported starting with Android 13. Source: Real Mi Central

exFAT has been natively supported since A13.

Why not earlier?

In August of 2019, Microsoft published the technical specification for exFAT and endorsed its addition to the Linux kernel. While Microsoft still holds patents on exFAT, its announcement means that the thousands of members of the free-to-join Open Invention Network — of which Microsoft is a part of — can freely use the technology in their Linux-based products as it’s covered under the OIN’s Linux System definition.

Immediately following Microsoft’s announcement, an old version of Samsung’s exFAT Linux driver that was in legal limbo for years was submitted to the staging area of Linux 5.4. Many kernel maintainers were unhappy with the code quality of the old driver, however, so several alternative implementations started to pop up, one of which was from Paragon Software. Eventually, though, the Linux kernel community settled on a newer exFAT driver developed by Samsung, the same one they’ve been shipping on their own products already. Samsung’s implementation of Microsoft’s exFAT officially landed in Linux 5.7.

How?

With a Microsoft-endorsed exFAT driver finally available in the upstream Linux kernel, shipping exFAT support in Android became a lot less complicated for Google and OEMs. Since an Android Common Kernel fork of Linux kernel 5.7 doesn’t exist, the first ACK branch to include the new exFAT driver was based on Linux 5.10, hence the line mentioned at the beginning of the article about exFAT being supported in kernel 5.10 and later. CONFIG_EXFAT_FS has been set in GKI builds for over a year now, including kernels based on the android12-5.10 branch, which is why the kernel on my Pixel 6 Pro running Android 12L reports support for exFAT. However, there’s one missing piece of the puzzle to actually get Android to mount exFAT drives, and it involves vold.

Vold is short for “volume daemon”, and it’s the service that handles the mounting and unmounting of storage media. Vold actually added basic support for exFAT all the way back in early 2018, provided it detects that the kernel supports it and “helper binaries” are present. Those “helper binaries” are mkfs.exfat and fsck.exfat, tools that respectively build and check the consistency of exFAT file systems. They’re included as part of exfatprogs, a set of userspace utilities for creating, fixing, and debugging exFAT file systems. If those helper binaries aren’t detected, then the file system check will fail, and the volume won’t be mounted.

Why not A12?

If you haven’t guessed by now, those helper binaries aren’t present in any stable Android 12L builds for the Pixel 6 Pro, but they are present in the Android 13 beta builds.

The Android Platform Manifest, which Google’s repo tool uses to find the various repositories in AOSP when checking out a specific branch, added external/exfatprogs to the default manifest in the AOSP master branch last year. This means that anyone checking out the AOSP master branch during their build process will have included the necessary helper binaries to pass vold’s file system check for exFAT. The default manifest in the android-12.1.0_r8 branch, however, does not pull external/exfatprogs, so those builds will lack the helper binaries.