* removed "scale" from the show(...) API
* made the zoom scale a dimension => the widget is
fully self-configured
* fixed the magnifier not always scaling the content
to the full pop-up window size
Bug: 63531115
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: manual test that shows the magnifier working
Change-Id: Ibf5c571970c8f6bd3cdbc6d46fbe57d08291783c
Statsd is now informed for starts/stops/etc of the following events:
BleScan
BleScanUnoptimized
BleScanResult
Sensor
Gps
Sync
ScheduledJob
UidWakelock (aggregate wakelock)
LongPartialWakelock
BatterySaverMode (power save mode)
DeviceIdleMode (doze)
ScreenBrightness
Audio
Video (media codec)
Camera
Flashlight
ProcessLifeCycle
TODO: Note that, although tags are java constants (e.g.
StatsLog.SCREEN_STATE), the values passed in for states do not have java
constants associated with them, so we use literals (0 vs 1 for off vs
on). In the future, when corresponding java constants exist, these can
be updated.
Test: manually confirmed statslog received each type of events
Change-Id: I24282cdb56265bba61dceb0932112804273dcfc8
* due to having to make the API public, drop the
invalidate_by_client strategy in favor of self invalidation
by polling
* in Magnifier#show(...) stop sending screen coordinates in favor
of view coordinates
* UI/UX:
** width from 200dp to 164dp
** fixed the shadow depth (elevation)
** fixed the rounded corners (2dp)
Bug: 63531115
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: manual test that shows the magnifier working
Change-Id: I6451767b0a618c0c4ea396ba3ee3144523dadc57
The host passes an IServiceConnection to the AppWidgetManager which
is used to bind to the RemoteViewsService. This allows the host to
recieve the connection callbacks directly instead of proxying it via
the AppWidgetManager. The host is also responsible for unbinding to
the service.
Bug: 26481160
Test: adb shell \
am instrument -w -e class android.widget.RemoteViewsAdapterTest \
com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Change-Id: Iac400095a319c3a43714c82fda7516be1ccc68af
The WakeupMessage object provides a mechanism to create an Alarm
which will wake-up the device and deliver a message to a Handler.
Add a Runnable mechanism as an alternative to the message.
Bug: 67276378
Test: unit test
Change-Id: Icf5f03b2b25a340273f9d3fcd09f182216ea6238
This reverts commit 96d68d45f0.
Reason for revert: This CL fixed the bug but introduced a new one as described in bug 31298450 comment#10
Bug: 31298450
Bug: 31444175
Test: Manually done as follows
1. Open system settings.
2. Tap "System"
3. Tap "Languages & input"
4. Tap "Languages"
6. Tap "Add a language"
7. Select "English"
8. Tap the back button on the NavBar
9. Make sure that the user is navigate back to "Add a language" screen.
Change-Id: I1c98476e962a2d767ec8ed6462c50715a95be9bc
InputConnectionWrapper has several synchronous methods which have a
timeout. If the application's UI thread hangs, all these synchronous
methods are blocked and IME stays on-screen.
This CL aims to improve the responsiveness of IMEs by rejecting
any blocking calls of InputConnection APIs once
IInputMethod#unbindInput() is issued by InputMethodManagerService
(IMMS).
Currently #unbindInput() is issued only from
IMMS#unbindCurrentClientLocked(), which basically means that the
previous application is losing the IME focus.
Underlying #onUnbindInput() signal is still immediately delivered
to the IME process, but it's just waiting to be consumed on the UI thread.
Hence in theory we can change the behavior of InputConnection seen
from the IME once the signal is delivered to the IME process.
This CL does not interrupt already blocked API calls, which is one of
future work for this scenario. This CL relies on:
A. IInputMethod is marked as oneway
B. IMMS guarantees that IInputMethod#bindInput() and
IInputMethod#unbindInput() are always paired without nesting,
and IInputMethod#startInput() is called 0 or more times only
during that pair.
In this case, the system guarantees that IInputMethod methods
will be called back in the IME process in the same order, and only
one IPC thread is handling those IPCs at the same time. See the
JavaDoc of IBinder#FLAG_ONEWAY for details.
Bug: 36897707
Test: Manual: using the apk in the linked bug:
1. Make sure that a valid InputConnection is established between
the test app and a test IME.
2. Let the test app start blocking the UI thread.
3. Let the test IME call InputConnection#getTextBeforeCursor()
three times.
4. Tap the Home button on the NavBar.
5. Make sure that the test app is immediately dismissed.
6. Make sure that InputConnection#getTextBeforeCursor() starts
returning immediately, once after the initial call was timed-
out after 2 sec (InputConnectionWrapper#MAX_WAIT_TIME_MILLIS)
Change-Id: I0f816c6ca4c5c0664962432b913f074605fedd27
Test: This merge conflict was automatically resolved by meld.
The automatic resolution of the same merge conflict by meld
from cherrypicking this CL into internal-master has passed
Treehugger (and was already submitted).
Exempt-From-Owner-Approval: Resolving merge conflicts with no deltas
Change-Id: I61f15aeb79c1ad26cc7c51be2af59ecb7b672a7b
This is a preparation to work on Bug 36897707.
For instance, the reason why most of IME-related callbacks in
InputMethodService get called on the main thread is because
IInputMethodWrapper keeps forwarding incoming IPCs into the
main looper of the IME process as follows:
InputMethodManagerService (IMMS)
------
-> one-way binder IPCs over IInputMethod
------
-> IInputMethodWrapper (on the binder thread(s))
-> Handler (to dispatch tasks to main thread)
-> InputMethodImpl.* (on the main thread)
-> InputMethodService.* (on the main thread)
By adding explicit annotations such as @BinderThread and @MainThread
in relevant methods, this CL makes that kind of investigation much
easier than before.
Bug: 36897707
Test: compile
Change-Id: I8f9afe9a1986a9fa41fb66fdc64e8f0f67e45c2e
This is a pure refactoring with no a behavior change other than
that these calls now go through android.system.Os, which immediately
delegates to Libcore.os.
This is a first step towards separating framework (via
android.system.Os) vs. libcore (via Libcore.os) clients of these
low level APIs. Separating these is a prerequisite towards moving
the API parts of android.system into framework, and moving the
rest into a different package in libcore.
Test: Treehugger
Bug: 67901714
Change-Id: Ifd8349ec5416e5693f40dba48fdf2bef651b7d81
Merged-In: Ifd8349ec5416e5693f40dba48fdf2bef651b7d81
This is a pure refactoring with no a behavior change other than
that these calls now go through android.system.Os, which immediately
delegates to Libcore.os.
This is a first step towards separating framework (via
android.system.Os) vs. libcore (via Libcore.os) clients of these
low level APIs. Separating these is a prerequisite towards moving
the API parts of android.system into framework, and moving the
rest into a different package in libcore.
Test: Treehugger
Bug: 67901714
Change-Id: Ifd8349ec5416e5693f40dba48fdf2bef651b7d81
* Magnifier#show() takes snapshots of the content and displays
them in the Magnifier bitmap
* calling show(...) consecutive times with the same arguments is
a no-op if already showing (to cater with the miriad of motion
events produced by touch which end up calling show(...))
* introduced Magnifier#invalidate(...) which, if currently
showing, forces updating the content using the last configuration
* clamped the start horizontal value of the Rect which delimits the
content to show in order to avoid distorting the rendering of the
magnifier content
* fixed invalidating the magnifier (invalidate() does not
automatically call invalidate(RectF) !)
Bug: 63531115
Bug: 67296158
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: manual test that shows the magnifier working
Change-Id: I8e53dfb6582d541922fe05b60311658fb07ca880
When a ble scan starts, it tells batterystats whether that scan is
unoptimized. When the scan stops, batterystats is not informed of
whether the stopped scan was unoptimized. Because the ble scan call
could not be nested (couldn't call start twice without stopping first),
this was fine, but now nesting is possible, so batterystats needs to
know whether the stopped ble scan is unoptimized.
Bug: 63456783
Test: runtest -x frameworks/base/core/tests/coretests/src/com/android/internal/os/BatteryStatsTests.java
Test: no new errors when run cts-dev -m CtsIncidentHostTestCases -t com.android.server.cts.BatteryStatsValidationTest#testUnoptimizedBleScans
Change-Id: Ia73f294cf1807ddaf20f1c0bcc28add001cac78c
Merged-In: Ia73f294cf1807ddaf20f1c0bcc28add001cac78c
(cherry picked from commit 94c5a313d7)
- Replace SHOW_AS_OVERFLOW_ALWAYS with SHOW_AS_ACTION_NEVER
- MenuItem ordering
- Allow textAssist items in overflow to show text with images
- MenuItem label text now standard case (not allcaps)
Bug: 62447250
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Change-Id: I07fa06f433a34adfad20b371417c95ce76422456
* magnifier zoom from 1.5 to 1.25
* max scale from 10 to 4
* magnifier shows over the text if there is no more space above
instead of showing underneath the cursor
* paused the blink while showing the magnifier and resumed when
dismissing
Bug: 63531115
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: manual test that shows the magnifier working
Change-Id: Ief3e0b7dc9e287e7dd1a9102548b1861598b69c4
Bug: 62269291
Test: manual, install new apk/splits and force updates.
I used com.android.cts.classloadersplitapp as the test app.
1) install-multiple split apks with dependency: Base -> A -> B
2) push an update for A
3) adb shell cmd package compile
4) check that A & B got recompiled and that B was because a class loader
context mismatch (e.g. "ClassLoaderContext classpath element checksum
mismatch for position 1.").
Change-Id: I4092562966413dc8976c9d41b26a90bbb9e37e1e
Instead of using the whole slab mem for kernel usage, split the
unreclaimable to kernel and reclaimable to cache (since is freed
under mem. pressure).
Test: tested on gobo
Bug:67753120
Change-Id: I0f5a310bb88603ad7bb28e5398ea57c249c04fc2
ListMenuItemView's group divider is only existed in
popup_menu_item_layout, but Chrome use list_menu_item_layout.
It will make NullPointerException and crash the chrome.
Fix it by check null before using the group divider.
Bug: 66987086
Test: Long click an image from webpage in chrome, click the "Download
image" item, and it works well.
Change-Id: Ie5f19194a968b4fff0126e1cf8bebda5344c8105
Still very rough UI, but basically does what is intended.
Also add two tests apps for manual tests (CTS test will
be coming).
Bug: 63937884
Test: manual
Change-Id: I45a6a2b122a75f8125510a2027bb1faf57c6956d
When device restarts, screen state is set to unknown, all
timebases stop. Then if setBatteryStateLocked() is called
with unplugged state, onBatteryTimeBase starts, but
onBatteryScreenOffTimeBase does not, so does ScreenOnTimer,
since screen state == unknown. So this duration is lost.
This fix attributes unknown state to ScreenOff.
Fixes: 67608353
Test: added a unit test in BatteryStatsNoteTest
Change-Id: Iee68898522564963e7d0b0110f1aee9248aacfe8
In BatteryStatsImpl.java:
Previously, if inclUid == false, then kernelWakelockStats and
wakeupReasonStats were not printed to the parcel, but only a single 0
was written in their place. In the parcel-reading code, their sizes are
read, so if they are not present, there should be a 0 for each of them.
In other words, two 0s should be written if they are not present,
instead of just 1.
Test: none
Change-Id: I1d443e9659646f0d30063f275a6a9db42b0a3906
The class must be public to avoid test issues. If the class is
package-private, the test would have to be in the boot class-
path:
Rejecting re-init on previously-failed class java.lang.Class<com.android.internal.os.LoggingPrintStreamTest$TestPrintStream>: java.lang.IllegalAccessError: Class com.android.internal.os.LoggingPrintStream extended by class com.android.internal.os.LoggingPrintStreamTest$TestPrintStream is inaccessible (declaration of 'com.android.internal.os.LoggingPrintStreamTest$TestPrintStream' appears in /data/app/com.android.frameworks.coretests-SD7GJmYE507ACoE9gu2mnw==/base.apk)
at java.lang.Object java.lang.reflect.Constructor.newInstance0(java.lang.Object[]) (Constructor.java:-2)
at java.lang.Object java.lang.reflect.Constructor.newInstance(java.lang.Object[]) (Constructor.java:334)
at junit.framework.Test junit.framework.TestSuite.createTest(java.lang.Class, java.lang.String) (TestSuite.java:61)
Test: m
Test: runtest -x frameworks/base/core/tests/coretests/src/com/android/internal/os/LoggingPrintStreamTest.java
Change-Id: I26cead7954cf4309c8b3e16994c35a3f4a9eb798
Also a little code cleanup as I was going through to understand the
dumping code.
Bug: 65750808
Test: flash device and inspect incident.proto output
Change-Id: Ib850db408c98d6a96dc028296e96c75087258904
