When calculating scroll amount, we should check whehter focus
is visible using before-scrolling position.
It's possible that the view is already scrolled, then visible
insets changes (eg. IME went away). Previous scroll position
still makes the focus visible, but it will leave the focus
in a bad position when it should be scrolled back.
bug: 29025892
Change-Id: I091f16bebc4c1e5ba831616c51ab2ac75d4c4b3c
am: 5a6cf3ac9a
* commit '5a6cf3ac9a3945c2d1f0e5e28ffda9e52124eb15':
Work on issue #29042642: Watchdog going off
Change-Id: I2a3b120648aef7401bb6d4c2460f868cdc16c1a0
-> Android Framework changes to add support for
an API to send indicator change in AG.
-> Added a system intent for broadcasting assigned number(ID)
of the supported HF indicators and their values (if received)
Bug: 19983867
Change-Id: If26a7ae5da5686da72ebca9ec3decfe086e2ffb6
Have FastPrintWriter note all cases where an exception is
thrown, and stop trying to push more data into the output
stream when this happens.
Change-Id: I51a1eeb26578f02b2a6f45ef7bc2513dfde702a2
When ejecting a storage device, the system process needs to rapidly
release any open FDs to prevent itself from being killed by vold.
This change examines all ResourceImpls cached inside the system
process and evicts any that reference the storage device being
ejected. (ResourcesManager will gladly recreate any evicted entries
when asked again in the future.)
Also replace broken use of WeakHashMap, since we want the values to
be weak references, not the keys.
Bug: 28867548
Change-Id: Ib9cfc66497149b6d3f8d49213e9779408a331d2a
Negative values of the field CONFIGURATION_STATE, DATA_CHANNEL_STATE,
NOTIFICATION_CHANNEL_STATE is reserved to voicemail source for its'
specific errors. SOURCE_TYPE can be set to help interpret the error
codes.
Typically the OMTP visual voicemail source will set SOURCE_TYPE to the
same value of visual voicemail type set with
CarrierConfigManager.KEY_VVM_TYPE_STRING, such as "vvm_type_omtp".
For example, the OMTP visual voicemail source could set
CONFIGURAITON_STATE to -5 and SOURCE_TYPE to "vvm_type_foo", and the
client can find -5 for "vvm_type_foo" means "PIN is not set by the user"
+ Field SOURCE_TYPE
+ Docs to specify negative values are reserved for the source
- Removed hidden helper method SetStatus() and SetQuota(). The 'ignore'
value is conflicting with reserved values.
Bug:26944391
Change-Id: I0930f684dadd25ae94e3ea68a7658c7ae423e3e3
The words "title" and "text" implies that "text" is a secondary label
that's shown with the title, but it turned out the launcher would show
only one of those depending on how much space it has.
So now we change them to "shortLabel" and "longLabel"
Note we're only changing the API surface -- in order to mimimize
the impact to the code, internally we'll keep using the old names.
- Also remove "shortcutRank" while I'm here -- it should be implied
from the order of the XML elements.
Bug 29057378
Change-Id: I3203f63b0318c7462c1c61fef43cf9755fa8c008
am: c16bc88fc9
* commit 'c16bc88fc99a6446c77d0b075f242c042bb31ded':
trim and strip html tags for load safe label name
Change-Id: Ic79f077813fcf2124fe1cbf031cb4e0770a02a51
Currently, if a priv-app sends ACTION_MASTER_CLEAR, whilst
DISALLOW_FACTORY_RESET is set, the factory reset is blocked. This CL
introduces a new extra for master clear that let's the priv-app bypass
the user restriction.
Bug: 28689894
Change-Id: I4bf979a3826454e977f1abff4562f85c8d0eec4a
Currently if an action mode is started in onCreate()
it will fade in. This isn't ideal though, especially
since Activities are recreated routinely with
multi-window and resizable Activities. In that instance
we fade it in on every recreate.
This CL fixes this in both the decor and toolbar action
modes to only fade in if the decor has been laid out.
BUG: 29036694
Change-Id: Iae985efcced170a0a4229124c1c132355c2aa71e
am: 88be465ce5
* commit '88be465ce572f84649e01744a7ec96b6346b3686':
Update override config to include some changes from global config
Change-Id: I2b15d9856f87e66ae9eb1ab6c9b84f7ac3add2ce
We now have a new settings key that provides all of the existing
tuning parameters, plus some newly redone ones for dealing with
different memory levels.
Changed the minimum batching for overall jobs from 2 to 1, so
we will never get in the way of immediately scheduling jobs
when the developer asks for this. We should now be able to rely
on the doze modes to do better batching of jobs for us when it
is really important.
Also work on issue #28981330: Excessive JobScheduler wakeup alarms.
Use a work source with scheduled alarms to blame them on the app
whose job they are being scheduled for, and add a check for whether
a job's timing constraint has been satisfied before considering it
a possible candidate for the next alarm. (If it is satisified,
the time is in the past, so we should not schedule an alarm for it.)
Finally clean up a bunch of the dumpsys output to make it easier
to understand.
Change-Id: I06cf2c1310448f47cf386f393e9b267335fabaeb
am: cd0aa9cda8
* commit 'cd0aa9cda8e57c224b473198a345fb008fe30b5a':
Don't bother with WeakHashMap for direct alarm bookkeeping
Change-Id: I3b28a8c03cee7fe6f85540f1f679de10de09923c
This fixes a bug where APK JAR signature verifier returned the wrong
certificate chain. Rather than returning the cert chain of the
verified SignerInfo, it was returning the bag of certs of the PKCS#7
SignedData block.
This issue was introduced in Android N and thus does not affect
earlier Android platform versions.
Bug: 29055836
Change-Id: I684c0f8e9ff47b922030645e07b6a114c0eb0963
