* changes:
[automerger] Optimise the hit test algorithm am: 71ecf5bd5c am: 42eaa8f932 am: a72cb45f89
[automerger] Optimise the hit test algorithm am: 71ecf5bd5c am: 42eaa8f932
[automerger] Optimise the hit test algorithm am: 71ecf5bd5c
Optimise the hit test algorithm
* changes:
[automerger] Optimise the hit test algorithm am: 71ecf5bd5c am: 42eaa8f932
[automerger] Optimise the hit test algorithm am: 71ecf5bd5c
Optimise the hit test algorithm
Layout#getOffsetForHorizontal was running in O(n^2) time, where n is the
length of the current line. The method is used when a touch event
happens on a text line, to compute the cursor offset (and the character)
where it happened. Although this is not an issue in common usecases,
where the number of characters on a line is relatively small, this can
be very inefficient as a consequence of Unicode containing 0-width
(invisible) characters. Specifically, there are characters defining the
text direction (LTR or RTL), which cause our algorithm to touch the
worst case quadratic runtime. For example, a person is able to send a
message containing a few visible characters, and also a lot of these
direction changing invisible ones. When the receiver touches the message
(causing the Layout#getOffsetForHorizontal method to be called), the
receiver's application would become not responsive.
This CL optimizes the method to run in O(n) worst case. This is achieved
by computing the measurements of all line prefixes at first, which can
be done in a single pass. Then, all the prefix measurement queries will
be answered in O(1), rather than O(n) as it was happening before.
Bug: 79215201
Test: manual testing
Change-Id: Ib66ef392c19c937718e7101f6d48fac3abe51ad0
Merged-In: Ib66ef392c19c937718e7101f6d48fac3abe51ad0
Layout#getOffsetForHorizontal was running in O(n^2) time, where n is the
length of the current line. The method is used when a touch event
happens on a text line, to compute the cursor offset (and the character)
where it happened. Although this is not an issue in common usecases,
where the number of characters on a line is relatively small, this can
be very inefficient as a consequence of Unicode containing 0-width
(invisible) characters. Specifically, there are characters defining the
text direction (LTR or RTL), which cause our algorithm to touch the
worst case quadratic runtime. For example, a person is able to send a
message containing a few visible characters, and also a lot of these
direction changing invisible ones. When the receiver touches the message
(causing the Layout#getOffsetForHorizontal method to be called), the
receiver's application would become not responsive.
This CL optimizes the method to run in O(n) worst case. This is achieved
by computing the measurements of all line prefixes at first, which can
be done in a single pass. Then, all the prefix measurement queries will
be answered in O(1), rather than O(n) as it was happening before.
Bug: 79215201
Test: manual testing
Change-Id: Ib66ef392c19c937718e7101f6d48fac3abe51ad0
Merged-In: Ib66ef392c19c937718e7101f6d48fac3abe51ad0
Fixes an issue where input intended for the keyguard could end up going
to a different display.
To prevent this, make sure that only the default display can get focused
when the keyguard is showing.
Change-Id: I6463c44aedca06930d2c9bda7c45ffd93141308c
Merged-In: I6463c44aedca06930d2c9bda7c45ffd93141308c
Fixes: 71786287
Test: atest DisplayContentTests
* limit the absolute maximum size of the label to 50000 characters
[which is probably far more than necessary, but, can be dialed down]
* use a string buffer while processing the string [instead of creating
multiple string objects]
Bug: 62537081
Test: Manual. Install APK in bug and see that it can be uninstalled
Change-Id: Ibf63c2691ad7438a123e92110d95b1f50050f8b1
Merged-In: Ibf63c2691ad7438a123e92110d95b1f50050f8b1
