-
-
Notifications
You must be signed in to change notification settings - Fork 6.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Android] Network: fix after "Listen to default network changes" #23313
Conversation
It's strange, the constructor registers the Later, the first call to |
This "immediately" is not atomic. Therefore a timespan exists where this ptrs is null. |
The problem is that there are calls to With the code proposed by @thexai it's fixed, later on we will have to see these calls and if it makes sense to get all the interfaces. |
There are at least two problems:
Only is called when network changes, then |
@@ -279,7 +279,7 @@ CNetworkInterface* CNetworkAndroid::GetFirstConnectedInterface() | |||
{ | |||
std::unique_lock<CCriticalSection> lock(m_refreshMutex); | |||
|
|||
if (CJNIBase::GetSDKVersion() >= 24) | |||
if (CJNIBase::GetSDKVersion() >= 24 && m_defaultInterface) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This condition can be simplified to:
if (m_defaultInterface)
because in SDK < 24 guarantees that m_defaultInterface
never is initialized then is redundant check SDK here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, more simple
Startup log in Android Emulator and the same in FireTV:
|
This error message appears when we activate the Web server and occurs because Regardless of this, the device should have network connectivity (see System Info > Network) and I'm fine with the fix, go ahead 👍 |
Description
Network: fix after "Listen to default network changes"
Motivation and context
On Shield, at least, #23059 has broken the network because
m_defaultInterface
can be nullptr in some cases:Callbacks only are received after network changes (lost, recovered, new) but not when app starts. This PR enables fallback to old enumeration method when
m_defaultInterface
is not yet initialized.How has this been tested?
Runtime tested Shield 2019
What is the effect on users?
Fix network not usable. The first symptom is that the web server for remote control fails to initialize when Kodi starts up.
Screenshots (if appropriate):
Types of change
Checklist: