The new system and UX sound volume policy makes that STREAM_SYSTEM
volume is not fixed anymore. It is tracking STREAM_RING (phones) or
STREAM_MUSIC (tablets) in a constrained range between -24dB and -6dB.
Sound Fx where previously played over STREAM_SYSTEM with a fixed
attenuation of -20dB. The default value of 5% in the keypress sound
volume setting was corresponding to -26dB, meaning 6dB below default.
Modified the default volume value to 50% so that by default, keypress sound
volume varies from -30dB to -12dB which is also 6dB below the other system
sounds.
Change-Id: I146f72275b8e88fdce5ccf8b6dae2903c27f15eb
* Move SubtypeLocale.get{Full,Middle,Short}DisplayName() to
LatinLeyboardView and add unit tests (SpacebarTextTests).
* Add SubtypeLocale.getSubtypeDisplayName()
This is a cherry-pick of I57420c6a from Master.
Bug: 6393865
Change-Id: I68748189c17c73984ac4ae05a5a40fb54bf46453
This is not the Right fix ; the Right fix would be to read
the file in a buffered way. However this delivers tolerable
performance for a minimal amount of code changes.
We may want to skip submitting this patch, but keep it around
in case we need to use the functionality until we have a good
patch.
Change-Id: I1ba938f82acfd9436c3701d1078ff981afdbea60
The core reason for this is quite shrewd. When a word is a bigram
of itself, the corresponding chargroup will have a bigram referring
to itself. When computing bigram offsets, we use cached addresses of
chargroups, but we compute the size of the node as we go. Hence, a
discrepancy may happen between the base offset as seen by the bigram
(which uses the recomputed value) and the target offset (which uses
the cached value).
When this happens, the cached node address is too large. The relative
offset is negative, which is expected, since it points to this very
charnode whose start is a few bytes earlier. But since the cached
address is too large, the offset is computed as smaller than it should
be.
On the next pass, the cache has been refreshed with the newly computed
size and the seen offset is now correct (or at least, much closer to
correct). The correct value is larger than the previously computed
offset, which was too small. If it happens that it crosses the -255 or
-65335 boundary, the address will be seen as needing 1 more byte than
previously computed. If this is the only change in size of this node,
the node will be seen as having a larger size than previously, which
is unexpected. Debug code was catching this and crashing the program.
So this case is very rare, but in an even rarer occurence, it may
happen that in the same node, another chargroup happens to decrease
it size by the same amount. In this case, the node may be seen as
having not been modified. This is probably extremely rare. If on
top of this, it happens that no other node has been modified, then
the file may be seen as complete, and the discrepancy left as is
in the file, leading to a broken file. The probability that this
happens is abyssally low, but the bug exists, and the current debug
code would not have caught this.
To further catch similar bugs, this change also modifies the test
that decides if the node has changed. On grounds that all components
of a node may only decrease in size with each successive pass, it's
theoritically safe to assume that the same size means the node
contents have not changed, but in case of a bug like the bug above
where a component wrongly grows while another shrinks and both cancel
each other out, the new code will catch this. Also, this change adds
a check against the number of passses, to avoid infinite loops in
case of a bug in the computation code.
This change fixes this bug by updating the cached address of each
chargroup as we go. This eliminates the discrepancy and fixes the
bug.
Bug: 6383103
Change-Id: Ia3f450e22c87c4c193cea8ddb157aebd5f224f01
* Remove keyXPos and keyWidth from key_*.xml and make it more generic.
* Add keyXPos and keyWidth to <include/> generalized key_*.xml.
* Remove zero width <Spacer/> and fold into successive <include/>.
Change-Id: I4b5c02a165ba0bc9ef8741be0b4938c1efaf5e27
This would end up in TextView sometimes calling onUpdateSelection
multiple times (this is the correct behavior for TextView). We now
commit the space and the word in a batch edit, and we only get
onUpdateSelection once.
Bug: 6300527
Change-Id: I9579f3d8f5320c1cc24a7a42f19db8e105eb090d
We need to get the bigrams during the call to getSuggestions for
bug#6313806. We already give an int[] to getSuggestions and we
wanted to get rid of char[]'s anyway because it doesn't work with
surrogate pairs, so here we go.
Bug: 6313806
Change-Id: I56ce99f1db6b3302cdf42f0527343bded837091e
* Remove duplicated xml-sw768dp/keys_apostrophe_dash.xml
* Separate keys_apostrophe_dash.xml to key_apostorhe.xml and
key_dash.ml
* Separate key_space.xml from row_qwerty4.xml
* Separate key_f1.xml from xml{,-sw600dp}/row_qwerty4.xml
* Separate keys_f1f2.xml from xml-sw768dp/row_qwerty4.xml
* Fix incorrectly named rows_symbols{,_shift}4.xml to
row_symbols{,_shift}4.xml
Change-Id: Id71967a016a348174d1fc265b654dbc233c6562e
satok
Eric Fischer
Tadashi G. Takaoka
Jean Chalard
Ken Wakasa
Eric Laurent
Tom Ouyang
Svetoslav Ganov