Breadcrumbs move to the action bar on certain configs.
Padding around fragments and to the left of preference items
adjusted for different display sizes.
Change-Id: Ie899f9742f4ebd7044f158b1c7db06df82ad2d75
When the version is reported as a codename, use the previous version
in the user agent string.
Bug: 4347787
Change-Id: I4ed804a7334d6ca242446176ff042c4ac7938a0f
The current browser pause/resume logic uses an integer count to track
the pause/resume behavior, which is mostly working fine in phone. The interger
count is usually 0 when browser is paused, and its value is usually 1
when the browser is resumed and will trigger any delayed timer.
But in tablet, where tabs can be easily created/switched/deleted, this
logic will not work well and sometimes cause resources timers get stuck.
For example, in case multiple tabs are created, and you reload one of the
tabs, when it's almost finished, switch to another tab, and hit home or power
button, at this point of time, the browser will be suspended at
Controller.java::onPause, hence the integer count will be 0; but since
the other tab is also finished after the pause, the current logic at
Controller.java::onPageFinished will call pause timer again, which will make
the integer count to be -1. Before the time the browser is resumed, it's very
possible some tabs will have some resources, such as images/flashs,
scheduled to be loaded, these will be in delayed timer in
ResourceLoadScheduler.cpp's m_requestTimer.
Now when the browser is resumed, the integer count will be 0, which will not
trigger delayed timer. Then all the new timers will be stuck as well since
old timers are not executed yet.
The fix is to simplify the pause/resume logic by just using a boolean variable
instead of error-prone integer counting.
issue: 4177932
Change-Id: Id10af9298c7be1f82222d0b94c34c5dc68403630
* commit 'bdc26dc34a5d848883d5acdee62f5b4403e8fe04':
Change measurement of effective screen height for PopupWindow now that DisplayMetrics reports it without system decorations.
* New opaque assets (now actually opaque!)
* SearchDialog determines theme to use from parent context
* SearchDialog now disallows action modes
Change-Id: If05fe64d7cc4460678d78412275ee988ddb47e9e
The previous fragment implementation allowed for animations
during fragment transitions, but did not account for the
different behavior of fragments when popping the back stack.
In general, you probably don't want to run the same animation
for putting a fragment on the stack as for popping it off, which
is what happens now. For example, you might fade a fragment out when
putting it on the stack. But when popping ot off, fading it out
is probably not the behavior you want.
The new API (setCustomAnimations() overload with two additional
parameters) allows developers to specify animations to be run
in the popping operation. Otherwise, the animations are null and
the operation will not be animated.
Change-Id: I53bbc6e6ec4e953b7ecdd99e2452d81857917de2
Handles the scenario of radio technology handover with IP continuity.
Once RIL/Modem finished a handover operation, an unsol data call state
change will be send up to FW notifying all link propertes changes.
FW will then re-configure the device with new link properties
including iptable used by Tethering.
Change-Id: I05e29f66ac3db8ba4274d3662642607742ba1d12
This ID is used for MTP as well as per volume querying in the media provider.
Change-Id: Ic4fc986d972bd477730643f7e9450c390c0b3a4b
Signed-off-by: Mike Lockwood <lockwood@android.com>
* commit '0eac092766d7871b34927442ee0b6e27e7e1317b':
DO NOT MERGE. From main -- Start work on simulating landscape/portrait when orientation is locked.
Not yet working, so turned off.
Also fix a bug where the display size configuration became inconsistent
after a configuration change -- we now figure out everything about the
display size when computing a new configuration.
Change-Id: Id155f133c0bf108508a225ef64ed3ca398a90a58
