| Age | Commit message (Collapse) | Author |
|
A prep step for the new preview UI: extract each preview logic from
ChooserContentPreviewUi into individual components leaving the former as
a facade for the latter.
More specifically:
* move ChooserContnetPreviewUi into a new package;
* make #displayTextContentPreview() to be the core of the
TextContentPreviewUI (with related methods);
* make #displayFileContentPreview() to be the core of the
FileContentPreviewUi (with related methods);
* make #displayImageContentPreview() to the core of the
ImageContentPreviewUi (with the related methods);
* for all aforementioned new components, pass component specific
dependencies as constructor arguments, capture the common component
contract in the base abstract class, ContentPreviewUi, along with the
static utility methods.
Bug: 271613784
Test: Manual testing of
* Text sharing with and without preview;
* File sharing with and without preivew, single file and multiple
fiels;
* Image sharing, single and multiple files, image + text sharing;
* Custom actions with text, image and files sharing;
* Reselection action with text, image and files sharing.
Test: screenshot transition animation
Test: atest IntentResolverUnitTests
Change-Id: I392de610b3d3e044e23c83d29fd11061fbc7192d
|
|
|
|
ScrollableImagePreviewView being a RecyclerView may reattache its
children multiple times and rely on the ImageLoader to implement any
image retrival optimizations.
Fix: 269797062
Test: manual test, unit tests
Change-Id: I256f4a78a677e939f717fee5dd82492ec572bc65
|
|
|
|
|
|
Animate custom actions in the same way as targets selection i.e.
slide-out to the left / slide-in from the right.
Bug: 271366532
Test: manual testing
Change-Id: I2fbff047b8a06cbdd890b56db45ba1efce3e3f95
|
|
We believe it's merely a bug that the legacy implementation always
merged the "refinement" into the "primary match" (among those that
matched the selected target -- so it's sort of arbitrary that this
didn't even necessarily have to be the "primary intent" of the chooser
request). Thus we believe the loosened restrictions keep with the
spirit of the original guardrails on refinement -- but this seems to
be a necessary "fix" before the refinement flow could fit its billing
as a mechanism to let users select among alternate formats.
I believe this won't currently work for `SelectableTargetInfo` (i.e.
app share/shortcut targets) which for some reason doesn't seem to keep
track of its "alternates" -- I'll look into that outside of the scope
of this current CL.
Patchset #5 changes:
* Make sure that component name is set for DisplayResolveInfo after a
refinement intent is provided;
* Update MultiDisplayResolveInfo intent refinement logic -- it is now
delegated to a selected target.
Bug: 262805893
Test: `atest IntentResolverUnitTests`
Change-Id: Ie56b14b9a7beaa6bde8fe476d1ff140280abc51a
|
|
|
|
|
|
|
|
into tm-qpr-dev
|
|
Line was accidentally removed in ag/21444756
Slight refactor to test the class as well.
Bug: 270276629
Test: atest ChooserIntegratedDeviceComponentsTest
Change-Id: I8bcbb5820ea366fb475b5124e612a60f6f1d1501
|
|
|
|
Add test to validate that getParcelableArrayExtra() works with the
Intent that is sent.
Bug: 270552026
Test: atest ChooserRefinementManagerTest
Change-Id: Id1a6b374c36b11334278eeee35dcec4bec240101
|
|
This was previously an inner class of `ResolverActivity` but that
seems inappropriate since it's a common component used throughout
our code base (including "Chooser" configurations).
Test: `atest IntentResolverUnitTests`
Bug: 202167050
Change-Id: I9b001d02c87faa376032682796ccb2bc9c902401
|
|
Also remove an unused logging parameter.
Clarify nullability of custom actions list (should migrate this to
kotlin sometime).
Bug: 265504112
Test: atest ChooserActivityLoggerTest
Change-Id: If3f224ef16755a9a3a2c625d63e2fc35888fa37a
|
|
ResolverListController instances are 1:1 with the ResolverListAdapter
instances that hold them, and the adapters already carry their
associated UserHandles, so this was just one more "source of truth"
to potentially get out of sync as we're trying to clean up management
of these handles throughout the project. (And by exposing the handle
in a now-removed getter, it also added a redundant mechanism for
clients to access this value, making it harder to track down all the
usages in our application.)
I also took this opportunity to factor out a lot of boilerplate in
our tests to use a helper. That's not generally considered a good
practice for testing, but in this case the helper already existed
and just wasn't used in some cases -- where we instead duplicated
verbose boilerplate that represents less about the conditions we'd
actually expect to see in practice. Long-term we should clean up a
*lot* of details in our test design, so I think for now it's OK to
just use a more terse version of the design we already have.
Eventually I'd like to break up ResolverListController into a few
components with narrower focus, so removing any unnecessary
responsibilities is a great start.
Test: `atest IntentResolverUnitTests`
Bug: 202167050
Change-Id: Iade5b8d1f4e31d5439c234fbb1d82169ec01a386
|
|
|
|
|
|
The new `WorkProfileAvailabilityManager` component consolidates
responsibilities that were previously associated with the
`QuietModeManager` interface and resolver's work-profile-state
`BroadcastReceiver`.
See code review comments for further discussion of CL diffs.
Test: `atest IntentResolverUnitTests`
Bug: 202167050
Change-Id: I5fd0385e161959a5fbcdf9c27dbc757d5faa2a06
|
|
Just a regular UiEvent log for modify share. Include position
information for custom actions (*just* the position within the custom
action set, ignoring other system actions that may be within the display
container).
Bug: 265504112
Test: atest ChooserActivityLoggerTest
Test: atest ChooserActivityFactoryTest
Change-Id: If64db5c1afccf6571d23395624d6ffbbef677188
|
|
|
|
|
|
|
|
This is a high priority security fix.
Bug: 261036568
Test: manually via supplied tool (see bug)
Change-Id: I7e05506dc260d10984b8e56a8e657b50177ff04d
Merged-In: I7e05506dc260d10984b8e56a8e657b50177ff04d
|
|
Bug: 265504112
Test: Builds
Change-Id: Ie1071c88dfb0f8dcbc01d800d396c62abbe92936
|
|
Add a new test parameter, feature flag set, and run Chooser tests for
two set values: all flags are off and all flags are on. This ensures
that our integration tests cover the new features.
A new test rule is added to ignore tests that were designed for a
specific flag values when running in a set that does not have those
values set.
Bug: 258838272
Test: the modified test itself
Change-Id: If646ef123a383e801fda55d601e10b186c6c5c1f
(cherry picked from commit 880417ed82485d63c87737d38a270a3367d27594)
Merged-In: If646ef123a383e801fda55d601e10b186c6c5c1f
|
|
Bug: 269170766
Test: atest CtsSharesheetDeviceTest
Change-Id: I539c1f4a00c4572913fb3c0f10f22d9c20eb6ca9
|
|
This is in advance of any possible bug-fixes related to b/262805893
(which may probably be accompanied by additional unit tests..)
Test: `atest IntentResolverUnitTests`
Bug: 202167050
Change-Id: I4c8d20522236559ff99b6e11a7c1a3a0fcbbd17d
Merged-In: I4c8d20522236559ff99b6e11a7c1a3a0fcbbd17d
(cherry picked from commit c07d3f064db9cf715e36e9b6d4c1cd516e2258ce)
|
|
This was a sizable chunk of code dedicated to one logical set of
responsibilities, so it's nice to separate.
Test: `atest IntentResolverUnitTests`
Bug: 202167050
Change-Id: I3b033e975afeee66e33da38d0dc0eeba768d0ed4
Merged-In: I3b033e975afeee66e33da38d0dc0eeba768d0ed4
(cherry picked from commit 6f3ea1e9310afb2a56c1491148802e1b6154a094)
|
|
Doesn't change the UI or logging in this change, just API and code naming.
Bug: 267870268
Test: atest UnbundledChooserActivityTest
Change-Id: I2b8a68ed1e3fe1e6d4bdb1a89f155afdf377159a
Merged-In: I2b8a68ed1e3fe1e6d4bdb1a89f155afdf377159a
(cherry picked from commit 6333997c2c04f2e71c8fefad56a651e88bd25922)
|
|
|
|
|
|
This is a simple mechanical refactoring and (given everything still
builds) it can't possibly have any side effects.
The procedure for generating this change was as follows:
1. Add `final` to all `ResolverActivity` methods.
2. Build, and remove `final` from any of those methods that now
break compilation.
3. Sort the `final` (and `static`) methods to the bottom of the
source file / non-final to the top.
4. Build `IntentResolverUnitTests` and remove `final` from any
`ResolverActivity` methods that broke test-only compilation.
Replace with a comment `// @NonFinalForTesting` on these methods
(referencing an annotation that isn't available in Android, but
still worth noting. There are other patterns we can use to
formalize our design requirements, but these lightweight comments
are more appropriate while the API is in flux).
5. Sort these "non-final for testing" methods above the `final`
methods but below any that are overridden by real clients (since
they're still *really* just internal implementation details).
6. Build and test.
(7. Go back through and remove `final` from any private methods, as
requested by the linter. I'm not sure I agre3 with this rule in a
language where these methods will be "open" by default if their
visibility is ever changed, but c'est la vie...)
This groups together the `ResolverActivity` "override surface," which
roughly outlines the interface of a hypothetical delegate interface
that could be injected as part of `ChooserActivity` configuration in
order to avoid overriding any `ResolverActivity` methods. (That's left
out of scope in this CL, because -- even though we *could* effect such
a change via purely-mechanical transformations -- I suspect we'll want
to apply *some* design discretion along the way.) Ultimately this will
be an important step in decoupling our components from the `Activity`
API (with benefits for code clarity, hypothetical "embedded Sharesheet"
and "build-your-own chooser" APIs, etc).
Test: `atest IntentResolverUnitTests`
Bug: 202167050
Change-Id: Iffe340e1d6e3e3224fb6bd78005c349384716162
|
|
Define a default Chooser text appearance style, apply it to image and
file preview text.
Fix: 267524169
Test: manual testing
Change-Id: I75b613c126d739d37a28dc8c80855fa7f119278b
|
|
These were unused, and the pruned-down API surface better indicates
that we *always* launch activities to an explicit *user* (and *maybe*
with additional specification about the caller identity -- something
to do with the "safe forwarding mode" feature I'm still trying to
get my mind aroud).
While I was in here, I changed the signature of the one 'activity
starter' method that arbitrarily took a `ResolverActivity` instead of
the more generic `Activity` used in the others. We've been commenting
about the opportunity to make this fix for a while now, and there's
no time like the present.
Test: `atest IntentResolverUnitTests`
Bug: 202167050
Change-Id: I33be96b68e6feba8b7fdb0295431373aadd2c2bf
|
|
Clients of the `NotSelectableTargetInfo` factory methods won't notice
any API change, but those methods will now return instances of
`ImmutableTargetInfo`, built to match the same behavior of the
legacy subtype (note no clients have any remaining `instanceof` checks
in this part of the inheritance graph). The class now just hosts the
static factory methods and some private static helpers, and no longer
inherits from `ChooserTargetInfo` (or any other base). The two
concrete `NotSelectableTargetInfo` subclasses are removed altogether.
This change is a near-pure refactoring; the only other theoretical
difference is that these `NotSelectableTargetInfo` targets will now
get a plausible implementation of `cloneFilledIn()` instead of
returning null, but in practice that method will never actually be
invoked on these particular `TargetInfo` types. We're also *slightly*
more eager in building `IconHolder` instances, but in practice we
would always do that at nearly the same time anyways (and there's no
particular concern about the overhead).
There are also two changes to tests:
1. The device config permission change seemed to be necessary in
order to run `TargetInfoTest` in isolation, even though those
same tests could run as part of `IntentResolverUnitTests` already.
I'm not sure why the discrepancy, but the fix seems reasonable.
2. I needed to do a better job of setting up the placeholder targets'
icon for tests since the new `ImmutableTargetInfo.Builder` API
doesn't offer a mechanism to override `hasDisplayIcon()` directly.
With the better support in place, I made some extra assertions.
This is the first (low-hanging-fruit) conversion of this type, and
in future CLs we should proceed through the rest of the hierarchy
before eventually flattening all the APIs into a single class.
Test: `atest TargetInfoTest`
Bug: 202167050
Change-Id: Ibabfee6ef2349de0db0be97f1d2f894d0672cbfd
|
|
|
|
|
|
Fix image preview elements paddings, an artifact of a logical merge
conflict.
Add transition animation.
Bug: 262277421
Test: manual testing
Change-Id: I1c87369a4aecb9ba576f37553da80eb53d3b7a1a
|
|
|
|
Explisitly check for flag presense.
Test: manual testing
Change-Id: I16aa1dc536548754d7be8ce0c6dba9f5737963c0
|
|
This component is a container for precomputed `UserHandle` values
that should be consistent wherever they're referenced throughout
a chooser/resolver session.
This includes some low-hanging integrations in `ChooserActivity` and
`ResolverActivity` that seemed unobjectionable and suitable for "pure"
refactoring -- i.e. the same handles are ultimately evaluated from the
same expressions, and I don't immediately plan to change the legacy
logic. Once this is checked in, we can proceed to looking at some of
the more complex/refactorable applications of `UserHandle` and
eventually integrate this component more thoroughly. First follow-up
priority is test coverage; existing coverage validates our typical
behavior as observed in the activities, but it would be great if we
could validate our understanding with thorough unit tests directly
against the `AnnotatedUserHandles` API.
Test: `atest IntentResolverUnitTests`
Change-Id: I36116d8c7156b7d30e777dd3c609c7e883ffc042
|
|
Bug: 262280076
Test: presubmits
Change-Id: I8d7cfced5ff01f25f9f6a899889956c94a3eb0d0
|
|
|
|
This is the (belated) next step for go/chooser-targetinfo-cleanup.
The new class isn't yet integrated anywhere (but it's covered by
thorough unit tests). In the next step(s) of this cleanup, we'll
replace the implementations of the per-target-type factory methods
(like `SelectableTargetInfo.newSelectableTargetInfo()`) with
calls against the new `ImmutableTargetInfo.Builder` API. Existing
type-specific tests in TargetInfoTest.kt cover the behavior of
those factory methods. Finally, we can merge all the APIs to a
single `TargetInfo` class, with the concrete implementation taken
from `ImmutableTargetInfo`, and all the (static) factory methods
pulled in to preserve the categorization that had previously been
established via the subclass design.
(In practice some pieces may shift along the way, e.g. API method
additions that will have to be propagated up to the base & out to
the new immutable type. The general plan won't be affected by
these kinds of minor disruptions.)
Test: new unit test (component isn't yet integrated anywhere)
Bug: 202167050
Change-Id: Iaa8b260efd3d01db5ce58068adcaf43082a64c90
|
|
|
|
Fix: 267509997
Test: manual test
Change-Id: I2f0f559f4aff0ce85d083cc60544b99a1d809e57
|
|
Bug: 267869885
Test: atest PlatformScenarioTests:android.platform.test.scenario.sysui.sharesheet.ShareScreenshot#shareScreenshot
Change-Id: I18403705c1891c8f5216651a660b119be6d81731
|
|
Add an option to the user to exclude text from being shared from a media
+ text sharing case.
The text is ecluded only if the primary send inten is used i.e. it is
possible for senders to specify alterntive intents that can also be
used.
Bug: 262277421
Test: manual testing of: (1) regualr image sharing, (2) image and
text/web-link sharing, (3) using of an alternative intent, (4) sharing
to a shortcut. All of those for one and two (+work) profiles.
Test: integration tests
Change-Id: Iebb33b951853c6588157fa92d3826b6a6e096591
|