[DISCUSSION] mcc and mnc qualifiers

[IgorEisberg]

Just curious, is there any reason for this strange formatting of mcc and mnc qualifiers? https://github.com/iBotPeaches/Apktool/blob/master/brut.apktool/apktool-lib/src/main/java/brut/androlib/res/data/ResConfigFlags.java#L179-L201

I mean, looking at the AOSP source code, there's a plain %d formatting for any value other than 0, no leading zeros. https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/content/res/Configuration.java#2512 https://android.googlesource.com/platform/frameworks/base/+/master/libs/androidfw/ResourceTypes.cpp#3370

[iBotPeaches]

There is not - I'm guessing before AOSP source was out - this was the interpretation of how it functions. I might go back and look at the Froyo release to confirm that, but otherwise I don't think there is any Apktool specific reason.

[IgorEisberg]

I dug a bit deeper. This table gives these examples:

mcc310
mcc310-mnc004
mcc208-mnc00

Regarding mcc field: IMSI MCC (Mobile Country Code), corresponding to mcc resource qualifier. 0 if undefined. Regarding mnc field: IMSI MNC (Mobile Network Code), corresponding to mnc resource qualifier. 0 if undefined. Note that the actual MNC may be 0; in order to check for this use the MNC_ZERO symbol.

Which seems to imply that stored value of MNC_ZERO is -mnc0/-mnc00/-mnc000, while stored value of 0 means any/undefined mnc.

Wikipedia says that MCC is always 3-digit, while MNC can be 2-digit (European standard) or 3-digit (North American standard), and an example says "MNC of 001 is not the same as MNC of 01". Which is odd, because the source code I linked you to doesn't make any kind of differentiation when constructing the qualifiers, and both 001 and 01 are stored as 1.

Here's a partial output of aapt2 dump resources framework-res.apk | grep mcc | sort:

      (mcc286-mnc2) true
      (mcc286-mnc2) true
      (mcc286-mnc3) false
      (mcc286-mnc3) true
      (mcc286-mnc3) true
      (mcc295-mnc1) false
      (mcc295-mnc1) true
      (mcc295-mnc1) true
      (mcc302-mnc220) 1410
      (mcc302-mnc220) false
      (mcc302-mnc220) true
      (mcc302-mnc220) true
      (mcc302-mnc221) false
...
      (mcc520-mnc65535) true
      (mcc520-mnc65535) true
      (mcc520-mnc65535) true
      (mcc525-mnc1) false
      (mcc525-mnc1) true
      (mcc525-mnc1) true
      (mcc525-mnc17) 1380
      (mcc525-mnc3) false
      (mcc525-mnc3) false
      (mcc525-mnc3) true
      (mcc525-mnc5) false
      (mcc525-mnc5) false
      (mcc525-mnc5) true
      (mcc530-mnc24) false
      (mcc530-mnc24) false
      (mcc530-mnc24) true
      (mcc530-mnc5) false
      (mcc602-mnc1) false
      (mcc602-mnc1) true
      (mcc602-mnc1) true

1. We can see no leading zeros here at all.
2. It's known that -mnc65535 is -mnc0 (vs. undefined), because 6553==MNC_ZERO, but it's really either -mnc00 or -mnc000 (no way to know, 00 is used in Europe while 000 by One network in Bermuda).
3. For the rest, it's entirely unclear, e.g. does -mnc1 mean -mnc01 or -mnc001 when both are valid?

I'm very confused.

Eventually went with something that looks the best... (mnc doesn't appear without mcc before it, prints mnc as 2-digit or more)

        if (mcc != 0) {
            ret.append("-mcc").append(String.format("%03d", mcc));
            if (mnc != 0) {
                ret.append("-mnc");
                if (mnc != MNC_ZERO) {
                    ret.append(String.format("%02d", mnc));
                } else {
                    ret.append("00");
                }
            }
        }

So looks like this

-mcc001-mnc00
-mcc001-mnc01
...
-mcc001-mnc09
-mcc001-mnc10
-mcc001-mnc11
...
-mcc001-mnc99
-mcc001-mnc100
-mcc001-mnc101

[iBotPeaches]

Did you stumble onto some issue that led you to this? I'm just weary of changing something I haven't touched in a decade.