New issue
Advanced search Search tips

Issue 593322 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Mar 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Lots of failing tests on downstream bots (nakasi, occam-svelte, volantis, android-one)

Project Member Reported by lizeb@chromium.org, Mar 9 2016

Issue description

See https://uberchromegw.corp.google.com/i/internal.client.clank/builders/android-one/builds/3075

Suspected CL in range:
https://codereview.chromium.org/1770883004

twellington: Can you take a look? I don't really see why this CL is related, but it's the only android-related one in the range.
 
Project Member

Comment 1 by bugdroid1@chromium.org, Mar 9 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/170e6a54eeb57a17a6909e88770d2cab88b7901c

commit 170e6a54eeb57a17a6909e88770d2cab88b7901c
Author: lizeb <lizeb@chromium.org>
Date: Wed Mar 09 13:16:31 2016

Revert of Use Display.getRealMetrics() to calculate device size (patchset #6 id:100001 of https://codereview.chromium.org/1770883004/ )

Reason for revert:
Speculative revert for https://bugs.chromium.org/p/chromium/issues/detail?id=593322

BUG= 593322 

Original issue's description:
> Use Display.getRealMetrics() to calculate device size
>
> Regular DisplayMetrics subtract the window decorations, causing
> the DeviceFormFactor.isTablet() calculation to be incorrect.
> To account for multi-window on N, use Display.getRealMetrics() instead.
> This API method is only available in level 17+, so use
> Configuration.smallestScreenWidthDp as a fallback.
>
> BUG=591861
>
> Committed: https://crrev.com/c6d363b1b16ef1de57ad555ea3efabb61fe38801
> Cr-Commit-Position: refs/heads/master@{#379955}

TBR=newt@chromium.org,twellington@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=591861

Review URL: https://codereview.chromium.org/1776963002

Cr-Commit-Position: refs/heads/master@{#380127}

[modify] https://crrev.com/170e6a54eeb57a17a6909e88770d2cab88b7901c/chrome/android/java/src/org/chromium/chrome/browser/init/AsyncInitializationActivity.java
[modify] https://crrev.com/170e6a54eeb57a17a6909e88770d2cab88b7901c/ui/android/java/src/org/chromium/ui/base/DeviceFormFactor.java

this also may be responsible for some of the failures on chromium.android, e.g. https://build.chromium.org/p/chromium.android/builders/Lollipop%20Phone%20Tester
It seems likely since the last Lollipop Phone Tester build with the revert was successful.

Not at all sure what's going on yet, but I'm investigating

I can repro locally (passes w/out patch, fails w/ patch).

The only thing in the logs is:
03-09 08:55:36.320 28819  3420 W ActivityManager: Spurious death for ProcessRecord{584ec99 0:com.google.android.apps.chrome/u0a112},
Found the root cause - context.getApplicationContext() is returning null, which in retrospect makes sense since Instrumetnation's getContext() is the context of the instrumentation's package rather than the application ( http://developer.android.com/reference/android/app/Instrumentation.html#getContext() )

I'm going to close this out and land another patch using my original bug. I'll keep a close eye on the bots today to make sure I don't break everything again.
Status: Fixed (was: Assigned)
To close the loop on this, the fix is to change incorrect uses of Instrumentation.getContext() to getTargetContext().

I found some instances in our base istrum classes, running all of the small tests locally to look for other incorrect uses.

Sign in to add a comment