summaryrefslogtreecommitdiff
path: root/core/java/android/util/DisplayMetrics.java
Commit message (Collapse)AuthorAgeFilesLines
* Add @Nullable annotation to the parameter of Object.equals() methods.Roman Kalukiewicz2020-10-151-2/+2
| | | | | | | | | | | | | | | | | | Those annotations could be inferred by some tools (like Kotlin), but the https://checkerframework.org/ doesn't check inherited annotations complaining about all equals() invocations that get nullable argument. The change was generated by running find . -name \*.java | xargs sed -i 's/public boolean equals(Object /public boolean equals(@Nullable Object /' in the frameworks/base directory and by automatically adding and formatting required imports if needed. No manual edits. Bug: 170883422 Test: Annotation change only. Should have not impact. Exempt-From-Owner-Approval: Mechanical change not specific to any component. Change-Id: I5eedb571c9d78862115dfdc5dae1cf2a35343580
* Use new UnsupportedAppUsage annotation.Artur Satayev2020-01-071-1/+1
| | | | | | | | Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library. Bug: 145132366 Test: m && diff unsupportedappusage_index.csv Change-Id: I288969b0c22fa3a63bc2e71bb5009fe4a927e154
* Merge "docs: fix code example" into qt-devTreeHugger Robot2019-11-131-3/+2
|\
| * docs: fix code exampleJoshua Baxter2019-11-111-3/+2
| | | | | | | | | | | | | | bug: 135556269 Change-Id: I9ba7a0f7de0322ba5e82413c0a95dffbef5a6236 test: make ds-docs
* | docs: fix typoJoshua Baxter2019-11-081-1/+1
|/ | | | | | | bug: 119479852 Change-Id: I5c2c31432446ef6fccf3ac80e44a1660654375c0 Test: make ds-docs
* DO NOT MERGE: Add DENSITY_450bj1211jeon2019-06-141-0/+8
| | | | | | | | | | | | | | Add 450dpi as a supported screen density. This change follows up below change Id : Iac673eae2d82c27d96e279c076454af2f5933208 Originally 600dpi was added to support sw384 with WQHD resolution, though it was lack of for the cases when resolution is FHD resolution. (In case of other resolutions, there already exist 300 and 200 for HD and WVGA resolutions). Bug: 78283907 Test: run android.dpi.cts.ConfigurationTest#testScreenConfiguration and android.app.cts.ActivityManagerMemoryClassTest#testGetMemoryClass (cherry picked from commit 13ca0450ede3eedf7d34bbd0b69525cb6ebc63f1) Change-Id: Ide0baba183c7dea962610d16f18fecbd0dc62567
* Add DENSITY_140, DENSITY_180, DENSITY_200, DENSITY_220Harry Slatyer2019-04-151-0/+28
| | | | | | | | | | This gives supported densities every 20dpi at the low end of densities, which is where all current automotive screens sit. BUG: 127714569 Test: None, just adding constants. Change-Id: I6dd96493bf4474a55f22ce4ddbe27566d4ab9deb
* Add DENSITY_600st.ji2018-08-201-0/+8
| | | | | | | | | Add 600dpi as a supported screen density Test: run android.dpi.cts.ConfigurationTest#testScreenConfiguration and android.app.cts.ActivityManagerMemoryClassTest#testGetMemoryClass Change-Id: Iac673eae2d82c27d96e279c076454af2f5933208 Signed-off-by: st.ji <st.ji@samsung.com>
* Add @UnsupportedAppUsage annotationsMathew Inwood2018-08-141-0/+5
| | | | | | | | | | | | | | | | | | | | For packages: android.util.proto android.util.jar android.util.apk android.util This is an automatically generated CL. See go/UnsupportedAppUsage for more details. Exempted-From-Owner-Approval: Mechanical changes to the codebase which have been approved by Android API council and announced on android-eng@ Bug: 110868826 Test: m Change-Id: I18848448a81132399f6878812acf5031ed8cec9f Merged-In: Ia0f48c244b0fbe33d40d797702a82303648196ed
* Add DENSITY_440weijuncheng2018-01-261-0/+8
| | | | | | | | | | | Add 440dpi as a supported screen density Bug: 72424600 Test: run android.dpi.cts.ConfigurationTest#testScreenConfiguration and android.app.cts.ActivityManagerMemoryClassTest#testGetMemoryClass Change-Id: I0dbf998ae02515a97f0d5668eeedc7098da4cca4 Signed-off-by: weijuncheng <weijuncheng@xiaomi.com>
* Update DisplayMetrics even on default displayAdam Lesinski2016-10-141-0/+4
| | | | | | | | | | | | | | | Fix a bug where the DisplayMetrics wouldn't be updated for a Resources object on the default display. Since multi-window, we want to update all Resources. This didn't always manifest itself due to recreation of assets, which would force an update of DisplayMetrics. Re-use of an AssetManager from the cache would expose the bug. Bug:32133693 Bug:31998629 Test: cts-tradefed run cts --module CtsServicesHostTestCases Change-Id: Ic51ab82710517b87eb995ccf982085dba876ad58
* Add DENSITY_260, DENSITY_300, DENSITY_340Erik Wolsheimer2016-06-151-0/+22
| | | | | | | Add supported screen densities to closer match some hardware's physical specifications BUG: 24132725 Change-Id: I7138d92fa4e1f4320f9068e154bd8318ac0c45c7
* Update docs for DisplayMetrics pixel size fieldsAndrii Kulian2016-03-101-2/+2
| | | | | | | | Update docs to reflect that values in fields store sizes available for application (not full screen size). Bug: 27449789 Change-Id: I92f7552a92fa1b66c5eba4cf28693528cbff21d3
* Add DENSITY_DEVICE_STABLE constantAlan Viverette2016-01-291-5/+18
| | | | | | | | The existing DENSITY_DEVICE gets updated by ActivityThread following configuration changes that affect density, so just a docs update there. Bug: 26854123 Change-Id: I69dfca99a6038ed9cf8b2f2c007cdbc4a399dd8a
* Fix issue #23122445: Add 420 densityDianne Hackborn2015-08-111-0/+8
| | | | Change-Id: I15c113eb7e22f1d882db071c007224746f9d408f
* Add DENSITY_360Adam Powell2015-06-041-0/+8
| | | | | | | | | | Add 360dpi as a supported screen density to closer match some hardware's physical specifications. This gives a dp multiplier of 2.25. Bug 19529059 Change-Id: Ibf9c768fba53765ea684ff228d24caf091f27a3e
* Add DENSITY_280Adam Powell2015-02-111-0/+7
| | | | | | Bug 19350604 Change-Id: I94f5162c31f9c8853908d7c4699974c236cc7fe7
* Corrects a typo that identified XXXHIGH as 560 dpi instead of 640.Philip Nowell2014-09-261-1/+1
| | | | Change-Id: I8b5ac84431d378f0e43be8d19920fd6ba335ebc6
* Add 560dpi, and some other stuff.Dianne Hackborn2014-08-121-1/+9
| | | | | | | | | | Like new settings actions for some of the new settings panels. And fix voice interaction services so they require a recognizer. And tweak array map doc to be correct. Blah blah blah. Change-Id: Ib5e66b574b10e7b3fa39723b21046a74e6ead204
* Remove obsolete remark from XXHDPI comment.Jeff Davidson2014-07-161-3/+1
| | | | | | | XXHDPI screens now make up 15% of all Android devices, so developers should be encouraged to include assets at this density. Change-Id: I9d845769233a71dd954b5f35246aabb774a1c40d
* Fix issue #11256132: Add density bucket for all real numbers between 0 and ↵Dianne Hackborn2013-10-171-0/+8
| | | | | | | | ∞... Well, how about 400. 400 is a real number. Change-Id: I29ac61b7d629d582c7b68367365a7f81fcf679a2
* Implement issue #6646859: 4K!!!! 4K!!!! 4K!!!!Dianne Hackborn2013-02-121-0/+9
| | | | Change-Id: Ib05a2eb6a03db50074805a437a3639a7d10684a0
* Fix issue #7585876: When changing the font settings, the movie...Dianne Hackborn2012-11-291-2/+15
| | | | | | ...just keeps attempting to load and doesn't play on the TV Change-Id: Ifcdc969a037a113224632f907d55f60a168dd05a
* Initial draft of high-level multi-display APIs.Jeff Brown2012-08-311-6/+45
| | | | | | | | | | | | | | | 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
* We can now (kind-of) change screen density on the fly.Dianne Hackborn2012-08-031-1/+1
| | | | | | | | | | | | | | | | | | | | | 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.
* Start moving away from DisplayMetrics.DENSITY_DEVICE.Dianne Hackborn2012-08-011-5/+21
| | | | | | | | | | | | 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
* Docs only: DENSITY_TV, not just for TVs any more!Dianne Hackborn2012-06-181-5/+15
| | | | Change-Id: Id70e0bc179ab405fbb7f3b2cda7b75f44ff30b57
* Add xxhdpi; fix ActivityManager.getLauncherLargeIconSize() etc.Dianne Hackborn2012-01-251-0/+7
| | | | Change-Id: I519d6cdc527a402d93b98df17a64fc1da52ad598
* Fix issue #4770360: older app compatibility mode is really tiny on ICS phonesDianne Hackborn2011-06-231-6/+34
| | | | | | | We were applying the density compat mode scaling multiple times to display metrics, causing bad values. Change-Id: Iafafd9a5e94b9d774cd2715bf968e91602a1bd82
* Add "tv" density for 720p screens.Dianne Hackborn2011-05-271-0/+9
| | | | Change-Id: I028969b007f2fceea66947d77a2ae31ef1d1a630
* Rework how we decide whether to use system or status bar.Dianne Hackborn2011-05-261-8/+16
| | | | | | | | | | | 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
* Better compat mode part one: start scaling windows.Dianne Hackborn2011-05-091-98/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Implement issue #3116702: New manifest tags for supported screen sizesDianne Hackborn2010-10-221-0/+5
| | | | | | Merged from GB. Change-Id: I94730b54bcacd083f77708e84c35f4932a7b9d2e
* New xlarge screen size.Dianne Hackborn2010-04-281-1/+12
| | | | | | | | | | | | | 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
* doc change: misc doc fixes.Dirk Dougherty2009-10-301-1/+1
| | | | | Bug:2160782 Change-Id: Iaf5d2cc2e3c657700469e8b7394a95bc03fc26f3
* DOCS ONLY.Scott Main2009-08-131-0/+3
| | | | | | | 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.
* Allow for screen density drawables in compatibility mode.Dianne Hackborn2009-07-241-0/+9
| | | | | | | | | | | | | | | | | | 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.
* First pass at reworking screen density/size APIs.Dianne Hackborn2009-07-211-41/+57
| | | | | | | | 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.
* cast is floor. Use round instead.Mitsuru Oshima2009-07-211-6/+10
| | | | This fixes a few layout issues (that was due to smaller widnow size)
* Add "nodpi" density, and expose a bunch of density-related APIs.Dianne Hackborn2009-07-171-10/+24
| | | | | 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.
* Re-implementation of large screen support using window manager.Mitsuru Oshima2009-07-081-3/+0
| | | | | | * 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.
* Expand support for different screen sizes.Dianne Hackborn2009-06-261-27/+34
| | | | | | | | | 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.
* * new screen resolution support impl.Mitsuru Oshima2009-06-231-12/+17
| | | | | | | | | | * 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.
* Allow the qemu.sf.lcd_density property to override the value of ↵David 'Digit' Turner2009-06-191-2/+10
| | | | | | | | | | | | | | | | | | 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.
* resolution support fix/improvementMitsuru Oshima2009-06-101-11/+22
| | | | | | | | | | | * 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.
* * Moved supports-density tag under manifestMitsuru Oshima2009-06-031-10/+41
| | | | | | | | | | | * 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.
* * update all metrics data when updating density.Mitsuru Oshima2009-05-111-0/+20
| | | | | * Keyboard should use DisplayMetrics from Resource rather than getting it from WindowManager as the display metrics can differ under compatibility mode.
* * update density correctly when the configuration is changed.Mitsuru Oshima2009-05-061-4/+8
| | | | * Turns private sLcdDensity to public DEVICE_DENSITY to use it in ActivityThread
* auto import from //depot/cupcake/@135843The Android Open Source Project2009-03-031-0/+98
|
* auto import from //depot/cupcake/@135843The Android Open Source Project2009-03-031-98/+0
|
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-20 15:55:30 +0000