Assigned
Status Update
Comments
bl...@google.com <bl...@google.com> #2
This was reported eight months ago. Is this going to be fixed anytime soon?
LTE cell measurements seem to be officially supported only via this interface (i.e. the old TelephonyManager.getCellLocation() can not be used for LTE since it is specified to return null when in LTE network). Thus it is important that this new interface works!
LTE cell measurements seem to be officially supported only via this interface (i.e. the old TelephonyManager.getCellLocation() can not be used for LTE since it is specified to return null when in LTE network). Thus it is important that this new interface works!
ka...@gmail.com <ka...@gmail.com> #3
Just tested this on Nexus 4 with Android 4.3. onCellInfoChanged is called with null parameter.
ma...@google.com <ma...@google.com> #4
How can we raise the priority of this issue? This should be fixed as soon as possible to give android a usable telephony API!
/ Kenneth
/ Kenneth
qu...@getalma.com <qu...@getalma.com> #5
Hi, same thing in Nexus 7 (ME571-LTE). Tell ASUS to fix the problem. Galaxy S4 works just fine.
ma...@google.com <ma...@google.com> #6
The reason the bug is here (and not on some ASUS forum) is that (in theory) Google has a compatibility test suite that tests the public API, and won't provide the Google apps (like Google Play) if the device fails that test (and you'd hope that their flagship device, the Nexus 4 would implement their documented public API.)
If there were an alternate public API that provided the LTE info, or the Google developer devices implemented the public API as documented and some OEM blew it, it wouldn't matter so much.
While fixing this on individual devices is good, what really needs to happen in addition to that, is an update to the CTS to test CellInfo and actually require that devices pass that part of the CTS and implement the API before getting the Google apps.
If there were an alternate public API that provided the LTE info, or the Google developer devices implemented the public API as documented and some OEM blew it, it wouldn't matter so much.
While fixing this on individual devices is good, what really needs to happen in addition to that, is an update to the CTS to test CellInfo and actually require that devices pass that part of the CTS and implement the API before getting the Google apps.
vm...@hemetusd.org <vm...@hemetusd.org> #7
I tried below work around and it looks working
1. list to LISTEN_SIGNAL_STRENGTHS event telephonyManager.listen(phoneCallsListener,PhoneStateListener.LISTEN_SIGNAL_STRENGTHS)
2. onSignalStrengthsChanged call telephonyManager.getAllCellInfo(). Returns values are not null. But I am not sure that returned values are correct or not yet.
1. list to LISTEN_SIGNAL_STRENGTHS event telephonyManager.listen(phoneCallsListener,PhoneStateListener.LISTEN_SIGNAL_STRENGTHS)
2. onSignalStrengthsChanged call telephonyManager.getAllCellInfo(). Returns values are not null. But I am not sure that returned values are correct or not yet.
fi...@gymkk.cz <fi...@gymkk.cz> #8
I've noticed something quite strange on the Nexus 5 (4.4). On Sprint LTE, it will return data for this. However, for a 3G provider (haven't tried LTE), it will return null.
34...@gmail.com <34...@gmail.com> #9
[Comment deleted]
ap...@ne-academy.net <ap...@ne-academy.net> #11
Why is this obsolete ? Is this method obsolete in the API ?
Description
Before opening a new issue, please search for other related issues , click the ★ to subscribe to updates, and click
+1
to vote.Description
The Submission History field is a logical place to look for this information, but it does not have an EXCUSED type. Upon excusing a submission, the corresponding
gradeChangeType
isDRAFT_GRADE_POINTS_EARNED_CHANGE
, which is also impossible to distinguish from real draft grade changes.Impact
Any programs that use this API to get a snapshot of a students' grades will be unable to determine if a submission is excused or if it's a grade of 0.