PhoneStateListener - what can I expect from onCellInfoChanged?

Question

I posted this on Android dev group. I'm hoping I can get some feedback here.

The PhoneStateListener's callbacks onCellLocationChanged and onSignalStrengthsChanged were the goto methods for when I wanted to handle cell and signal data changes in GSM and CDMA. With API 17+, I can see that there's a new callback (onCellInfoChanged) for handling both cell and signal changes.

Looking at the documentation, it's not clear what I can expect from the introduction of this new callback.

Will LTE changes always and only trigger onCellInfoChanged?
Will GSM/CDMA changed remain on the older callbacks?
Does one overlap with the other? (i.e. Both old and new get triggered for LTE or GSM/CDMA.)

It may very well be that different OEMs will have different implementations (sigh!), but I'm hoping there are guidelines that everyone's supposed to follow.

Can anyone shed some light on this?

Thanks, Sebouh

score 0 · Answer 1 · answered Jan 28 '14 at 08:05

I didn't test if but it looks from the code that both will be called.

I downloaded code source of Android 4.3(API 18) using the SDK Manager. The following observations made me think that both would be called. The class that triggers these events is: com.android.server.TelephonyRegistry

It notifies the listener though:

public void listen(String pkgForDebug, IPhoneStateListener callback, int events, boolean notifyNow)

This same function calls for both type of notifications(Location and CellInfo) in a non exclusive way.

On line 256:

if (validateEventsAndUserLocked(r, PhoneStateListener.LISTEN_CELL_LOCATION)) {
    try {
             if (DBG_LOC) Slog.d(TAG, "listen: mCellLocation=" + mCellLocation);
             r.callback.onCellLocationChanged(new Bundle(mCellLocation));
        } catch (RemoteException ex) {
             remove(r.binder);
        }
    }

This one will call onCellLocationChanged even on new LTE phone since there is nothing from the above code that would prevent this. This needs double checking that there is no upper layer that filters the events themselves

On line 300 in the same code:

if (validateEventsAndUserLocked(r, PhoneStateListener.LISTEN_CELL_INFO)) {
     try {
         if (DBG_LOC) Slog.d(TAG, "listen: mCellInfo=" + mCellInfo);
          r.callback.onCellInfoChanged(mCellInfo);
     } catch (RemoteException ex) {
          remove(r.binder);
     }
}

There are other things from the code that look like CDMA will be calling the newer API. For example com.android.internal.telephony.cdma.CdmaLteServiceStateTracker seems to be dealing with CDMA and LTE. Again it would require a more careful look but that should give you a good place to start. You can also try to simulate that with the emulator.

Thanks for digging around. I tested this on LG G2 and it looks like the onCellInfoChanged never gets called. I'm gonna test again to see if I can access the LTE cell info via TelephonyManager.getAllCellInfo() in the old callbacks. Also, I read in the documentation that OEMs should not use GSM/CDMA objects to represent LTE cell info (there's no LteCellLocation obj), so that should rule out onCellLocationChanged. I can't remember where I saw this though. — black, Feb 01 '14 at 18:55
On LG G2 (running 4.2), LTE data is accessible via TelephonyManager.getAllCellInfo, but no calls to onCellInfoChanged are made. I can access this info when onSignalStrengthsChanged is called. — black, Feb 05 '14 at 18:38

PhoneStateListener - what can I expect from onCellInfoChanged?

1 Answers1