| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Change-Id: Ic266e491a73fb3df00e77111a4ad9f270741c28b
|
|
|
|
|
|
|
|
|
|
| |
Also replaced all doThrow by jniThrow.
OutOfMemory after string creation were removed: should have been thrown before.
Bug http://b/issue?id=2949164
Change-Id: Idea8e27fdedeb43e3976776c477766e4dcdebcf8
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we're grabbing references to many strings in a loop, we have to
remove our local references so we don't overflow the VM's local
reference table.
Also, use env->ExceptionCheck() instead of checking for NULL value
returns on trying to allocate new items.
Bug: 2663816
Change-Id: I9cb5e17f6181dbb2f2c03d53841b2f5d8ab10f68
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug #2376231: Apps lose window focus (and back key causes ANR) if the
lock screen is dismissed while the phone is in landscape mode
This is another case where we weren't recomputing the focused window
after changing the visibility policy.
bug #2479958: Investigate source of "Resources don't contain package
for resource number 0x7f0a0000"
Um, okay, so it turns out there were bugs all over the place where
we would load an XML resource from a another application, but not
use the Resources for that application to retrieve its resources...!
I think the only reason any of this stuff was working at all was
because it typically only cared about retrieving the resource
identifiers of the items (it would look up the values later).
Bug #2401082: Passion ERE26 monkey crash - InputMethodManagerService
Add some null checks.
|
|
|
|
|
|
|
|
|
|
|
|
| |
StringBlock instances containing UTF-8 strings use a cache to convert
into UTF-16, but using that cache and then using a JNI call to NewString
causes the UTF-8 string as well as two copies of the UTF-16 string to
be held in memory. Getting the UTF-8 string directly from the StringPool
eliminates one copy of the UTF-16 string being held in memory.
This is part 1. Part 2 will include ResXMLParser optimizations.
Change-Id: Ibd4509a485db746d59cd4b9501f544877139276c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The device mode is now called ui mode. Furthermore is the order of
precedence for the resources now in such a way that the ui mode needs
to be specified after the orientation and before the density.
The ui mode can be set, like it is done for the locale, as follows:
IActivityManager am = ActivityManagerNative.getDefault();
Configuration config = am.getConfiguration();
config.uiMode = Configuration.UI_MODE_TYPE_CAR | Configuration.UI_MODE_NIGHT_ANY;
am.updateConfiguration(config);
To allow users to disable the car mode and set the night mode the IUiModeManager
interface is used.
The automatic night mode switching will be added in a separate change.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Binary XML file line #37: Error inflating class <unknown> after adding a secondary account
Now that I have these debug logs, I want to keep them since they will make
debugging these kinds of issues a lot easier in the future. (Note in this
case there was no problem in the framework.)
Change-Id: If2b0bbeda4706b7c5dc1ba4a5db04b74f40e1543
|
|
|
|
|
| |
We now hopefully do better about generating the anr reports, and include
information about the malloc loaded assets in meminfo.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
attribute in QVGA
It turns out we were not returning the density for anything retrieved from a
TypedArray... which basically means any bitmap references from a layout or style...!!!
This is now fixed.
Also fiddle with the density compatibility mode to turn on smoothing in certain situations,
helping the look of things when they need to scale and we couldn't do the scaling at
load time.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|
|