The entire block is only executed, if TARGET_USES_QCA_NFC equals true. However, in above line the variable is set to other. This means the entire block you posted is not evaluated.
Edit: To extend my answer and give some background:
AOSP source tree includes essentially everything that is necessary to use any feature of Android. With configuration files for each device, one can choose and pick what is enabled based on device hardware and capabilities. Of course, AOSP also includes support for NFC. Only for FP2 this is not enabled.
The same is also true for any features Qualcomm adds (the QCA in the variable name suggests, this is a Qualcomm feature): Qualcomm adds code for all kind of features supported by its chips. It is up to the phone manufacturer to select those that make sense for their device. In this case, TARGET_USES_QCA_NFC is disabled for obvious reasons
Ah, maybe I missed the point of your question. Did you rather ask why the entire block is even included in “FP2.mk”?
I don’t know about the specifics (I am working on FP1 after all), but my guess is that the makefile for FP2 was created by copying a template provided by Qualcomm and change it where necessary. The minimal change to disable NFC is to set this variable to anything not equal to true. Of course, just keeping the line TARGET_USES_QCA_NFC := other and removing the entire ifeq block would lead to the same result.
Edit: If you port to CM by starting with a template from CM and copy over everything you need from FP2.mk, then do not include the block. You probably do not even need the TARGET_USES_QCA_NFC := other, however I cannot say the latter with 100% certainty.
I completely overlook that conditional! Even with its content indented,
It confounded me the other value. Why not just false? Hahaha, . Semantically, other could mean “I’ll configure this on my own” (e.g. with another package on the device config plus the respective hardware subfolder). Makefile “language” has its limitations… hahaha. (Not an issue, just my little-but-growing knowledge about GNUMake)
Yes, we are rewriting the device configs from scratch (i.e. from the succinct base CM provides). That approach has the advantage of allow us to learn one step at a time. We’ll inform you!
But there could be a new back cover in the future which enables NFC on the Fairphone 2. (Well, the NFC hardware is brought by the back cover in this case.)
Well, the hardware is in fact modular, but Android isn’t…
I don’t know how difficult could be make Android detect hardware at runtime to enable hardware-dependent features (like NFC), but I doubt is easy and I doubt we’ll see it in the FP2.
Anyway, that’s another topic to discuss on other forumcategory and this one already came to its end,