Status Update
No update yet.
Comments
lb...@gmail.com
Any suggestions on where such an interface might live? I don't think it makes sense for the interface to be in the drawerlayout artifact if you're specifically going to use the interface to *not* use DrawerLayout.
ad...@google.com
ad...@google.com
androidx.customview would be a good candidate. This is used by all of the widget libraries.
lb...@gmail.com
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 3ed3fb003fa6c1244f923202859a616225b5b2fa
Author: Ian Lake <ilake@google.com>
Date: Fri Feb 14 11:17:46 2020
Create an interface for layouts that can be opened
Create a common interface that represents layouts
that have two states: open and closed. This allows
higher level libraries to rely on the interface,
rather than concrete implementations such as
DrawerLayout, making them more resilient to
changes in the current recommended implementation.
Fixes: 129979320
Test: ./gradlew checkApi
Change-Id: I0f2a1414977825aa053c6555261f2b7d4417bd19
M customview/customview/api/1.1.0-alpha02.txt
M customview/customview/api/current.txt
M customview/customview/api/public_plus_experimental_1.1.0-alpha02.txt
M customview/customview/api/public_plus_experimental_current.txt
M customview/customview/api/restricted_1.1.0-alpha02.txt
M customview/customview/api/restricted_current.txt
A customview/customview/src/main/java/androidx/customview/widget/Openable.java
M drawerlayout/drawerlayout/api/1.1.0-alpha03.txt
M drawerlayout/drawerlayout/api/current.txt
M drawerlayout/drawerlayout/api/public_plus_experimental_1.1.0-alpha03.txt
M drawerlayout/drawerlayout/api/public_plus_experimental_current.txt
M drawerlayout/drawerlayout/api/restricted_1.1.0-alpha03.txt
M drawerlayout/drawerlayout/api/restricted_current.txt
M drawerlayout/drawerlayout/build.gradle
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
M jetifier/jetifier/migration.config
M slidingpanelayout/slidingpanelayout/api/1.1.0-alpha01.txt
M slidingpanelayout/slidingpanelayout/api/current.txt
M slidingpanelayout/slidingpanelayout/api/public_plus_experimental_1.1.0-alpha01.txt
M slidingpanelayout/slidingpanelayout/api/public_plus_experimental_current.txt
M slidingpanelayout/slidingpanelayout/api/restricted_1.1.0-alpha01.txt
M slidingpanelayout/slidingpanelayout/api/restricted_current.txt
M slidingpanelayout/slidingpanelayout/src/main/java/androidx/slidingpanelayout/widget/SlidingPaneLayout.java
https://android-review.googlesource.com/940787
Branch: androidx-master-dev
commit 3ed3fb003fa6c1244f923202859a616225b5b2fa
Author: Ian Lake <ilake@google.com>
Date: Fri Feb 14 11:17:46 2020
Create an interface for layouts that can be opened
Create a common interface that represents layouts
that have two states: open and closed. This allows
higher level libraries to rely on the interface,
rather than concrete implementations such as
DrawerLayout, making them more resilient to
changes in the current recommended implementation.
Fixes: 129979320
Test: ./gradlew checkApi
Change-Id: I0f2a1414977825aa053c6555261f2b7d4417bd19
M customview/customview/api/1.1.0-alpha02.txt
M customview/customview/api/current.txt
M customview/customview/api/public_plus_experimental_1.1.0-alpha02.txt
M customview/customview/api/public_plus_experimental_current.txt
M customview/customview/api/restricted_1.1.0-alpha02.txt
M customview/customview/api/restricted_current.txt
A customview/customview/src/main/java/androidx/customview/widget/Openable.java
M drawerlayout/drawerlayout/api/1.1.0-alpha03.txt
M drawerlayout/drawerlayout/api/current.txt
M drawerlayout/drawerlayout/api/public_plus_experimental_1.1.0-alpha03.txt
M drawerlayout/drawerlayout/api/public_plus_experimental_current.txt
M drawerlayout/drawerlayout/api/restricted_1.1.0-alpha03.txt
M drawerlayout/drawerlayout/api/restricted_current.txt
M drawerlayout/drawerlayout/build.gradle
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
M jetifier/jetifier/migration.config
M slidingpanelayout/slidingpanelayout/api/1.1.0-alpha01.txt
M slidingpanelayout/slidingpanelayout/api/current.txt
M slidingpanelayout/slidingpanelayout/api/public_plus_experimental_1.1.0-alpha01.txt
M slidingpanelayout/slidingpanelayout/api/public_plus_experimental_current.txt
M slidingpanelayout/slidingpanelayout/api/restricted_1.1.0-alpha01.txt
M slidingpanelayout/slidingpanelayout/api/restricted_current.txt
M slidingpanelayout/slidingpanelayout/src/main/java/androidx/slidingpanelayout/widget/SlidingPaneLayout.java
lb...@gmail.com
lb...@gmail.com
I have now Android P DP 4 (beta 3), and this is still an issue.
hasPhone = intent.hasExtra(TelephonyManager.EXTRA_INCOMING_NUMBER)
phone = if (hasPhone) intent.getStringExtra(TelephonyManager.EXTRA_INCOMING_NUMBER) else null
val state = intent.getStringExtra(TelephonyManager.EXTRA_STATE)
Incoming phone call with a normal phone number:
android.intent.action.PHONE_STATE state:RINGING phone:null hasPhone:false
android.intent.action.PHONE_STATE state:RINGING phone:050... hasPhone:true
Incoming phone call with a private phone number:
android.intent.action.PHONE_STATE state:RINGING phone:null hasPhone:false
android.intent.action.PHONE_STATE state:RINGING phone:null hasPhone:false
And on Android 6 , for example:
Incoming phone call with a normal phone number:
android.intent.action.PHONE_STATE state:RINGING phone:050... hasPhone:true
Incoming phone call with a private phone number:
android.intent.action.PHONE_STATE state:RINGING phone:null hasPhone:false
So, still it's impossible to differentiate .
Please just add an extra boolean in the bundle : "EXTRA_UNDETERMINED_PHONE_NUMBER" , or have a behavior that's consistent with previous versions.
And in any case, don't use the new behavior of duplicate calls, if targetSdk isn't 28. This breaks apps. Really.
hasPhone = intent.hasExtra(TelephonyManager.EXTRA_INCOMING_NUMBER)
phone = if (hasPhone) intent.getStringExtra(TelephonyManager.EXTRA_INCOMING_NUMBER) else null
val state = intent.getStringExtra(TelephonyManager.EXTRA_STATE)
Incoming phone call with a normal phone number:
android.intent.action.PHONE_STATE state:RINGING phone:null hasPhone:false
android.intent.action.PHONE_STATE state:RINGING phone:050... hasPhone:true
Incoming phone call with a private phone number:
android.intent.action.PHONE_STATE state:RINGING phone:null hasPhone:false
android.intent.action.PHONE_STATE state:RINGING phone:null hasPhone:false
And on Android 6 , for example:
Incoming phone call with a normal phone number:
android.intent.action.PHONE_STATE state:RINGING phone:050... hasPhone:true
Incoming phone call with a private phone number:
android.intent.action.PHONE_STATE state:RINGING phone:null hasPhone:false
So, still it's impossible to differentiate .
Please just add an extra boolean in the bundle : "EXTRA_UNDETERMINED_PHONE_NUMBER" , or have a behavior that's consistent with previous versions.
And in any case, don't use the new behavior of duplicate calls, if targetSdk isn't 28. This breaks apps. Really.
lb...@gmail.com
Or just remove this useless extra call!
I can't find any reason to have it.
It doesn't even get explained in the docs. Doesn't even tell from which Android version.
I can't find any reason to have it.
It doesn't even get explained in the docs. Doesn't even tell from which Android version.
ad...@google.com
We've deferred this issue for consideration in a future release. Thank you for your time to make Android better. In case you want to provide more information with respect to this bug, please file a bug in AOSP via "https://goo.gl/TbMiIO "
Description
For some reason it was decided that it should be this way. I have no idea why. I really wish it was just a single call.
But, assuming this is a new behavior, I'd like to request that it will be possible to identify the call that doesn't have the EXTRA_INCOMING_NUMBER.
This is important, because in most cases, on devices on all Android versions I've seen, this will get only one call, and it will have either null for EXTRA_INCOMING_NUMBER or a real number.
That's while looking at the new behavior, we will always see null for EXTRA_INCOMING_NUMBER at first, and then the real call that have either null or a real number.
This makes it impossible to know if the the caller has a private number or not, and whether we will get a phone number out of it or not.
The only workaround (which is a bad one) that I could find, is that when I get a call to ACTION_PHONE_STATE_CHANGED , I delay the handling of it by 100 ms so that I give the next one a chance to be handled, if it indeed occurs.
What I request, is that only in the case of 2 calls to ACTION_PHONE_STATE_CHANGED , we will be able to differentiate between the useless one that always has null for EXTRA_INCOMING_NUMBER , and the important one that has it when it got a phone number, and null when it's a private number.
An extra flag in this case could be nice.
One that I could choose to ignore the call to ACTION_PHONE_STATE_CHANGED for one value, and use what I got for EXTRA_INCOMING_NUMBER on the other value.