Fixed
Status Update
Comments
si...@google.com <si...@google.com>
lb...@gmail.com <lb...@gmail.com> #2
I've tried this on a HTC Sensation XE 4.0.3 with Lunar Lander, out the box, no modification, and I also see the same behaviour where a null canvas is incorrectly returned before the surface is destroyed. Net result, the sample game crashes when rotated.
lb...@gmail.com <lb...@gmail.com> #3
I wasted a good amount of time tracking this down because I didn't expect it to be a bug in android itself. Is there a consensus on the workarounds suggested? Is it considered acceptable practice to catch NullPointerException (which could be thrown from other bugs in the draw method)? Also, is it safe to condition the call to the draw method on canvas being not null (i.e. is it safe to assume there no chance that it will become null in the middle of the draw method)?
si...@google.com <si...@google.com>
ad...@google.com <ad...@google.com> #5
There is a bug in the run function. You need to verify if c is not null before drawing.
So you should implement the folowing code to avoid the bug:
@Override
public void run() {
while (mRun) {
Canvas c = null;
try {
c = mSurfaceHolder.lockCanvas(null);
if (c!=null){
synchronized (mSurfaceHolder) {
if (mMode == STATE_RUNNING) updatePhysics();
doDraw(c);// draw it
}
}
} finally {
// do this in a finally so that if an exception is thrown
// during the above, we don't leave the Surface in an
// inconsistent state
if (c != null) {
mSurfaceHolder.unlockCanvasAndPost(c);
}
}
}
}
So you should implement the folowing code to avoid the bug:
@Override
public void run() {
while (mRun) {
Canvas c = null;
try {
c = mSurfaceHolder.lockCanvas(null);
if (c!=null){
synchronized (mSurfaceHolder) {
if (mMode == STATE_RUNNING) updatePhysics();
doDraw(c);// draw it
}
}
} finally {
// do this in a finally so that if an exception is thrown
// during the above, we don't leave the Surface in an
// inconsistent state
if (c != null) {
mSurfaceHolder.unlockCanvasAndPost(c);
}
}
}
}
lb...@gmail.com <lb...@gmail.com> #6
Eric, this solution was provided in my original post. It also doesn't change the fact that the underlying behavior changed across versions. Even the samples were assuming a non-null canvas. The better solution is to fix the samples, as then this error won't creep into everyone else's code.
lb...@gmail.com <lb...@gmail.com> #7
Agree. I am having the same problem on my Nexus 4.
Description
Version used:
implementation 'androidx.appcompat:appcompat:1.0.0-beta01'
implementation 'androidx.constraintlayout:constraintlayout:1.1.2'
implementation 'com.google.android.material:material:1.0.0-beta01'
Theme used:
Devices/Android versions reproduced on:
Pixel 2 with Android P DP5
The bug is that on the IDE, the card doesn't get its corners being rounded at all (only its stroke), and on the device, it does, but it doesn't cut its content well, so it has some pixels that remain from the content, being shown outside of the stroke.
Even if you enlarge the stroke width, you can still see them.
- Relevant code to trigger the issue.
<FrameLayout
xmlns:android="
xmlns:tools="
android:layout_height="match_parent" tools:context=".MainActivity">
<com.google.android.material.card.MaterialCardView app:cardCornerRadius="14dp" app:cardElevation="10dp"
app:strokeColor="#0f0" app:strokeWidth="1dp"
android:layout_width="100dp" android:layout_height="100dp" android:layout_gravity="center">
<ImageView
android:layout_width="match_parent" android:layout_height="match_parent"
android:background="#f00"/>
</com.google.android.material.card.MaterialCardView>
</FrameLayout>
- A screenrecord or screenshots showing the issue (if UI related).
Attached.