When the screen goes off or dreaming start, an alarm will be
scheduled and idle state will be true when the alarm expired.
If the screen goes on or dreaming stop happens before
the alarm expired, the alarm isn't cancelled and idle state is
set to be true when the device is in SCREEN_ON or DREADING_STOPPED
state. There is also a case that Idle alarm triggered when
the screen on or dreaming stop just start to be processed.
ACTION_TRIGGER_IDLE will set mIdle to true during screen on
or dreaming stop.
In this patch, the alarm will be cancelled when the screen goes
on or dreaming stop and screen-on flag will be set. So the idle
state can only be set when screen is off or dreaming started.
Change-Id: I06ae4b7fd77901f9570ce0459d2299bbfd4b46b4
With this patch, when the user requested shutdown,
PowerManagerService sets sys.powerctl is set to
"shutdown,userrequested", and init runs fsck on shutdown.
When shutdown is triggered due to a low power state etc.,
the service sets the property to "shutdown,", and init
immediately shuts down the system without running the
command.
This is a follow-up CL for http://r.android.com/158525.
Bug: 21853106
Change-Id: Iae72990130fe9aa479c802f77301438190dbbfb3
It is possible that jobs.xml does not have valid content
if the device meet unexpected power off or reboot during
writing the file, then parser.getName() may get null string
on next boot.
Because log does not allow to print null message.
It will result boot fail:
Caused by: java.lang.NullPointerException: println needs a message
at android.util.Log.println_native(Native Method)
at android.util.Slog.d
at com.android.server.job.JobStore
$ReadJobMapFromDiskRunnable.readJobMapImpl
Change-Id: Icd485096e2f00f4028428a9ad95cd0ef66b2dca0
In the move from InetUnixAddress to UnixSocketAddress
commit e9d537506bf19375fb932ac7d25ac9a9e3aef61d did not modify
the Os.accept() call in NativeCrashListener. It was passing
an empty InetSocketAddress.
The type could have been changed, but the peer address is
never used and it is safe to pass a null.
Bug: 3106438
Change-Id: I2a61221c4504657b3e1de848b0b493f202726126
If user install apps from playstore, system has installerPackageName attribute of app.
but, after reboot, some apps(have sharedUserID) installerPackageName attribute disappearing.
because lack of copy routine.
So, I added copy routine(installerPackageName).
Testcase :
1. Install app(has sharedUserId, ex Lync2013) from market.
2. Confirm package info from packages.xml(exist installer info).
3. reboot.
4. Re-confirm package info from packages.xml(not exist installer info).
Change-Id: I5f9597b0f0f23be21efdfc7c7780ce7cfd2b9672
In the scenario that you connect more than one device to android phone with an usb hub,
when you attach the second device,mNewConfigurationis is still corresponded to the first
device unless another mNewConfiguration is created by a new operation.
However,before another mNewConfiguration is created,setInterfaces() in addUsbConfiguration()
has already been executed. Problem is that mNewInterfaces has already been cleared when
it finished endUsbDeviceAdded for the first device. As a result,the UsbInterface descriptor
in the first device's Configuration descriptor is set to null.
Change-Id: I0ba4f07c809d07ebebed633e43c3ee8e2e4c5060
When calling the methods
com_android_server_PersistentDataBlockService_getBlockDeviceSize()
com_android_server_PersistentDataBlockService_wipe()
memory is leaked because string created by
GetStringUTFChars() is not released.
Use ScopedUtfChars instead to ensure that memory is released.
Change-Id: I880a6d66a4824778b411b858774b8ffa009c1e17
The new option "--track-allocation" is to work with the new
allocation tracker in ART.
Bug:20037135
Change-Id: Ic5f8945ab4c1f167c27b05ad0d11d04bac680c1f
While in computing surface crop region, magnification specs are
not applied to surface insets from LayoutParams.
So, in case magnification specs are set,
surface crop region should be calculated considering scale factor.
(For instance, using TouchZoom in Accessibility
at AppsPermissionActivity in market app)
Bug: 20863078
Change-Id: I9e7e21e502b29208f2856918d6fcda050f515595
Signed-off-by: Seunghyun Lee <seunghyun85.lee@lge.com>
To address the UX comments, this CL modifies the dialogs when the
device is rebooted to install an update or to perform factory data
reset.
Bug: 20949086
(cherry picked from commit 81dce6631396012e8b722bbed6d003f584800ae1)
Change-Id: I6d0cbbbaf184806366c6581c1c2e7dbcc5d89a17
/system/bin/uncrypt needs to be triggered to prepare the OTA package
before rebooting into the recovery. For larger packages, uncrypt may be
killed before it finishes the work after the timeout. Change to monitor
the uncrypt status and show the progress to user.
Needs matching changes in bootable/recovery/uncrypt, system/core and
external/sepolicy.
Also pick up the two NPE fixes in commits
9bb765448df43d41e0a3edb7de1d1641c9251c35 and
da3f63ffb87397943546a7c5c893ce98f2489df2.
Bug: 20012567
Bug: 20949086
(cherry picked from commit 90237f7beb55dae79cdcba5271f96be778573737)
Change-Id: Ibf2fc80032967e5f6cda3cd469005dd29665c87c
If there is an Activity Z of Task T needs be visible but
isn't running, and the process P of Z is existed, it will
just to schedule launch Z.
The problem will happen when P is died (e.g. kill itself)
right before scheduleLaunchActivity. Once RemoteException
is caught, startSpecificActivityLocked will try to restart
the process and run cleanup procedure because the process
record is existed (death recipient of P has not entered AMS
yet). And assume task T contains X, Y, Z. X and Y have
declared stateNotNeeded=true, so X and Y will be removed
from task T.
Now the size of task T changes from 3 to 1. And because
activityNdx=2 when updating Z, the next round (--activityNdx)
will have exception at activities.get(activityNdx):
IndexOutOfBoundsException: Invalid index 1, size is 1
The ActivityRecord in TaskRecord is removed by below flow:
ActivityStack.ensureActivitiesVisibleLocked
ActivityStackSupervisor.startSpecificActivityLocked
ActivityStackSupervisor.realStartActivityLocked
ApplicationThreadProxy.scheduleLaunchActivity -> IPC fail
ActivityManagerService.startProcessLocked
ActivityManagerService.handleAppDiedLocked
ActivityStackSupervisor.handleAppDiedLocked
ActivityStack.handleAppDiedLocked
ActivityStack.removeHistoryRecordsForAppLocked
ActivityStack.removeActivityFromHistoryLocked
task.removeActivity(r) -> mActivities.remove(r)
There is also similar patch to solve the same problem:
https://android-review.googlesource.com/143780/
Change-Id: Iac646bcb8ed3d3cfb2bda14e05e11abfcfe980d1
Here's overflow/underflow problem in comparators.
"when1 - when2" may suffer in overflow/underflow condition.
Comparing them directly can avoid this problem.
Change-Id: Id46af3db2adac90654210182d26ade1986ee0661
The comparator used variable "when" in IncreasingTimeOrder class.
variable "when" means "elapsed time" or "real time"(RTC) and these types have different unit of time.
so, I recommend that you use a "whenElapsed" which has the equal unit of time as its default value.
Change-Id: I248863ef8a5c49cc7114cb2965f3d6b78f4faa59
Signed-off-by: Jinho Park <jinho.park@lge.com>
Passing null to XmlPullParser.setInput forces it to do additional
work, which can be easily avoided if we know the charset beforehand.
bug: b/20849543
(cherry picked from commit 9e9e2e73c6ec7bece20268196dc89ad0c8bafad4)
Change-Id: Iaff97be9df2d0f99d7af8f19f65934439c9658e2
We don't dex2oat during application moves, so we must scan
the package again scanPackageDirtyLI to deduce its ABI.
This is unnecessary (since a move cannot change ABIs), but we
need some additional refactoring to avoid a second scan.
bug: 21337469
(cherry picked from commit cd251fa382e887f59c278d4d7cd0a858812c6114)
Change-Id: Id1ed3bdfabb41e05e6a2f7efbd05d2103a67c663
Allows us to proceed without crashing the system process. Also,
complete an incomplete error message. Follow up comments from
change b904863476991d8540d37d5.
bug: 21144503
(cherry picked from commit c52ae28006605fb2da38b305b60b9bb419aa2f80)
Change-Id: I47b8762449714162fcd5c16eba6fcc146b93120b
This requires a minor refactor to extract the ABI detection logic
out of scanPackageDirtyLI.
Note that there's a minor regression here : we ignore the
cpuAbiOverride from the package settings when calculating the
CPU ABI. This is OK (and possibly better behaviour) because this
is only a debug only option (for adb install) AND because the instructions
require users to specify the abi override on every adb install
invocation. Furthermore, the behaviour when an ADB installed app
(with an override) is auto-updated is more consistent.
bug: 21144503
(cherry picked from commit b904863476991d8540d37d542c0a49b78deab680)
Change-Id: I1eb88b808fd2e90e14c32322131659220aafdb7a
Currently installation fails, if an app is located on SD card (inside ASEC).
If an app is located inside ASEC, dexopt output should go to
/data/dalvik-cache. dexopt also needs to be performed at a later stage,
because the name of the oat file contains the absolute path to the dex file.
Bug: 20452651
Bug: 21360107
(cherry picked from commit 94056d1cb8183bde3e942336735b289b9654deb1)
Change-Id: Id1ced7159e5af9c05be0b637437b3b260e859c1d
Just above the SecurityException is a check for r.record == null,
thus dereferencing r.record will cause a null pointer exception.
Found in Android 4.3 with the following steps:
1) Start the music app.
2) Switch to the restricted user.
3) Navigate to Settings->Apps->Running->Music.
4) Tap the stop button.
The security exception should be thrown which results in
a nice message to the user, but instead a null pointer
exception is thrown which results in the settings app
crashing.
Change-Id: I4a306c38650c9d366896e592767dde70adb71c57
The NotificationManagerService limits the number of
notifications per package+user to 50. Once that limit is
reached, it will refuse new notifications. However, it was
also erroneously refusing updates to existing notifications.
Bug: 5821364
Change-Id: I3aa4be9ad4b288e4a22bf7a64f67521695dfb579
WindowManagerService received X and Y offset steps but failed to pass
them off to the relavent wallpaperservice.
Live wallpapers expect a valid value for xOffsetStep and yOffsetStep
when the WallpaperService.Engine::onOffsetsChanged function is called
As specified here:
https://developer.android.com/reference/android/service/wallpaper/WallpaperService.Engine.html
onOffsetsChanged(float,float, float, float, int, int)
See bug report:
https://code.google.com/p/android/issues/detail?id=173607
Change-Id: I532dedf2db055e27d6eca813e30346e37f52dc65
(cherry picked from commit e03ea68d0a7f7d7c60663feae587225cca3a3a5b)
Case 1 (name == null):
Switch user from guest to owner. All processes of guest
will be killed, it will not include processes which singleton
components live in, but singleton provider records are still
collected and removed.
When the user switch is complete and the process of removed
singleton provider is still alive, there is someone access
the provider, it will create a new ContentProviderRecord and
wait but no one will notify it because the provider process
is alive with different ContentProviderRecord.
Then the access cannot get response unless the process of target
provider is died and restarted.
Case 2 (name != null):
Switch to another non-guest user, launch an application which
contains singleton provider. Go to Settings to force-stop the
package then switch back to owner user. Launch an application
which will access the singleton provider. It will also cannot
get response that similar as case 1.
Solution:
Only collect singleton provider if target user is all or owner.
Change-Id: Ic6828da66645172d1378cfb1f66d092df5966516
e.g. ContentResolver.getType will call
ActivityManagerService.getProviderMimeType
that will not have connection but increase
externalProcessNoHandleCount.
Change-Id: I649c0b2390a749c77c6be5e7dfadc1acb689ec4c
Add KeyStore.onUserPasswordChanged for the lockscreen to call when
the user changes their password. Keystore will then handle the logic of
deleting keys. Instead of calling Keystore.password_uid for both
unlocking and password changes the behavior has been split into
Keystore.unlock and onUserPasswordChanged.
(cherry-picked from commit a91a8504191d91d288c55821caa5bf00c9be26a2)
Change-Id: I324914c00195d762cbaa8c63084e41fa796b7df8
The original logic would use out-of-date parent sizes to initialize
animations. If the screen size is changed after assigning mAnimDw and
mAnimDh in the constructor of WindowStateAnimator, the fromDeltaY
(in the most cases) of TranslateAnimation would be initialized
incorrectly.
In this change, we always use up-to-date parent sizes to initialize
animations to prevent the issue.
https://code.google.com/p/android/issues/detail?id=170348
Change-Id: Ib9c609121228934bdb463263feb1924eb389c1d2
