09acb7ca897c9f49dd65b7173688e4ca63ca5dd3 |
|
18-Oct-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #11256132: Add density bucket for all real numbers between 0 and ∞... Well, how about 400. 400 is a real number. Change-Id: I29ac61b7d629d582c7b68367365a7f81fcf679a2
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
56a2301c7a1169a0692cadaeb48b9a6385d700f5 |
|
13-Feb-2013 |
Dianne Hackborn <hackbod@google.com> |
Implement issue #6646859: 4K!!!! 4K!!!! 4K!!!! Change-Id: Ib05a2eb6a03db50074805a437a3639a7d10684a0
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
7ac8bbddfcaa2539f6311be54323d22f2dcc4a35 |
|
29-Nov-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #7585876: When changing the font settings, the movie... ...just keeps attempting to load and doesn't play on the TV Change-Id: Ifcdc969a037a113224632f907d55f60a168dd05a
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
a492c3a7b2c18426fd0cb4d017eacbc368195dc5 |
|
24-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
Initial draft of high-level multi-display APIs. This patch introduces the ability to create a Context that is bound to a Display. The context gets its configuration and metrics from that display and is able to provide a WindowManager that is bound to the display. To make it easier to use, we also add a new kind of Dialog called a Presentation. Presentation takes care of setting up the context as needed and watches for significant changes in the display configuration. If the display is removed, then the presentation simply dismisses itself. Change-Id: Idc54b4ec84b1ff91505cfb78910cf8cd09696d7d
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
dde331cebd87982faded6818ad5f9927ff994c96 |
|
03-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
We can now (kind-of) change screen density on the fly. Preloaded drawables now have a density associated with them, so we can load the correct drawable if we are using a different density. Window manager now formally keeps track of the density for each screen, allowing it to be overridden like you can already do with size, and relies on this density to drive itself internally and the configurations it reports. There are a new set of Bitmap constructors where you provide a DisplayMetrics so they can be constructed with the correct density. (This will be for when you can have different windows in the same app running at different densities.) ActivityThread now watches for density changes, and pushes them to the DENSITY_DEVICE and Bitmap global density values for that process. A new am command allows you to change the density.
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
908aecc3a63c5520d5b11da14a9383f885b7d126 |
|
01-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
Start moving away from DisplayMetrics.DENSITY_DEVICE. This puts in most of the infrastructure needed to allow us to switch between different densities at run time. The main remaining uses of the global are to initialize the Bitmap object (not sure what to do about that since it doesn't have anything passed in the constructor to get this information from), and being able to load drawables if we need a different density than what was preloaded by zygote. Change-Id: Ifdbfd6b7a5c59e6aa22e63b95b78d96af3d96848
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
493861dfa011f482987c7a49d147d6e50a90c692 |
|
19-Jun-2012 |
Dianne Hackborn <hackbod@google.com> |
Docs only: DENSITY_TV, not just for TVs any more! Change-Id: Id70e0bc179ab405fbb7f3b2cda7b75f44ff30b57
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
d96e3dfa02b203b1fc826e80d6f9aa074ba9c250 |
|
26-Jan-2012 |
Dianne Hackborn <hackbod@google.com> |
Add xxhdpi; fix ActivityManager.getLauncherLargeIconSize() etc. Change-Id: I519d6cdc527a402d93b98df17a64fc1da52ad598
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
2b31d53161789358de57fd396716a6503855c5da |
|
23-Jun-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #4770360: older app compatibility mode is really tiny on ICS phones We were applying the density compat mode scaling multiple times to display metrics, causing bad values. Change-Id: Iafafd9a5e94b9d774cd2715bf968e91602a1bd82
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
b96cbbd11c4590bec846212c33361e02293f18b5 |
|
27-May-2011 |
Dianne Hackborn <hackbod@google.com> |
Add "tv" density for 720p screens. Change-Id: I028969b007f2fceea66947d77a2ae31ef1d1a630
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
81e56d535c853d73ff537357da5b935f51cb779d |
|
26-May-2011 |
Dianne Hackborn <hackbod@google.com> |
Rework how we decide whether to use system or status bar. The PhoneWindowManager is now responsible for determing this, since it needs to do this before we can generate the configuration since we need to take into account the system bar size we will use. Also the Display should now report the screen height without including the system bar. Change-Id: I82dfcc5e327e4d13d82c373c6c870f557a99b757
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
e2515eebf42c763c0a2d9f873a153711778cfc17 |
|
28-Apr-2011 |
Dianne Hackborn <hackbod@google.com> |
Better compat mode part one: start scaling windows. First step of improving app screen size compatibility mode. When running in compat mode, an application's windows are scaled up on the screen rather than being small with 1:1 pixels. Currently we scale the application to fill the entire screen, so don't use an even pixel scaling. Though this may have some negative impact on the appearance (it looks okay to me), it has a big benefit of allowing us to now treat these apps as normal full-screens apps and do the normal transition animations as you move in and out and around in them. This introduces fun stuff in the input system to take care of modifying pointer coordinates to account for the app window surface scaling. The input dispatcher is told about the scale that is being applied to each window and, when there is one, adjusts pointer events appropriately as they are being sent to the transport. Also modified is CompatibilityInfo, which has been greatly simplified to not be so insane and incomprehendible. It is now simple -- when constructed it determines if the given app is compatible with the current screen size and density, and that is that. There are new APIs on ActivityManagerService to put applications that we would traditionally consider compatible with larger screens in compatibility mode. This is the start of a facility to have a UI affordance for a user to switch apps in and out of compatibility. To test switching of modes, there is a new variation of the "am" command to do this: am screen-compat [on|off] [package] This mode switching has the fundamentals of restarting activities when it is changed, though the state still needs to be persisted and the overall mode switch cleaned up. For the few small apps I have tested, things mostly seem to be working well. I know of one problem with the text selection handles being drawn at the wrong position because at some point the window offset is being scaled incorrectly. There are probably other similar issues around the interaction between two windows because the different window coordinate spaces are done in a hacky way instead of being formally integrated into the window manager layout process. Change-Id: Ie038e3746b448135117bd860859d74e360938557
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
a0b46c9c441f017a2008ca8ee2c864987465996b |
|
22-Oct-2010 |
Dianne Hackborn <hackbod@google.com> |
Implement issue #3116702: New manifest tags for supported screen sizes Merged from GB. Change-Id: I94730b54bcacd083f77708e84c35f4932a7b9d2e
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
14cee9f688c32d63d8521188e7422811629bb7c2 |
|
24-Apr-2010 |
Dianne Hackborn <hackbod@google.com> |
New xlarge screen size. Not complete, only for experimentation at this point. This includes a reworking of how screen size configurations are matched, so that if you are on a larger screen we can select configurations for smaller screens if there aren't any exactly matching the current screen. The screen size at which we switch to xlarge has been arbitrarily chosen; the compatibility behavior has not yet been defined. Change-Id: I1a33b3818eeb51a68fb72397568c39ab040a07f5
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
6b13bc043e715b5415b701e93141daa0d49fa364 |
|
31-Oct-2009 |
Dirk Dougherty <ddougherty@google.com> |
doc change: misc doc fixes. Bug:2160782 Change-Id: Iaf5d2cc2e3c657700469e8b7394a95bc03fc26f3
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
71d4b289a7a934ecd16c3036b812d40db6d3a74d |
|
13-Aug-2009 |
Scott Main <smain@google.com> |
DOCS ONLY. add manifest documentation for uses-feature and supports-screens elements. also update the navigation and manifest home page, update the uses-sdk element to include new maxSdk and targeSdk attributes, and add some sample code to DisplayMetrics to query the device for screen info.
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
11ea33471e1a14a8594f0b2cd012d86340dd3bd8 |
|
23-Jul-2009 |
Dianne Hackborn <hackbod@google.com> |
Allow for screen density drawables in compatibility mode. This change allows us to use drawables that match the current screen density even when being loaded in compatibility mode. In this case, the bitmap is loaded in the screen density, and the bitmap and nine-patch drawables take care of accounting for the density difference. This should be safe for existing applications, for the most part, since they shouldn't really be pulling the bitmap out of the drawable. For the small rare chance of them breaking, it worth getting the correct graphics. Also this will only happen when there is actually a resource of the matching density, and no existing apps should have resources for anything besides the default density (though of course all of the framework resources will be available in the native density). As part of this, the bitmap density API has been changed to a single integer provider the DPI unit density.
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
c4db95c077f826585d20be2f3db4043c53d30cf5 |
|
22-Jul-2009 |
Dianne Hackborn <hackbod@google.com> |
First pass at reworking screen density/size APIs. This changes the names of the directories in aapt, to what you see in the list of DpiTest resources. Also adds a new "long" configuration for wide screens, which the platform sets appropriate, and introduces a new kind of resizeability for not large but significantly larger than normal screens which may have compatibility issues.
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
61324e58c549670c015010d0be14c6af76e3e9f7 |
|
22-Jul-2009 |
Mitsuru Oshima <oshima@google.com> |
cast is floor. Use round instead. This fixes a few layout issues (that was due to smaller widnow size)
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
a53b828635fce8b6b2d3e3377d74d72070056623 |
|
17-Jul-2009 |
Dianne Hackborn <hackbod@google.com> |
Add "nodpi" density, and expose a bunch of density-related APIs. Also update the DpiTest app to use nodpi images, and try to have a mode where it turns off compatibility though it's not quite working.
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
1ecf5d28817f0a051e77488380dcd5bc622ea169 |
|
07-Jul-2009 |
Mitsuru Oshima <oshima@google.com> |
Re-implementation of large screen support using window manager. * added background filler surface to fill the outer rim. Using the same layer as dim surface because they never co-exists (in the same window) * clean up the obsolete code in CompatibiltyMode/ViewRoot for support large screen support.
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
723738cfaec3dd7b0fe152c872c41bebf94074c4 |
|
26-Jun-2009 |
Dianne Hackborn <hackbod@google.com> |
Expand support for different screen sizes. Applications can now declare that they support small, normal, or large screens. Resource selection can also be done based on these sizes. By default, pre-Donut apps are false for small and large, and Donut or later apps are assumed to support all sizes. In either case they can use <supports-screens> in their manifest to declare what they actually support.
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
64f59342d41849bd365cb43fad7505d5e3daa417 |
|
21-Jun-2009 |
Mitsuru Oshima <oshima@google.com> |
* new screen resolution support impl. * use full window for activities, and shift & clip the content * refactored the compatibility code, and introdcued Translator class to handle cooridnate translations. * removed a workaround to handle an activity with configChagne=rotation in old implementation. * I'll fix background issue on rotation in next CL. * removed unnecessary scaling code in SurfaceView, which I forgot to remove when I changed SurfaceView not to scale the content.
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
2a578ae518ff3d8a2d4768b3d190e4702509e82c |
|
18-Jun-2009 |
David 'Digit' Turner <digit@google.com> |
Allow the qemu.sf.lcd_density property to override the value of ro.sf.lcd_density ro.sf.lcd_density is usually defined in the build.prop file which is parsed by init before anything else. Since its name begins with "ro.", this property is write-once and cannot later be modified, e.g. in /system/etc/init.goldfish.sh. In other words, you cannot use "emulator -prop ro.sf.lcd_density=<value>", since it is impossible to override the value defined in build.prop This patch modifies the system to recognize "qemu.sf.lcd_density" as an override value, which can be set with "emulator -prop qemu.sf.lcd_density=<value>", forcing a specific density. A later patch will allow the emulator to automatically set this property depending on AVD hardware configuration settings.
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
e5fb328825995aa33b5b7ecf8b5bee2b17f81715 |
|
10-Jun-2009 |
Mitsuru Oshima <oshima@google.com> |
resolution support fix/improvement * adding compatibility menu * backup gravity * set expanable=true if the screen size is hvga * density. * added "supports any density" mode. I'll add sdk check later. * disallow to catch orientation change event if the app is not expandable. This was causing layout problem under non-expandable mode. I discussed this with Mike C and we agreed to do this approach for now. We'll revisit if this causes problem to a lot of applications.
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
9189cabb0b6c6c28232fe6f412b7ba7a37352a6a |
|
03-Jun-2009 |
Mitsuru Oshima <oshima@google.com> |
* Moved supports-density tag under manifest * Refactored Compatibility code * Added CompatibilityInfo class * Removed getApplicationScale from Context * Added Resources#getCompatibilityInfo so that RootView can get the compatibility info w/o going through Context * Expandable support * Added expandable tag under manifest * Old application w/o expandable is given the default screen size ([320, 480] x density). * The non-expandable window is centered.
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
58feea74b42bbaaa0552d76af23873bdd0b5dca2 |
|
12-May-2009 |
Mitsuru Oshima <oshima@google.com> |
* update all metrics data when updating density. * Keyboard should use DisplayMetrics from Resource rather than getting it from WindowManager as the display metrics can differ under compatibility mode.
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
2e3d3b9ce74cb9c906e5cc0e9898d757d45c4237 |
|
07-May-2009 |
Mitsuru Oshima <oshima@google.com> |
* update density correctly when the configuration is changed. * Turns private sLcdDensity to public DEVICE_DENSITY to use it in ActivityThread
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
9066cfe9886ac131c34d59ed0e2d287b0e3c0087 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
d24b8183b93e781080b2c16c487e60d51c12da31 |
|
11-Feb-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@130745
/frameworks/base/core/java/android/util/DisplayMetrics.java
|
54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/core/java/android/util/DisplayMetrics.java
|