Obsolete
Status Update
Comments
co...@gmail.com <co...@gmail.com> #2
Can you provide the below requested information to better understand the issue:
Can you please test with latest library and update result here.
https://developer.android.com/topic/libraries/support-library/revisions.html
If possible please provide a complete sample application.
Expected output
What do you expect to occur?
Current output
What do you see instead?
Can you please test with latest library and update result here.
If possible please provide a complete sample application.
Expected output
What do you expect to occur?
Current output
What do you see instead?
ch...@gmail.com <ch...@gmail.com> #3
This seems to be intended according to https://issuetracker.google.com/74278849 , the suggestion is to remove the extra logic to deliverResult() in onStartLoading().
[Deleted User] <[Deleted User]> #4
@gg..@google.com
Sample project is attached.
Steps to test:
1. Import, build and install apk
2. Notice "Number of 'onLoadFinished' calls: 1"
3. Click "Click me!" button to start Second Activity
4. Notice "Number of 'onLoadFinished' calls: 2"
EXPECTED: At stap 4 "Number of 'onLoadFinished' calls" should be 1.
ACTUAL: It's 2.
@ha...@gmail.com
That's not the solution because developers are not in control of all Loaders. For example CursorLoader from support libaray should be then fixed by google, not by developers.
And this is behavior change which is not documented, so suggestion on issuetracker is not good enough.
Sample project is attached.
Steps to test:
1. Import, build and install apk
2. Notice "Number of 'onLoadFinished' calls: 1"
3. Click "Click me!" button to start Second Activity
4. Notice "Number of 'onLoadFinished' calls: 2"
EXPECTED: At stap 4 "Number of 'onLoadFinished' calls" should be 1.
ACTUAL: It's 2.
@ha...@gmail.com
That's not the solution because developers are not in control of all Loaders. For example CursorLoader from support libaray should be then fixed by google, not by developers.
And this is behavior change which is not documented, so suggestion on issuetracker is not good enough.
am...@google.com <am...@google.com> #5
We have shared this with our engineering team and will update this issue with more information as it becomes available.
vs...@gmail.com <vs...@gmail.com> #6
Do you have any news ?
pe...@gmail.com <pe...@gmail.com> #7
@6 I think they changed the way it works, without much information about the change.
Try this solution I've written about (read the last part of the text too, as it talks about the changes) :
https://stackoverflow.com/a/22675607/878126
Try this solution I've written about (read the last part of the text too, as it talks about the changes) :
de...@awox.com <de...@awox.com> #8
@7 Thank you for your information. I still get the error when orientation change
de...@awox.com <de...@awox.com> #9
@8 I can't confirm. It works fine without any error .
Attached sample project, that "loads" content, and after 5 seconds returns a result, that will be returned on the current Activity.
Attached sample project, that "loads" content, and after 5 seconds returns a result, that will be returned on the current Activity.
ra...@gmail.com <ra...@gmail.com> #10
OK I'll check it again. Thx a lot!
bo...@gmail.com <bo...@gmail.com> #11
@9 Hello man, when orientation change the "onLoaderFinished" method, called again. Do you know how to stop calling this method?
em...@gmail.com <em...@gmail.com> #12
@11 It is called only once after onCreate is called, just as intended.
The reason is that after you load something, you wish to use it. After orientation change, all is destroyed, but the result is still available, so you can use it.
If you don't want to use the result, either ignore it, or check whether the loader (if existing) has a result or not.
But this loses the whole point of using a loader. By using a loader, you are supposed to use its result, even after an orientation change.
The reason is that after you load something, you wish to use it. After orientation change, all is destroyed, but the result is still available, so you can use it.
If you don't want to use the result, either ignore it, or check whether the loader (if existing) has a result or not.
But this loses the whole point of using a loader. By using a loader, you are supposed to use its result, even after an orientation change.
sa...@google.com <sa...@google.com> #13
We will be closing this bug as Obsolete. If you still think this issue is reproducible and relevant in the latest Android release (Android Q), please attach a new bug report along with reproduction details. If a reply is not received within the next 14 days, this issue will be closed. Thank you for your understanding.
ad...@google.com <ad...@google.com> #14
Thank you for your feedback. We assure you that we are doing our best to address all issues reported. For now, we will be closing the issue as won't fix obsolete.
If this issue currently still exists, we request that you log a new issue along with the bug report herehttps://goo.gl/TbMiIO and reference this bug for context.
If this issue currently still exists, we request that you log a new issue along with the bug report here
Description
DESCRIPTION
When using BLE and from an Android app is first disconnecting and then closing a BluetoothGatt instance a NullPointerException can happen in BluetoothGatt.java.
It seems like the issue is that the mCallback is set to null before removing/unregistering the callback. This means that the GattService still thinks the callback is available when calling e.g. onConnectionStateChange which uses the mCallback instance.
REPRODUCABILITY
This issue has been seen (100% reproducable) on a Nexus 9 with Android 5.0.1 with an app that communicates with a BLE device. I have maybe seen it on other devices but right now I have not been able to reproduce it on my Xperia devices. Probably because this issue is timing dependent. (There are big time differences between e.g. a Nexus 9 and a Xperia Z3 when handling BLE).
APP CODE SNIPPET:
private BluetoothGatt mGatt;
...
void disconnectAndClose() {
...
mGatt.disconnect();
mGatt.close();
...
}
When invoking disconnectAndClose() on a connected device, the following is seen in the log:
08-17 12:23:13.500 3390-3418/com.sonymobile.hostapp.everest D/BluetoothGatt﹕ cancelOpen() - device: ab:ab:ab:ab:ab:ab
08-17 12:23:13.502 3390-3418/com.sonymobile.hostapp.everest D/BluetoothGatt﹕ close()
08-17 12:23:13.502 3390-3418/com.sonymobile.hostapp.everest D/BluetoothGatt﹕ unregisterApp() - mClientIf=5 [removes mCallback needed at BluetoothGatt.java:181]
08-17 12:23:13.504 3390-3450/com.sonymobile.hostapp.everest D/BluetoothGatt﹕ onClientConnectionState() - status=0 clientIf=5 device=ab:ab:ab:ab:ab:ab
08-17 12:23:13.506 3390-3450/com.sonymobile.hostapp.everest W/BluetoothGatt﹕ Unhandled exception in callback
java.lang.NullPointerException: Attempt to invoke virtual method 'void android.bluetooth.BluetoothGattCallback.onConnectionStateChange(android.bluetooth.BluetoothGatt, int, int)' on a null object reference
at android.bluetooth.BluetoothGatt$1.onClientConnectionState(BluetoothGatt.java:181)
at android.bluetooth.IBluetoothGattCallback$Stub.onTransact(IBluetoothGattCallback.java:70)
at android.os.Binder.execTransact(Binder.java:446)
AFFECTED ANDROID CODE (BluetoothGatt.java):
/**
* Unregister the current application and callbacks.
*/
private void unregisterApp() {
if (DBG) Log.d(TAG, "unregisterApp() - mClientIf=" + mClientIf);
if (mService == null || mClientIf == 0) return;
try {
mCallback = null;
/* ISSUE COMMENT: If a onConnectionStateChange happens here a NullPointerException will be thrown. */
mService.unregisterClient(mClientIf);
mClientIf = 0;
} catch (RemoteException e) {
Log.e(TAG,"",e);
}
}