Fixed
Status Update
No update yet.
Comments
vi...@google.com
Thank you for reporting this issue. For us to further investigate this issue, please provide the following additional information:
Device used -- Device Make, Model, Android OS Version
Apart from Samsung models, are you able to observe the issue on Pixel devices?
Steps to reproduce
Please provide a sample project or apk to reproduce the issue. Also mention the steps to be followed for reproducing the issue with the given sample project or apk.
Frequency
How frequently does this issue occur? (e.g 100% of the time, 10% of the time)
Android full bug report (to be captured after reproducing the issue)
For steps to capture a bug report, please refer:https://developer.android.com/studio/debug/bug-report#bugreportdevice
Screen record of the issue, if possible
Please capture screen record or video of the issue using following steps:
adb shell screenrecord /sdcard/video.mp4
Subsequently use following command to pull the recorded file:
adb pull /sdcard/video.mp4
Attach the file to this issue.
Capture the issue in a screenshot, if possible
Press the volume down and power buttons simultaneously. The image will appear in the picture gallery. Attach the screenshot image to this issue.
Note: Please avoid uploading directly to the issue using attachments. You may upload to google drive and share the folder to android-bugreport@google.com, then share the link here.
Device used -- Device Make, Model, Android OS Version
Apart from Samsung models, are you able to observe the issue on Pixel devices?
Steps to reproduce
Please provide a sample project or apk to reproduce the issue. Also mention the steps to be followed for reproducing the issue with the given sample project or apk.
Frequency
How frequently does this issue occur? (e.g 100% of the time, 10% of the time)
Android full bug report (to be captured after reproducing the issue)
For steps to capture a bug report, please refer:
Screen record of the issue, if possible
Please capture screen record or video of the issue using following steps:
adb shell screenrecord /sdcard/video.mp4
Subsequently use following command to pull the recorded file:
adb pull /sdcard/video.mp4
Attach the file to this issue.
Capture the issue in a screenshot, if possible
Press the volume down and power buttons simultaneously. The image will appear in the picture gallery. Attach the screenshot image to this issue.
Note: Please avoid uploading directly to the issue using attachments. You may upload to google drive and share the folder to android-bugreport@google.com, then share the link here.
iv...@gmail.com
Device used -- Device Make, Model, Android OS Version
-------------------
Android 11/API Level 30 or greater.
All devices that support 5G SA are affected. this is Android OS code that has the bug, not the RIL or any vendor proprietary code.
Yes, it will affect any Android >= 11 phone, including Pixels, if on 5G SA in the right area where network is configured to use particular spectrum.
Steps to reproduce
------------------------------
1. Be on a network registered on 5G SA with a channel that overlaps multiple bands (i.e T-Mobile USA Band n25 in Seattle, WA NR-ARFCN 397970)
2. Instantiate TelephonyManager, call getAllCellInfo()
3. Iterate through all CellInfo objects, look for CellInfoNr
4. From CellInfoNr, call getCellIdentity()
5. From the CellIdentityNr returned from above, call getBands().
Result returned for getBands() is an array with the value "2" in it when it should be "25."
Please note, for this particular network it should be n25, but on others, depending on how they are configured, n2 is correct. That's why a fix most likely needs to involve a way for the RIL to pass the actual band from the baseband, and not to just calculate it via NR-ARFCN.
Frequency
---------------
This happens 100% of the time in the particular use case I gave. If T-Mobile deployed n2 instead of n25, it would be 0%, but that is purely because the code matches in ascending order of NR bands.
Unfortunately, I cannot provide any bug report, as I do not live in the US where this spectrum is used. This was reported to me from users of my application on multiple devices from multiple manufacturers. Likewise, there is nothing really to record, as its purely an API and nothing visual is involved.
-------------------
Android 11/API Level 30 or greater.
All devices that support 5G SA are affected. this is Android OS code that has the bug, not the RIL or any vendor proprietary code.
Yes, it will affect any Android >= 11 phone, including Pixels, if on 5G SA in the right area where network is configured to use particular spectrum.
Steps to reproduce
------------------------------
1. Be on a network registered on 5G SA with a channel that overlaps multiple bands (i.e T-Mobile USA Band n25 in Seattle, WA NR-ARFCN 397970)
2. Instantiate TelephonyManager, call getAllCellInfo()
3. Iterate through all CellInfo objects, look for CellInfoNr
4. From CellInfoNr, call getCellIdentity()
5. From the CellIdentityNr returned from above, call getBands().
Result returned for getBands() is an array with the value "2" in it when it should be "25."
Please note, for this particular network it should be n25, but on others, depending on how they are configured, n2 is correct. That's why a fix most likely needs to involve a way for the RIL to pass the actual band from the baseband, and not to just calculate it via NR-ARFCN.
Frequency
---------------
This happens 100% of the time in the particular use case I gave. If T-Mobile deployed n2 instead of n25, it would be 0%, but that is purely because the code matches in ascending order of NR bands.
Unfortunately, I cannot provide any bug report, as I do not live in the US where this spectrum is used. This was reported to me from users of my application on multiple devices from multiple manufacturers. Likewise, there is nothing really to record, as its purely an API and nothing visual is involved.
vi...@google.com
Thanks for the above information. For further investigation we would need a bugreport, without this we couldn't proceed. Is it possible to share the snippet of erroneous logs?
iv...@gmail.com
I have managed to get a bug report from another phone (Samsung A32 5G - SM-A326W Android 12 build #SP1A.210812.016) in a different area with a network using the same spectrum:
https://drive.google.com/file/d/10tirhnoYXvKT4SapW0hJUxxWtltmFx72/view?usp=sharing
In this case the NR-ARFCN is 387410 which always returns "2" regardless if it is NR band 2 or 25.
In this case the NR-ARFCN is 387410 which always returns "2" regardless if it is NR band 2 or 25.
vi...@google.com
We’ve shared this with our product and engineering teams and will continue to provide updates as more information becomes available.
pe...@gmail.com
Here is another example bug report from Android 13: (Samsung S22 Ultra - SM-S908U Android 13 Build# TP1A.220624.014.S908USQU2ZVJA)
https://drive.google.com/drive/folders/19nx45Dn1KlxoZ1kX2DNlgQMepmVd6peD?usp=sharing
vi...@google.com
The provided logs do not contain modem logs. Apart from the Samsung device, have you observed the bug in the Pixel device? If yes, kindly share the bugrpeort (specific to Pixel device) with the modem logs enabled.
iv...@gmail.com
Yes, I have from user complaints. The code that deals with this is in AOSP (see my first post), it is not device specific. It's an issue of logic in the method I mentioned, which assumes an NR-ARFCN always maps to a single band, which is incorrect for NR.
I will ask some users to see if someone with Pixel can submit a bug report, but it will be the same NR-ARFCN passed to that AOSP method resulting in the same issue.
If it helps, for previous cellid bugs "nharold" used to deal with these, as they are familiar with the 3GPP standard.
I will ask some users to see if someone with Pixel can submit a bug report, but it will be the same NR-ARFCN passed to that AOSP method resulting in the same issue.
If it helps, for previous cellid bugs "nharold" used to deal with these, as they are familiar with the 3GPP standard.
vi...@google.com
It would be extremely helpful if you could provide a bugreport from the Pixel device enabled with modem logs, for further investigation.
vi...@google.com Restricted+
Restricted+
Comment has been deleted.
vi...@google.com
In addition, please confirm the HAL version of the user equipment. We would like to know whether it is 1.5+ or below.
vi...@google.com
Please share the information requested in
iv...@gmail.com
This is from a Pixel 7 Pro on T-Mobile 5g SA n25 I received from a user. I am not sure of HAL version, I assume Pixel 7 being brand new is 1.5+
gl...@gmail.com Restricted
Restricted
ja...@gmail.com
vi...@google.com
Thank you for reporting this issue. The band info is directly from the modem, we recommend you to file a bug with the respective OEM (modem chipset vendor) for tracking.
gl...@gmail.com
This is disappointing considering it seems to impact all 5G-NR devices identically, including Google's own Pixels. Since this is a Google site, perhaps you can direct us where to report a bug with Google for the chipsets that impact the affected Google Pixel 4a, 5, 5a, 6, 6 Pro, 7, and 7 Pro? I spoke with Pixel Support but I am not confident that it will go anywhere, as that channel is for end users, not developers.
iv...@gmail.com
The band is not taken directly from the modem, the ARFCN is, which is valid on all those devices. If the band is taken directly from the modem, then this would not be an issue.
The issue lies in telephony/java/android/telephony/AccessNetworkUtils.java method getOperatingBandForNrarfcn, which assumes a single ARFCN maps to a single band, which is not correct. This is part of AOSP and is vendor neutral. However, the fix isn't just modifying the code, but I imagine finding a way to pass the band from the baseband to Android, which currently does not exist.
The issue lies in telephony/java/android/telephony/AccessNetworkUtils.java method getOperatingBandForNrarfcn, which assumes a single ARFCN maps to a single band, which is not correct. This is part of AOSP and is vendor neutral. However, the fix isn't just modifying the code, but I imagine finding a way to pass the band from the baseband to Android, which currently does not exist.
vi...@google.com
vi...@google.com
Re-
The band information in CellIdentityNr is always from RIL/modem. This is applicable to Pixel and non-Pixel devices.
However, it is quite possible that some modem vendors choose not to expose the band information in CellIdentityNr, and that's their own decision.
Our development team has fixed the issue you have reported and the fix has already been released in Android latest version for Pixel 7, 7 Pro, and 7a models. On those devices, we verified CellIdentityNr has the correct band information.
vi...@google.com
gl...@gmail.com
This does not appear to have actually been fixed. Same issues continue to persist on Pixel 7, Pixel 8, and other devices running Android 14.
gl...@gmail.com
This issue continues to persist in Android 15. It has not been resolved.
da...@gmail.com
This is not fixed. Multiple devices running on Android 14 have this bug.
gl...@gmail.com
This bug continues to persist; it negatively impacts Google Pixel 7, 8, 9, and non-Google 5G devices.
da...@gmail.com
I have examined this on a Samsung Galaxy S25 Ultra and a Google Pixel 8a running Android 16 Beta 2 as well.
Description
CellIdentityNr - getBands() returns incorrect data when an NR-ARFCN maps to multiple bands.
Details:
When this method was developed, the logic it used was partially incorrect. The logic simply looks for a match of the NR-ARFCN to a band, and returns the first result. This logic did work for CellIdentityLte, as a EARFCN maps directly to a single band. However, with NR, an NR-ARFCN can map to multiple bands. The band returned should be the actual band retrieved from the baseband.
This is not device or vendor specific, but a core Android bug in master/telephony/java/android/telephony/AccessNetworkUtils.java method getOperatingBandForNrarfcn.
Example wrong data (Galaxy S22 - samsung SM-S908U Android 13 build TP1A.220624.014 on T-Mobile USA):
class java.lang.String toString() = CellIdentityNr:{ mPci = **5 mTac = 2****24 mNrArfcn = 397970 mBands = [2] mMcc = 310 mMnc = 260 mNci = 7*******26 mAlphaLong = T-Mobile mAlphaShort = T-Mobile mAdditionalPlmns = {} }
In this case, the band is returned as "2" when it should be "25," because NR-ARFCN 397970 maps to both bands, but the network is specifically configured for n25 as per SIB 1 broadcast.
Reproduction steps:
You need to be on a network which uses an overlapping NR-ARFCN and call CellIdentityNr.getBands().
However, to reproduce this locally, call AccessNetworkUtils.java.getOperatingBandForNrarfcn(397970).
Expected behaviour:
The band returns should be queried baseband from the Radio Interface Layer (RIL) to get the actual band used. Perhaps for fallback call getOperatingBandForNrarfcn as a last resort.