Every RenderSession would call the AttachInfo.setAttachInfo but wouldn't
issue a View.dispatchDetachedFromWindow.
This caused some Canvas to be slowly leaked in the DelegateManager in
every session.
Change-Id: Iec418a86f5c5e55c2a2860ef945268c51c0e8173
Every RenderSession would call the AttachInfo.setAttachInfo but wouldn't
issue a View.dispatchDetachedFromWindow.
This caused some Canvas to be slowly leaked in the DelegateManager in
every session.
Change-Id: Ib0392303e6d00a4fe5494ae484f28135b1fe6b28
Every RenderSession would call the AttachInfo.setAttachInfo but wouldn't
issue a View.dispatchDetachedFromWindow.
This caused some Canvas to be slowly leaked in the DelegateManager in
every session.
Change-Id: I0322767e5fffc6053ce1be852dd8ca904dfaa137
Backup requires both CE and DE storage to be available, so delay
spinning up the backup system until the user is unlocked, since
that's when CE storage becomes available. Note that devices without
FBE immediately transition USER_SYSTEM into the unlocked state,
since their CE is always available.
Offer to backup and restore files under both CE and DE. Since DE
is effectively the same as CE, most logic is simply duplicated for
now, but it could be simplified in the future. Since system apps
can force their default storage location to DE, we always build
explicit CE and DE paths.
Add getDataDir() to give clean access to the top-level private data
directory, but disclaim that apps shouldn't create files there.
Bug: 26279618
Change-Id: Ic34a4b330223725db93b1d0f5c9dffc88002c61f
The main build hasn't swtiched to java 8, but lambdas are already used
in layoutlib. This fixes the build break.
Change-Id: I4dd69ebd736179067899f5d86d3608d5fdb03d93
This will process all the classes and replace all the uses of
java.text.DateFormat and java.text.SimpleDateFormat with the
android.icu.text. package implementations. The original ones do not
match the Android platform behaviour.
Change-Id: Id55f103c21117a8d6403bf2124b6c1a0e1fb2f71
Refactor setPackageSuspended into setPackagesSuspended. The rationale
is that the consumers of this API are likely to want to remove
multiple packages at once. Rather than calling the API N times, call
it just once.
The good part is that we already have the broadcast intent for
suspended packages take an array so only one broadcast. Less stress
on the system.
Another good part is that (right now) we only have one consumer of
this API and it will be easy to make changes once this CL goes in.
As a shell command, for consistency only allowed one package at
a time.
Bug: 22776761
Change-Id: Ic8b8cf64d0a288ea3a282bb7b72f9d663b3b0049
Instead of always rebuilding the full ApplicationInfo for a
package when callers are only interested in the suspended status
add a new fast API in Packagemanager (which only checks the
suspended user setting for the requested package and returns
a boolean) and change the appropriate caller code too.
Bug: 26794775
Bug: 22776761
Change-Id: Ide8428ef734479360d5a8a75fd8e0ed8ddf2da7a
We're starting to see more instances of device features that will
increment separately from the SDK API level, such as camera HAL,
GPU capabilities, Bluetooth, and other hardware standards.
This change adds the ability for device features to specify a
version, which is defined to be backwards compatible. That is, apps
requesting an older version of a feature must continue working on
devices with a newer version of that same feature.
When a version is undefined, we assume the default version "0".
Bug: 27162500
Change-Id: If890bf3f3dbb715e8feb80e7059a0d65618482ea
This adds an 'axis' child element to the 'font' element. The 'axis'
element has attributes 'tag' (a four byte identifier) and 'stylevalue'
(a float value) to the parser. This also modifies reading the font file
name in a backwards compatible fashion by using only the direct #text
children of the 'font' element. (Both the Minikin and Skia parsers now
allow the font file name on a separate line in the fonts.xml file).
This information is then passed through to Skia in order to select the
desired variation. The Skia parser already parses this way and has for
some time, so Chrome and WebView can already read this format.
Change-Id: I15623fe864fa92b2bf0705af5e389daedfb77e5c
(cherry picked from commit b8e367fb7428076ff2e4aa2a97adaed1ef806e92)
Prior to this commit in this case of activity pause, with finishing=true
the activity manager will notify us of app visibility and we will begin
an exit animation. When this exit animation finishes, we will destroy
the application surface (unless its eligible for saving). However there
are two cases where this breaks down:
1. The exit animation finishes before the activity thread handles
the stop transition. Many activities stop rendering on Pause
but many do not and it is totally legal to do so. Sometimes this
results in non fatal dequeue buffer errors and sometimes results in
fatal errors with Pixel Buffers, etc...
2. We may resume the activity shortly after asking the window manager
to pause it. If the window wasn't eligible for animation, we will
immediately destroy it after being told of the visibility change
following PAUSE_FINISHING. It's possible for this to complete
before we process the resume. On the other hand the client
happilly processes the resume and transitions back from PAUSE
and then crashes once it attempts to use it's surface.
In this commit we have the activity manager notify the window manager
when an application has actually finished (or we have timed out
waiting). For windows which have not been explicitly removed by the
client, we defer destruction until we have received both this signal
and the animation has completed.
Bug: 26793431
Change-Id: Ib6ee8fbdd1f03450fbbfd62468a19e97774befab
The try catch was to prevent crashing on preview releases of Android
Studio. We don't support them anymore.
Change-Id: I8e33cae98117c0034aea1b56903b623fcb64435e
Databases and SharedPreferences often involve multiple files under
the hood, so developers wanting to migrate them between different
storage contexts should ask us to make sure all relevant files are
migrated correctly.
This makes a best-effort attempt to recover from battery pulls
during migration, while still trying to alert developers to
conflicting files.
Bug: 26668510, 25860525
Change-Id: I9ffa3e8cb6191dfd4237b9466a081d6d77df3ba0
Changes activity manager and window manager to use resizeMode
as defined by ActivityInfo#resizeMode instead of a boolean.
Bug: 26774816
Change-Id: I8cef46d9fba6bfdd21df7da63ed5d5330ad03d4b
When dismissing the docked stack, the fullscreen stack stayed in drag
resize mode because it got a relayout, but because the bounds didn't
change (it switches to the fullscreen layout a bit earlier) it never
called WM.relayoutWindow, so it stayed in drag resize mode indefinitely.
To fix this, introduce forceRelayout in Window.resized(), which makes
sure the client always calls relayoutWindow. Set this to true whenever
drag resizing is changing.
For some very weird reason this also broke that home button was not
responding anymore.
Bug: 26806532
Change-Id: I4b39c1c419a166aa7093c31226f2a4915f642328
Mouse pointer is set to STYLE_GRAB when the drag has started and
reset to STYLE_DEFAULT when the drag has ended.
Resetting the pointer shape to the one defined by an underlying
view will be handled in a separate patch.
Bug: 24415739
Change-Id: I8df0a08c5701a34a48f10ec6b43c2cf2e6362d61
Layoutlib now correctly interprets the translation and scaling
xml attributes of views, by implementing what the Android platform
does in native code.
Change-Id: Ie8465f40ef4508d3c31796200800f12cb8f883a4
In resize modes where we are preserving the main application
window, we need to tell the WindowManager to prepare to replace
the child surfaces, or they will dissapear across relaunches.
Bug: 26070641
Change-Id: I864168688dc320e9280e651f9c5df614f52bc96c
The way Android views deal with their rotation xml attribute is through
native code called for hardware accelerated rendering. So layoutlib
has to bypass that in order to take those attributes into account.
Bug: http://b.android.com/73300
Change-Id: Ieb5bf0567a25a9021491ebf3250cedd0752f7863
The method index in PropertyValuesHolder was using only the method name
+ the number of parameters in the call to index the different properties
methods. This worked ok most of the time because, for a given method
name (let's say setTrimStartOffset), the class is usually the same.
However, if the same method name is used in multiple classes, this will
cause collisions and will most likely crash.
Change-Id: Ie6fa8872c5c5e69e690f4f1bb79191a31bef2a28
