Add an option -f to record instrumentdata proto produced by am instrument
to a file in addition to printing to stdout. Default path is
/sdcard/instrument-logs/log-yyyyMMdd-hhmmss-SSS.instrumentation_data_proto.
If the file exits, it will be deleted before writing. Path can be changed
via optional <FILE> argument after -f.
If -f and -m are both present, proto will be written to a file and print
to stdout.
Test: build, flash and run:
bit -bi FrameworksCoreTests
adb shell am instrument -w -r -f tmp/tmp.log \
-e class com.android.internal.os.BatteryStatsNoteTest \
com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Change-Id: Iabc320c066d5995eee842c26416623eeb3d403f4
We can use the new mechanism to ask the calling shell to open
a file in order to implement the rest of these commands, allowing
you to give the path to an apk to install. That API is thus
extended to allow you to open readable files, not just opening
file for writing.
Doing this however means we no longer can pass a file path to
AssetManager for the apk to parse, we only have an already open
fd for that. Extending AssetManager to allow adding apks from
fds is not that hard, however, since the underlying zip library
already supports this.
This main thing this changes is in AssetManager.cpp where we
retrieve the open zip file for a particular apk that has been
added. This used to look up the zip file by path every time
it was needed, but that won't work anymore now that we can have
things added by fd. Instead, we keep track of each opened zip
in the AssetManager, so we can just directly retrieve it from
the asset_path representing the item that was added. As a
side-effect, this means for normal paths we no longer need to
look up by name, but just have the opened zip file directly
accessible. (This is probably good, but it does mean that we
no longer run the logic of seeing if the zip file's timestamp
has changed and re-opening it if it has. We probably shouldn't
be relying on that for an active AssetManager anyway, and maybe
it is even good that we don't allow the zip file to change
under it?)
A follow-up change will finally remove the Pm.java implementation
and turn the pm "command" into a simple shell script that runs
cmd package.
Test: manual
Change-Id: Ie103e3bdaa5b706796cc329254f2638151a3924f
This change introduces minimal changes needed to support selection
of locales with BCP 47 numbering system specification. Two level
selection (Language/Region) schema remains, locales with numbering
systems appear in the region selection list and are displayed as
"region (numbering system)".
Bug: 18340949
Bug: 63754513
Test: manual, experimental UI for review.
Change-Id: I42691f3714c5e5c51fd8d96c034cc3a9f6be93dc
He prefers to use his @android.com account.
Test: Treehugger
Bug: 63673347
Exempt-From-Owner-Approval: Allow @android.com to approve this CL :)
Change-Id: Ie80cc7864de7b91ae44ad57f0bae9b859d034803
- This logic will also be used when the recents component is started to
fetch assist data associated with the current activity.
Bug: 67864419
Test: com.android.server.am.AssistDataRequesterTest
Test: CtsVoiceInteractionTestCases
Change-Id: I4cb3c2536a104d7071bc0a1fd6e31dfc2c0ce8d0
The quitNow method places the SM_QUIT_CMD at the front
of the queue. This can cause StateMachine to throw exception
if it has not yet processed the SM_INIT_CMD from start().
Bug: 67370902
Test: make checkbuild
Test: StateMachineTest unittest
Test: build/install on device, toggle bluetooth and wifi
Change-Id: I7cec7bb91e0447e3c565d33cb7c34ccf59566639
Remove uselsess annotations on primitives.
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: I1e15e18d57af23d25a347d644ea57372e32adb59
The following events are added to statsd:
WifiLockStateChanged
WifiSignalStrengthChanged
WifiSignalStrengthChanged
PhoneSignalStrengthChanged
Test: manually confirmed these show up in the statslog.
Change-Id: Ifee27c86a28616d8cb9d43bdf11f9cabe2b367c6
The wakelock event is logged in statsd.
Test: manually confirmed that the event appears in statslog.
Change-Id: I9ffa4b0042264aabf3526843b4fb1832d183de61
Expose Binder Proxy Tracking by Uid from the native side. Enable
tracking for SYSTEM and killing of any bad behaving uids.
Change-Id: Ifd6d0f30a93fad406417dd83c1495c105bced974
Fixes: 63901963
Test: bit FrameworksCoreTests:android.os.BinderProxyCountingTest
* 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
