…reProcessorImpl is enabled and convert it to JPEG in camera-core

Previously camera-extensions do the YUV to JPEG conversion but the problem is that it can't set the timestamp of the
JPEG Image and thus we aren't able to match the timestamp of the Image and the CaptureResult in ImageCapture in order to
know exactly which request does the Image belong to.

This timestamp match is critical to avoid the issues when interrupting a extensions takePicture actions.

This CL is to let camera-extensions outputs the YUV_420_888 image directly and let the ImageCapture pipeline handles the
YUV-To-JPEG conversaion and rotation and EXIF hanndling.

Bug: 318027789, 318451053
Test: extensions/ImageCaptureTest
Change-Id: I7fc225a0fab186d4af82764cf0fc23f00659a101

…ompleted passes CameraCaptureResult

This CL is to make SessionProcessor more consistent with non-SessionProcessor capture
by allowing TagBundle to be set in startRepeating / startCapture / StartTrigger
and the callback's onCaptureCompleted will pass the CameraCaptureResult that
contains the TagBundle and the timesstamp.

Bug: 339762546
Test: AdvancedSessionProcessorTest

Change-Id: Ie33c9b1b4281b07364a6f1f685fa7d739da612eb

This ScrollIndicator features a new design. It also fixes the problem of the jumping size- it's fixed now and depends on initial position of the List.
Bug:286883009
Test: "ScrollIndicatorTest.kt"
Relnote: "Add ScrollIndicator to Material 3. This ScrollIndicator features a new design. It also fixes the problem of the jumping size- it's fixed now and depends on initial position of the List"

Change-Id: Ic228d48ed349dabb9c1fa02b949f07e3a6a4781b

If a text button was built using just a Text and a clickable modifier with a role `Role.Button`, such text button wasn't announced as a button because the `TextView` classname overwrote the `Button` classname.

Fixes: 343392125
Test: ACVADCTest, demo with Talkback

Change-Id: I1f588e2fcef0c4aa85ba2051c3df42f6a33ff300

…can be read

Without the finalizeDsl, this is being run before library type is set, and lint is not getting applied correctly because we do several checks on library type.

Test: Validated with aosp/2979896

Change-Id: I786228ec567566bb20cc888cc0075c11bba1679a

Failing to reset the count of pending commits leads to redundant render calls when the surface is recreated. This results in extra calls to onDrawMultiBufferedLayer with an empty params list (more than the one expected), or in additional front renders that skip the user onDrawFrontBufferedLayer callback (because that's called within a block passed to ParamQueue.next that does not get executed unless there's actually an item in the queue).

The same issue happens on clear, which uses the same underlying method to clear pending draws before triggering a render of the multi-buffered layer.

This fix might help with a rendering stall where (apparently) the count of pending commits can be spuriously positive while no commits are actually pending. One way for this to happen is for commit to be called while mMultiBufferedRenderer is null, that increments mCommitCount, but no render is actually kicked off. mMultiBufferedRender is null while the app is paused (assuming the default SurfaceView lifecycle). clearParamQueues is called when the surface is updated on resume, but that doesn't currently clear mCommitCount.

Getting tests that reliably failed before the fix and pass elsewhere required fixing another bug where deferred render requests did not get processed on release when the cancelPending parameter is set to false. It needs to push those up-front so the sequence point set by GLThread.stop(false) is after those callbacks.

Fix: 342154090
Fix: 342160701
Bug: 344867857
Test: Unit tests that fail before the code change and pass after
Change-Id: I42da1458f6c4dbbbe45a988b4f8a9eb278bf32ad

Test: N/A, no logic change
Bug: 335726351
Change-Id: Ie234ec5e49007843006126c9404736be5904f63f

…esultKeys issue in extensions testlib

The new extensions capture pipeline will have the following expectation for the OEM
implementations (which was tested in CTS)
1) if getAvailableCaptureResultKeys returns a non-empty list, then
   either SessionProcessorImpl.CaptureCallback#onCaptureCompleted (advanced) or
   ProcessResultImpl#onCaptureCompleted (basic) will always be invoked.

2) the onCaptureCompleted will have the same timestamp as the Image.

This CL is to align the extensions testlib to the above expectations.
Besides,
For advanced extender, it extends the LongCaptureAdvancedExtenderImpl
to the ConfiguratableAdvancedExtenderImpl and allow it to configure
the willInvokeOnCaptureCompleted and longDurationCapture parameters.

Bug: 339762546
Test: manual
Change-Id: I280e7a2ce96b23210185db70c2ea65f7cefb5a29

…eted is always invoked with correct timestamp and switch to MetadataImageReaderProxy for Extensions

1) Changed the SessionProcessor behavior to make it always invoke
SessionProcessor.Callback#onCaptureCompleted regardless of Basic Extender
or Advanced Extender.  (previously, onCaptureCompleted is invoked optionally)

The rules are
if (OEM verion >= 1.3 && getAvailableCaptureResult returns non-empty)
   then onCaptureCompleted in SessionProcessorImpl.CaptureCallback and
   ProcessResultImpl is expected to be invoked. We can finish the capture
   sequence here.

If (OEM version < 1.2 || getAvailableCaptureResult returns empty)
   then onCaptureCompleted in SessionProcessorImpl.CaptureCallback and
   ProcessResultImpl won't be invoked. We can finish the capture sequence
   when the SessionProcessorImpl.CaptureCallback.onCaptureSequenceCompleted
   or CaptureProcessorImpl.process returns.

These rules are tested in CTS so OEMs should follow the rules.

2) In ImageCapture, we configure it to use regular MetadataImageReaderProxy when
   Extensions are enabled (SessionProcessor is enabled

3) In camera-camera2 and camera-pipe-integratin,  ensures
   CameraCaptureResult in SessionProcessor.onCaptureCompleted are passed to
   CameraCaptureCallback.onCaptureCompleted so that MetadataImageReaderProxy
   can get the CameraCaptureResult to match with Image.

Relnote: "Fix the issue that interrupting a takePicture request with
Extensions enabled could fail to get result and the next takePicture
request might no longer work."

Bug: 339762546
Bug: 318027789
Test: AdvancedSessionProcessorTest / BasicExtenderSessionProcessorTest / extensions/ImageCaptureTest
Change-Id: Iae78f85a429b5e72354debb9201daa130784a1ab

Additional callback was added to support long clicks for Card, TitleCard, AppCard and OutlinedCard

Bug: 338551409
Test: "CardTest.kt"
Relnote: "Add onLongClick callback to Cards"
Change-Id: I305d5005e98ece7424af6d9c690c5c844836ab5e

While we work in the proper implemntation, we can use this placeholder to keep
development going, even if we may need to revisit some of it later on when
the proper API is finalized.

Test: Manual
RelNote: Internal
Change-Id: Ida9f53a9103343b62c74fe4fef844f3957b8872e

To merge aosp/3115143

Bug: 332507644
Test: presubmit
Change-Id: Ib554db2f0f1646a7f2432cd1de958c7a2a164802

…l::onCancelPointerInput

Otherwise this information is lost and unwanted touch-related interactions can be triggered in environment where they were not supposed to happen

Test: SuspendingPointerInputFilterTest

Change-Id: I5f6fdc160d79d23594337701743451ecabd5cbc2

Bug: 344848081
Test: ./gradlew 🚗app:app:test
Relnote: "Add @ExperimentalCarApi tag to MediaPlaybackTemplate.Builder."

Change-Id: Ic195773f56a9f10234f232413b72404f95434ec6

Bug: 342952256
Test: ./gradlew :pdf:pdf-viewer:assemble &&
      ./gradlew :pdf:integration-tests:testapp:assemble
Change-Id: Icdb2da049058caedb96196687b4c0c7322c627df

...along with false positive test case

Bug: 344616929
Bug: 313686921
Test: unit test added
Change-Id: I52b694f6331d6a4c072112104c478e502a5cefe8

…for camera-pipe

Bug: 344717630
Test: run OpenCloseCameraStressTest & OpenCloseCaptureSessionStressTest on lab devices
Change-Id: Iaf6cf70c80a429ca1ef02a92223699373d8eaf65

…d improve testlib

1. When OEM removes some extensions classes such as HdrImageCaptureExtenderImpl,
  the same classes in testlib is still being used and could cause crash.

   Added the code to detect this case.
2. Ensure the testlib covers all kind of extensions features combination.
  For example, use PROCESSOR_TYPE_NONE in auto preview and returns null
  for CaptureProcessor for auto capture so that we can test these combinations.

Bug: 339762546
Test: extensions/ImageCaptureTest
Change-Id: I9b3b4ed44b36b2295f36dee3d88e0fc08ebe7bb1

* changes:
  [Extensions-Capture] Ensures SessionProcessor.Callback#onCaptureCompleted is always invoked with correct timestamp and switch to MetadataImageReaderProxy for Extensions
  Extensions-Capture] Fix the onCaptureCompleted / getAvailableCaptureResultKeys issue in extensions testlib
  [Extensions-Capture] add TagBundle to SessionProcessor and onCaptureCompleted passes CameraCaptureResult
  [Extensions-Capture] camera-extensions outputs YUV_420_888 when CaptureProcessorImpl is enabled and convert it to JPEG in camera-core

…sses and improve testlib" into androidx-main

…Quirk in pipe-integration

Bug: N/A
Test: manually testing
Change-Id: I37f64b78aea5147627b78dcebb14051f3e00fb02

…idx-main

…ssTest for camera-pipe" into androidx-main

…IsBoundQuirk in pipe-integration" into androidx-main

…dx-main

Dynamically adjusts zoom margins based on screen DPI.
Applies larger margins at 840 DPI and above for easier reading of PDFs,
aligning with design mocks https://www.figma.com/file/D7sKYUlsHW8cFAlRZN8UhX/Parchment-(PDFs-on-Android)?type=design&node-id=8201-99773&mode=design&t=b6hopo5NbsNEIbkK-0
The current look can be found at https://b.corp.google.com/issues/327949931#comment5

Bug: 327949931
Test: verify via test app
Change-Id: I1905283828fce7c12caa9bba4e43c10a5be0fb89

- Add android:configChanges to handle orientation changes manually.
- Implement onConfigurationChanged to adjust zoom view margins when screen configuration changes

Bug: 334012074
Test: ./gradlew :pdf:pdf-viewer:assemble &&
      ./gradlew :pdf:integration-tests:testapp:assemble
Change-Id: I8f4e2cc99de20e615efbd4c02f511be847480e4d

Bug: 338216880
Test: ./gradlew :pdf:pdf-viewer:assemble && ./gradlew :pdf:integration-tests:testapp:assemble
Change-Id: If3825d4a916847d344031a742f263fd63a7cc39c

…t." into androidx-main

… into androidx-main

…droidx-main

…ndroidx-main

For collection types, in the past if no value was passed in, the arg would be ignored and omitted from argument bundle. Now, a missing collection type value will default to the NavArgument's defaultValue, or an emptyList if there isn't a defaultValue.

What is considered "no value" is different between list of strings and list of non-strings. For clarity, this is how various routes are handled:

Given a route pattern "www.test.com?list={myList}"

List<String>
1. "www.test.com?list=" considered as listOf("")
2. "www.test.com?list={myList}" considered as listOf("{myList}")
3. "www.test.com?" considered as no value
4. "www.test.com" considered as no value

non-String lists
1. "www.test.com?list=" considered as no value (since it is invalid)
2. "www.test.com?list={myList}" considered as no value
3. "www.test.com?" considered as no value
4. "www.test.com" considered as no value

Test: ./gradlew navigation:navigation-common:cC
Test: ./gradlew navigation:navigation-runtime:cC
Bug: 341723133
Relnote: "Fix how navigation handles missing arg values for CollectionNavTypes - instead of ignoring missing values, navigation will now default to its defaultValue, or an empty collection if there isn't a defaultValue. This fallback value will be added the NavBackStackEntry.argument bundle."

Change-Id: Id630fb148782fbb34d3c236f5d8bb363fba7ef91

Test: ./gradlew navigation:navigation-common:cC
Test ./gradlew navigation:navigation-runtime:cC
Bug: 341723133

Change-Id: I1c67ff34424a4559ed09ad2ef1f92c7baec2e23a

…values can be read" into androidx-main

We merged aosp/3105059 to fix null lists by adding null values to the bundles.

In this forward fix, we handle null the same as a missing value for lists whereby we will default to the defaultValue if present, otherwise we default to an emptyList().

Test: ./gradlew navigation:navigation-runtime:cC
Test: ./graldew navigation:navigation-common:cC
Bug: 342672856
Relnote: "Navigation handles null value for built-in CollectionNavTypes by by defaulting to the NavType’s defaultValue, or an emptyList() if there is no defaultValue."
Change-Id: I84158320503bc04052de8f80022f83d86e23cc15

Test: TH
Bug: 344943214
Relnote: "Add comment on NavType.serializeAsValue and serializeAsValues to highlight that the final outputs should be Uri encoded."
Change-Id: Ida6bd848fb1e3d8e26277eff0f214e1d40907063

* changes:
  Forward fix null lists
  Add safe args tests for empty lists
  Handle empty CollectionNavType

…/navigation/2.8.0-beta03

)

The issue is that the call to setPopUpTo becomes recursive since the
`hashCode` is treated as `route: T`. The fix is to duplicate what the
other functions are doing, which isn't too bad because there isn't a lot
happening.

Another option would be to extract everything into a separate private
function and have all the overloads call that, but it seemed like
overkill here.

## Testing
Describe how you tested your changes. If possible and needed:
- Test it on a sample project

## Google CLA
Signed

---------

Co-authored-by: Ivan Matkov <[email protected]>

Adoption of d08f0cc and fb14567