The old way will almost always miss the MAX_SIZE * MAX_SIZE case.
Most of time, it will be fine.
But if the threshold is just fall a bit short from MAX_SIZE * MAX_SIZE, then
it is likely that no generated configuration can be bigger than the threshold.
At the same time, a power of 2 size texture is more likely be used in the new
way. Better for memory alignment (or usage) and potential performance.
b/19966623
Change-Id: I4683fd5dea347158bc05d95cc7d777cc391b7fba
In some cases it is possible for the AppToken.allAppWindows list to
get out of sync with the list of windows known to WMS if the client
doesn't call Session.remove(Window). This can lead to an NPE when
the animation threads runs and the display for the window has been
removed.
Also corrected some method names/scopes I ran across while debugging.
Bug: 19972099
Change-Id: Ib0ae7ede6c506f833bbdd66723b88e7504a61907
Symptom:
Report ANR on wrong activity.
Reproduce steps:
(All launchMode, taskAffinity are default and
without additional intent flag)
Case 1:
1.Launch activity A from launcher.
2.Activity A starts B activity.
3.Press home key.
4.Launch activity A from launcher (B is top).
5.Press back key twice to finish B and A,
A sleep 10s in onResume.
6.ANR will report on launcher.
Case 2:
1.Launch activity A from launcher.
2.Press home key.
3.Kill process of A.
4.Launch activity A from launcher.
5.A sleep 10s in onResume, press back key immediately.
6.ANR will report on launcher.
Possible root cause:
Focused activity will not be updated every time when activity
resumed. (the condition to call setFocusedActivityLocked)
Case 1:
Launcher was stopped and not waitingVisible due to launcher
is not the previous one, then getWaitingHistoryRecordLocked
has no chance to correct the real ANR activity.
Case 2:
Due to process of next activity is died, bring existed
task will not set mResumedActivity (it will be set when its
process is started), so when assigning waitingVisible from
processStoppingActivitiesLocked, the return value of
allResumedActivitiesVisible will be true even there is no
mResumedActivity. That results set waitingVisible to false
to previous activity (e.g. launcher), then also cannot
correct ANR target as case 1.
Change-Id: I0b24f46a8fab266382ebc6e2ed84ebeca9358768
This currently truncates all strings at the first NULL character,
except for vendorInfo, which is an opaque string.
Bug: 19985674
Change-Id: Ie53b2c55eb8a5204d7b2c7e2d8587743d923647a
The new AndroidManifest activity attribute, lockTaskOnLaunch attribute
is a boolean that puts the system in lockTask mode when true and if
the activity specified is the root of a privileged task.
This bug also fixes lockTask mode for root activities that finish
themselves. Previously finish was not allowed even if there were
activities left in the task that were still valid.
A NullPointerException for lock task toasts has also been fixed.
Fixes bug 19995702.
Change-Id: Iba6976b1a0cc5a22eb526db66d2e9af66445541f
The install permissions for a shared user were clobbered when a pending
package for this user was matched to the shared user after reading the
state from XML. The reason was that the copy code in PackageSettingBase was
using the getter to get its settings state to which to copy the permissions
for the pending package but this is the permissions state for the shared
user instead of the package. Since the pending package has no permissions
we ended up clobbering the permissions for the shared user.
bug:19955926
Change-Id: Ia8d090883d50fc987a32ceeed6c7562c49698328
If setAppVisibility() is called multiple times in a short interval
while the screen is turned off between the calls, the visibility of
the app would be wrong. For example, the user may see the app under
the launcher, not the wallpaper under the launcher.
The flow to the issue:
1. Screen is on.
2. AM calls setAppVisibility() token=App A's token, visible=true
3. Screen is turned off.
4. AM calls setAppVisibility() token=App A's token, visible=false
Note:
a. In 2., WM would put App A into mOpeningApps, and tell it to be
visible.
b. In 4., because the screen is off now, App A would not be removed
from mOpeningApps. App A might be told to be invisible directly
through setTokenVisibilityLocked(), but it would be told to be
visible again in handleAppTransitionReadyLocked() later.
Change-Id: Icf3d69031ea2822245008248ec8f12bd57218880
- Adds a camera service to system server that forwards events to the
mediaserver camera service.
- Notify the camera service when the device user changes.
Bug: 19186859
Change-Id: I172a2ce46c8e8a131ae7e8dd99d60c5f4f0d6668
This CL mostly affects Settings app as it can run in a user different
than UserHandle.OWNER. Since it is a system app it should have access
to all uid's data usage, regardless of which user it is currently running
in.
Bug: 19967498
Change-Id: I4a7787134d998457f7e2a1029183d44d9584083e
Symptom:
System server crash.
Root Cause:
The value curProcState for array index is -1 if the process
has not attached yet.
Solution:
Skip computing for process which is not attached or curProcState
is nonexistent state.
Change-Id: I71aaf45bb78d73097ebe9dfebf76b72f2d243232
Storage devices are no longer hard-coded, and instead bubble up from
whatever Disk and VolumeBase that vold uncovered, turning into
sibling Java objects in MountService. We now treat vold events as
the source-of-truth for state, and synchronize our state by asking
vold to "reset" whenever we reconnect.
We've now moved to a model where all storage devices are mounted in
the root mount namespace (user boundaries protected with GIDs), so
we no longer need app-to-vold path translation. This also means that
zygote only needs to bind mount the user-specific /mnt/user/n/ path
onto /storage/self/ to make legacy paths like /sdcard work. This
grealy simplifies a lot of system code.
Many parts of the platform depend on a primary storage device always
being present, so we hack together a stub StorageVolume when vold
doesn't have a volume ready yet.
StorageVolume isn't really a volume anymore; it's the user-specific
view onto a volume, so MountService now filters and builds them
based on the calling user. StorageVolume is now immutable, making
it easier to reason about.
Environment now builds all of its paths dynamically based on active
volumes. Adds utility methods to turn int types and flags into
user-readable strings for debugging purposes.
Remove UMS sharing support for now, since no current devices support
it; MTP is the recommended solution going forward because it offers
better multi-user support.
Simplify unmount logic, since vold will now gladly trigger EJECTING
broadcast and kill stubborn processes.
Bug: 19993667
Change-Id: I9842280e61974c91bae15d764e386969aedcd338
If a scheduled full-data backup was attempted but the device had not yet
run the primary key/value backup pass, the full-data backup scheduler
would wind up in a bad state and potentially never retry until reboot.
We now properly reschedule a future retry, using the key/value
scheduling batch quantum as a backoff to be sure to give it a chance
to run before the next time full data is attempted.
Change-Id: Ic7eb7a7940fe6380f40d04813a46fc336e95815e
Added new restriction types - bundle and bundle-array.
Modified RestrictionsManager.getManifestRestrictions to support new
hierarchical restrictions.
Added RestrictionsManager.convertRestrictionsToBundle, which enables
programmatic conversion from a list of RestrictionEntries to a Bundle.
Modified read/write methods for application restrictions in UserManagerService.
Added unit tests.
Bug: 19540606
Change-Id: I32b264e04d5d177ea5b4c39a8ace5ee0ce907970
