$ adb shell dumpsys activity provider com.android.launcher3/com.android.launcher3.LauncherProvider
To see how the proto is filled: go/launcher-proto-dump
b/31772480
Change-Id: I8e0f1e5e38148a3dfeabd2fc057392193b2625dd
(cherry picked from commit 6aa3729e98)
$ adb shell dumpsys activity provider com.android.launcher3/com.android.launcher3.LauncherProvider
To see how the proto is filled: go/launcher-proto-dump
b/31772480
Change-Id: I8e0f1e5e38148a3dfeabd2fc057392193b2625dd
- Log notification launches
- Log notification swipes
- Fix logDragNDrop() to only log if the pre-drag ends (so it doesn't
log a long-press that only shows shortcuts without dragging).
- Add shortcut rank to logs when launching deep shortcuts, where 0
is the shortcut closest to the app icon (highest rank).
Bug: 34770729
Bug: 32410600
Change-Id: I99dcef9b6a71da2ef58e32397702bb137407b10f
> Also enabling fileLog when the device is debug build (even when
launcher is not dogfood build)
Bug: 30735662
Change-Id: Ieab2c962d57f6f7f972f8111070d4ecbef06b3e7
LoggerUtils had a lot of methods with same name and similar arguments
but completely different behavior.
Instead only defining macros in LoggerUtils and movoing the action
logic in the UserEventDispatcher.
Change-Id: Ibce8ea1a0890499b47c950930accb9b28473f44c
This is the first CL in a series of logging-related CLs. Upcoming CLs will
include using Commands (HOME_INTENT, BACK) and "tapping outside" of a container
logic.
Change-Id: I62f0a08c7a9d9fce0baa5c12c67e21f63ab16a7c
b/30039490
Supported in this CL:
- DnD: drag from container [WORKSPACE|HOTSEAT|FOLDER|ALLAPPS|WIDGETS|DEEPSHORTCUTS]
drag to container [HOTSEAT,WORKSPACE,FOLDER,DROPTARGETS]
- Source and target can be [FOLDER_ICON, ICON, DEEPSHORTCUT, WIDGET]
- $ adb shell setprop log.tag.UserEvent DEBUG will turn on debugging
Change-Id: I0b8b879b80e6dce85bbde6e7794f9e0677832603
- We only want to log when the container is opened and potentially
used, not when a long press is followed by a drag-and-drop.
- Also cleaned up code that was determining the container of the
app icon, since LaunchSourceProvider.fillInLaunchSourceData()
can do that instead (it's more robust and consistent).
Bug: 30791570
Change-Id: I05b6750f26182fda8a9940ac66f1371c2d228ca9
- Log as long press with child type DEEPSHORTCUTS container
- Parent type can be one of WORKSPACE, HOTSEAT, FOLDER,
ALLAPPS, PREDICTION, or SEARCHRESULT.
Bug: 30537079
Change-Id: Ie62e4889ee06c845f959ca998781787a7fdaf00e
The javadoc in createUserEventDispatcher suggested that it can be used
as a singleton. But it was being constructed as an inner class which
would cause context leak when used as singleton
Change-Id: I706018d4ab26b506ac936fe1a7304d9b530b820c
During tests, the logs directory is changed. But the active thread
was not getting stopped which was causing some logs to be written
to the old location corresponding to some previous test
Change-Id: I7b8587eae0eb68fa180e3992694cab3745922483
The logs are kept for at max 48 hours. It uses two log files and switches
between the two based on the day of the year.
Change-Id: I9a99499b3445a62f29f62a5cd13db20b1783bcd3
b/26494415
- Removed bundle object that became redundant now that we have LauncherEvent proto
- Combined Stats and UserEventLogger as they are effectively doing same thing
- Removed parent field inside Target
- added predictedRank target inside Target
b/27967359
- make com.android.launcher3.action.LAUNCH broadcast explicit
Later CL: finish packageName/intent/componentHash/predictedRank fields
Change-Id: I441fb46c834f73e58a4d2324e8da7971e8713ec8
