When user reset password their password,
if password doesn't match target quality of device,
DPM print a log why can't reset password.
however log message isn't correct information.
in log context, it have to exist current quality
and target quality. this patch can help print correct log.
Change-Id: I5c8fb1c77ddbe1bdbc76e35038c897e2e8efb077
Use a Bundle for persisting and passing to the application, but use a
list to return data back from an application that's exposing restrictions.
Changed the xml reading/writing code to store the value type in the Bundle
so that it can be reproduced when reading. Earlier we were assuming only
String and String[].
Bug: 8633967
Change-Id: I523d5553728edcf28a1e9d432f490b4956f34215
We're missing some (small fraction of) native crash reports from
debuggerd. It looks like under high system load the debuggerd
reporting code just isn't quite timely enough for the very short
timeouts initially deployed, so lengthen those a bit.
Bug 8552010
Change-Id: Icbc5b6517de3bb98fff1af2ea42ffd208ef20412
For the purposes of deciding whether or not to invoke the
"fallback vibrate", that is. (RingtonePicker will return
content://settings/system/notification_sound when "Default"
is chosen, so if the app pops this Uri directly into
Notification.sound, we should treat it like DEFAULT_SOUND
and look to see whether the system notification sound is
not None before running the fallback vibration.)
Bug: 8627641
Change-Id: Ia469b8e4d5d7647ce1a8a179f591ed7a3443b5c5
- Max 250 notifications preserved (was 1000)
- Known heavyweight extras are removed
- print some of 'em out in dumpstate, while we're at it
Bug: 8280039
Bug: 8537938
Change-Id: I9239128c32a1d9f5ef4e0dc62dc2d23e190871e9
* commit 'feedb1b095f94e4bd153aeee78da07d963892071':
Fix security issues with LocationManager where apps with coarse permissions can get location updates too frequently by repeatedly calling getLastKnownLocation or by registering/unregistering location updates frequently.
It is possible that an accessibility service's package was force stopped
during whose handling the death recipient is unlinked and still get a call
on binderDied since the call was made before we unlink but was waiting on
the lock we held during the force stop handling. Added a check whether the
service is already disconnected and if so do nothing.
bug:8600388
Change-Id: I4a9ca305b9863d986b930a7c1ec8f9006b16a333
can get location updates too frequently by repeatedly calling getLastKnownLocation
or by registering/unregistering location updates frequently.
Change-Id: Ibd9ce28b0401372b995a0dbfb2f0a984dd11c0b1
On eng builds we have an event consistency verifier to log any
inconsistent event stream states due to mishandling of intercepted
events by an accessibility service. On non-eng builds this verifier
is null and a null check was lacking.
bug:8616711
Change-Id: Ib083a405dfa8340025090a65e50155eb10526a90
If the connected service is not entirely setup when calling the method for
handling a change in the current user state we get a potential NPE since
the management method may have discarded the service, thus nullifying the
connection to it. Now the service is fully configured before calling the
state change management method.
bug:8600489
Change-Id: Ib0bf7c6d575e15c620da419d43ece22f4187fd34
This covers all useful data from the basic Builder as well
as each of the Styles that is not otherwise captured on the
Notification object itself.
Extras are now prettyprinted in dump() output.
Bug: 8270485
Change-Id: I47fc50860dab6409793f57e904cc60296310d5cf
