Fixed
Status Update
Comments
na...@gmail.com <na...@gmail.com> #2
Forgot to mention running platform-tools 26.0.0. And Android "O" public beta
sj...@gmail.com <sj...@gmail.com> #3
Not to be "that guy" but is there any update on this? Any additional information needed?
sj...@gmail.com <sj...@gmail.com> #4
Project: platform/system/core
Branch: master
commit f806a3c303028014eec43894386fbfb117667684
Author: Josh Gao <jmgao@google.com>
Date: Fri Aug 18 18:25:44 2017
fastboot: gracefully handle failure to open a USB device on OS X.
High Sierra restricts opening some USB devices (e.g. the touchbar)
to processes that have specific entitlements. Ignore devices that we
can't open.
Bug:http://b/64292422
Test: manual
Change-Id: I6074b53a365b8d936610bafea60244f8bba1a33f
M fastboot/usb_osx.cpp
https://android-review.googlesource.com/461857
https://goto.google.com/android-sha1/f806a3c303028014eec43894386fbfb117667684
Branch: master
commit f806a3c303028014eec43894386fbfb117667684
Author: Josh Gao <jmgao@google.com>
Date: Fri Aug 18 18:25:44 2017
fastboot: gracefully handle failure to open a USB device on OS X.
High Sierra restricts opening some USB devices (e.g. the touchbar)
to processes that have specific entitlements. Ignore devices that we
can't open.
Bug:
Test: manual
Change-Id: I6074b53a365b8d936610bafea60244f8bba1a33f
M fastboot/usb_osx.cpp
rp...@google.com <rp...@google.com> #5
Since OSX 10.13 is being released the 25th of September (in 5 days as of writing), is it possible to create a new Android Platform Tools release, so the impact can be as low as possible?
se...@gmail.com <se...@gmail.com> #6
Project: platform/system/core
Branch: sdk-release
commit 73f4670f380679ba5e6081968ba7ea992edf51b9
Author: Josh Gao <jmgao@google.com>
Date: Fri Aug 18 18:25:44 2017
fastboot: gracefully handle failure to open a USB device on OS X.
High Sierra restricts opening some USB devices (e.g. the touchbar)
to processes that have specific entitlements. Ignore devices that we
can't open.
Bug:http://b/64292422
Test: manual
Change-Id: I6074b53a365b8d936610bafea60244f8bba1a33f
(cherry picked from commit f806a3c303028014eec43894386fbfb117667684)
M fastboot/usb_osx.cpp
https://android-review.googlesource.com/489920
https://goto.google.com/android-sha1/73f4670f380679ba5e6081968ba7ea992edf51b9
Branch: sdk-release
commit 73f4670f380679ba5e6081968ba7ea992edf51b9
Author: Josh Gao <jmgao@google.com>
Date: Fri Aug 18 18:25:44 2017
fastboot: gracefully handle failure to open a USB device on OS X.
High Sierra restricts opening some USB devices (e.g. the touchbar)
to processes that have specific entitlements. Ignore devices that we
can't open.
Bug:
Test: manual
Change-Id: I6074b53a365b8d936610bafea60244f8bba1a33f
(cherry picked from commit f806a3c303028014eec43894386fbfb117667684)
M fastboot/usb_osx.cpp
sa...@gmail.com <sa...@gmail.com> #7
Thanks for the reminder, I'm kicking off the process now.
rp...@google.com <rp...@google.com> #8
Release process is still churning along, until then I've attached the binary we're planning to release that should work on 10.13.
dv...@gmail.com <dv...@gmail.com> #10
Sweet, thanks a bunch!
tr...@gmail.com <tr...@gmail.com> #11
I think i still have this issue
MacBookPro13,3 (late 16" touchbar)
macOS 10.13 (17A405)
fastboot version 4022467
bnaya@bmbp ~ $ fastboot --version
fastboot version -4022467
Installed as /Users/bnaya/Library/Android/sdk/platform-tools/fastboot
bnaya@bmbp ~ $ fastboot devices
ERROR: Unable to create a plug-in (e00002be)
Sudo didn't help
MacBookPro13,3 (late 16" touchbar)
macOS 10.13 (17A405)
fastboot version 4022467
bnaya@bmbp ~ $ fastboot --version
fastboot version -4022467
Installed as /Users/bnaya/Library/Android/sdk/platform-tools/fastboot
bnaya@bmbp ~ $ fastboot devices
ERROR: Unable to create a plug-in (e00002be)
Sudo didn't help
st...@gmail.com <st...@gmail.com> #12
More info:
when starting adb i see this message
bnaya@bmbp platform-tools $ adb devices
List of devices attached
* daemon not running. starting it now at tcp:5037 *
adb E 10-28 17:42:35 1657 37964 usb_osx.cpp:152] Unable to create an interface plug-in (e00002be)
* daemon started successfully *
LGH815*** device
when starting adb i see this message
bnaya@bmbp platform-tools $ adb devices
List of devices attached
* daemon not running. starting it now at tcp:5037 *
adb E 10-28 17:42:35 1657 37964 usb_osx.cpp:152] Unable to create an interface plug-in (e00002be)
* daemon started successfully *
LGH815*** device
pi...@gmail.com <pi...@gmail.com> #13
it not yet fix
lu...@gmail.com <lu...@gmail.com> #14
Same error message for me. MacOS 10.13, Platform-tools 26.0.2
ga...@gmail.com <ga...@gmail.com> #15
it seems the version attached in comment#8 actually works on MacOSHighSierra,
(./fastboot version 9dc0875966c0-android ) , but the one (version -4022467) included in 26.0.2 tools release, does not work (it reports the same bug)
I've just flashed fine with the provided version (9dc0875966c0).
(./fastboot version 9dc0875966c0-android ) , but the one (version -4022467) included in 26.0.2 tools release, does not work (it reports the same bug)
I've just flashed fine with the provided version (9dc0875966c0).
hk...@gmail.com <hk...@gmail.com> #16 Restricted
Restricted
Comment has been deleted.
at...@gmail.com <at...@gmail.com> #17
Yeah, the fastboot we released was from a separate branch.
Description
Long story short, to get the best possible experience, applications have to be coded specifically to support this new feature, otherwise blurriness will occur in certain scenarios, as Windows will scale automatically, "The effect is that the window and content size are appropriate for every display, but the scaling introduces blurriness.".
Official doc:
There is a good summary here:
This has 2 implications:
1) Applications need to support DPI setting per top-level window (as opposed to application wide) <= This is required because top level windows of a single application may appear on separate displays, each one with distinct DPI settings.
2) Applications need to be able to apply a new DPI setting to any top level window at run-time, without restarting <= This happens when a window is moved by the user from one display to another display with a different DPI setting.
Implementation notes:
* Supporting this feature means that every top level windows of Android Studio will have it's own DPI (and scaling factor), so relying on a global scaling factor is not an option anymore.
* This also means that the application needs to support dynamically (i.e. at run time) scaling to a different factor all components of a top level window in response to the WM_DPICHANGED message.
* The two points above make the approach currently implementated in the JBUI class obsolete.