Fixed
Status Update
Comments
ki...@google.com <ki...@google.com>
no...@google.com <no...@google.com> #3
lblb636@ Thanks for reporting this bug. I just want to confirm that the issue is the call device
button being not responsive according to the uploaded video. It seems like this issue only happened on Windows.
si...@google.com <si...@google.com> #4
@3 Why does it occur?
And why only from specific API of Android?
On API 28 for example, it doesn't occur...
Please fix this issue for all API versions of the emulator.
And why only from specific API of Android?
On API 28 for example, it doesn't occur...
Please fix this issue for all API versions of the emulator.
ap...@google.com <ap...@google.com> #5
Another similar issue that's related
si...@google.com <si...@google.com>
an...@google.com <an...@google.com> #6
RE#4 I need to try this on Windows laptop first and I couldn't repro on MacOS or Linux. But I think this is most likely related to the modem simulator we introduced for API 31. Will need to further investigate.
dr...@gmail.com <dr...@gmail.com> #7
@6 There are plenty of issues on emulator API 31 (and on Android 13 emulator). Many glitches. Spend 5 minutes on it and you will notice.
Why isn't the emulator tested more on Windows OS?
Windows OS is more popular than Linux and MacOS combined (on desktop) ...
Why isn't the emulator tested more on Windows OS?
Windows OS is more popular than Linux and MacOS combined (on desktop) ...
si...@google.com <si...@google.com> #8
@6 Also please check on all versions of the emulator, to see when this issue started, and fix from there.
dr...@gmail.com <dr...@gmail.com> #9
I reproduced this bug on Windows with emulator version 31.2.10-8420304
Description
When using
ResourcesCompat.getFont
to resolve a .ttf file in res/font, the returnedTypeface
instance always has a weight of 400 and a style ofNORMAL
.On all APIs < 29, style correctly resolves to
ITALIC
. On API 28, weight correctly resolves to 300.The font actually looks correct when displayed on an API 29 device, it just has the wrong values according to the
Typeface
instance.The issue is reproducible in this test class . Several tests fail on API 29 only due to this issue. I've also added a temporary
typefaceBug
test case that uses an ActivityScenario to demonstrate that the text actually appears correctly on API 29.