Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Upgrade VisionCamera to V3 #28914

Closed
wants to merge 13 commits into from

Conversation

mrousavy
Copy link
Contributor

@mrousavy mrousavy commented Oct 5, 2023

Details

Migrates from VisionCamera V2 to VisionCamera V3 ✨

Some important changes about V3:

  • Fully rewritten codebase for Android (now uses the low-level Camera API "Camera2" in favor of the more limiting alternative "CameraX")
  • Fully rewritten Frame Processors implementation (now uses react-native-worklets-core, FPs are disabled if Worklets is not installed; should fix a ton of build issues)
  • Fully rewritten Camera Devices API (useCameraDevice(..); useCameraFormat(..) - always have a device, never null)
  • Muuuuch faster (Camera device selection is now instant, and Camera is faster in general)
  • See full changelog here: mrousavy/react-native-vision-camera@v2.16.2...v3.3.0

Warning

Since the Android part is completely rewritten from CameraX to Camera2, there might be some rare edge cases on some phones. Often it's some Samsungs that report a feature as being available in their APIs, then the feature is not available for some reason (e.g. Samsung phones return 60 FPS as a supported FPS range, but just crash when you use 60 FPS. Aka; their APIs simply lie.)

We should carefully roll this out and report any issues straight to the VisionCamera repo so I can fix them asap! It's a huge help for me to test in a variety of devices.

Fixed Issues

$#28341
PROPOSAL: #28341 (comment)

Tests

  • Open Scan Receipt screen
  • Check if Camera works and can take pictures (on iPhones as well as Android phones)
  • Verify that no errors appear in the JS console

Offline tests

QA Steps

  • Verify that no errors appear in the JS console

PR Author Checklist

  • I linked the correct issue in the ### Fixed Issues section above
  • I wrote clear testing steps that cover the changes made in this PR
    • I added steps for local testing in the Tests section
    • I added steps for the expected offline behavior in the Offline steps section
    • I added steps for Staging and/or Production testing in the QA steps section
    • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
    • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
    • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
  • I included screenshots or videos for tests on all platforms
  • I ran the tests on all platforms & verified they passed on:
    • Android / native
    • Android / Chrome
    • iOS / native
    • iOS / Safari
    • MacOS / Chrome / Safari
    • MacOS / Desktop
  • I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
  • I followed proper code patterns (see Reviewing the code)
    • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
    • I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
    • I verified that comments were added to code that is not self explanatory
    • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
    • I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
      • If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:
    • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
    • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
    • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
    • I verified the JSDocs style guidelines (in STYLE.md) were followed
  • If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
  • I followed the guidelines as stated in the Review Guidelines
  • I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
  • I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
  • I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
  • I verified that if a function's arguments changed that all usages have also been updated correctly
  • If a new component is created I verified that:
    • A similar component doesn't exist in the codebase
    • All props are defined accurately and each prop has a /** comment above it */
    • The file is named correctly
    • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
    • The only data being stored in the state is data necessary for rendering and nothing else
    • If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
    • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
    • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
    • All JSX used for rendering exists in the render method
    • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
  • If any new file was added I verified that:
    • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
  • If a new CSS style is added I verified that:
    • A similar style doesn't already exist
    • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))
  • If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
  • If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
  • If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
  • If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
  • If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
  • If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
  • I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web
Mobile Web - Chrome
Mobile Web - Safari
Desktop
iOS
Android

@mrousavy mrousavy requested a review from a team as a code owner October 5, 2023 13:18
@mrousavy mrousavy mentioned this pull request Oct 5, 2023
61 tasks
@melvin-bot melvin-bot bot requested review from MonilBhavsar and removed request for a team October 5, 2023 13:19
@melvin-bot
Copy link

melvin-bot bot commented Oct 5, 2023

@MonilBhavsar Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

@allroundexperts
Copy link
Contributor

Reviewer Checklist

  • I have verified the author checklist is complete (all boxes are checked off).
  • I verified the correct issue is linked in the ### Fixed Issues section above
  • I verified testing steps are clear and they cover the changes made in this PR
    • I verified the steps for local testing are in the Tests section
    • I verified the steps for Staging and/or Production testing are in the QA steps section
    • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
    • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I checked that screenshots or videos are included for tests on all platforms
  • I included screenshots or videos for tests on all platforms
  • I verified tests pass on all platforms & I tested again on:
    • Android / native
    • Android / Chrome
    • iOS / native
    • iOS / Safari
    • MacOS / Chrome / Safari
    • MacOS / Desktop
  • If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
  • I verified proper code patterns were followed (see Reviewing the code)
    • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
    • I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
    • I verified that comments were added to code that is not self explanatory
    • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
    • I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
    • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
    • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
    • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
    • I verified the JSDocs style guidelines (in STYLE.md) were followed
  • If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
  • I verified that this PR follows the guidelines as stated in the Review Guidelines
  • I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
  • I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
  • I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
  • If a new component is created I verified that:
    • A similar component doesn't exist in the codebase
    • All props are defined accurately and each prop has a /** comment above it */
    • The file is named correctly
    • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
    • The only data being stored in the state is data necessary for rendering and nothing else
    • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
    • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
    • All JSX used for rendering exists in the render method
    • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
  • If any new file was added I verified that:
    • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
  • If a new CSS style is added I verified that:
    • A similar style doesn't already exist
    • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)
  • If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
  • If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
  • If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
  • If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
  • If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
  • If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
  • I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Web
Mobile Web - Chrome
Mobile Web - Safari
Desktop
iOS
Android

@allroundexperts
Copy link
Contributor

FYI, I'll be testing the android build on:

  1. Huawei Mate 10 Lite (Physical device)
  2. Google Pixel 3 (Emulator)
  3. Samsung Galaxy A10 (Physical device)

I will be testing the iOS build on:

  1. iPhone 13 Pro (Physical device)

@situchan situchan mentioned this pull request Oct 5, 2023
57 tasks
@shubham1206agra
Copy link
Contributor

@allroundexperts We need someone to test this with iPhone 15 due to a known issue

@allroundexperts
Copy link
Contributor

@shubham1206agra I think that will be tested as part of #27820. No?

@shubham1206agra
Copy link
Contributor

@shubham1206agra
Copy link
Contributor

@shubham1206agra I think that will be tested as part of #27820. No?

To be safe, we should test v3 too.
Once you have tested it, we can ask someone in slack to test this on the iPhone 15

@mrousavy
Copy link
Contributor Author

mrousavy commented Oct 5, 2023

I have an iPhone 15 Pro test device

@mountiny
Copy link
Contributor

mountiny commented Oct 5, 2023

Kicked off the test build

@Expensify Expensify deleted a comment from OSBotify Oct 5, 2023
@allroundexperts
Copy link
Contributor

What's up with the builds @mountiny?

@AndrewGable
Copy link
Contributor

Not sure, I just retried it here https://github.com/Expensify/App/actions/runs/6424873394

@AndrewGable
Copy link
Contributor

Seems like Android is failing to build on the GitHub runner, are you seeing the same locally?

https://github.com/Expensify/App/actions/runs/6424873394/job/17446462378#step:10:10762

Screenshot 2023-10-05 at 4 30 35 PM

@shubham1206agra
Copy link
Contributor

shubham1206agra commented Oct 6, 2023

@mrousavy Can you check this line?
https://github.com/mrousavy/react-native-vision-camera/blob/36e9e00930cac75c5890a2f8dc688874425def57/package/android/gradle.properties#L17

We are using kotlinVersion = '1.6.20'
Can you check the compatibility issues here?

@mrousavy
Copy link
Contributor Author

mrousavy commented Oct 6, 2023

Hi - this is the error:

image

From the docs it looks like this has been available since Kotlin 1.5, so not sure if 1.7 is really required. I'll try with 1.7

@mrousavy
Copy link
Contributor Author

mrousavy commented Oct 6, 2023

Either we need to add apply plugin: 'kotlin-android' to the build.gradle, or we need to upgrade Kotlin.

I believe the funcs I'm using are in the std lib of Kotlin, this is no third party extensions dep or anything afaik.

@allroundexperts
Copy link
Contributor

Waiting for the android build issue to resolve.

@mrousavy
Copy link
Contributor Author

mrousavy commented Oct 9, 2023

Update:

  1. I just updated the kotlinVersion from 1.6.x to 1.7.x because we might need that for VisionCamera
  2. Since react-native-worklets-core is not installed, Frame Processors are automatically disabled now:
    Screenshot 2023-10-09 at 11 30 08
  3. I have removed @react-native-async-storage from the dependencies because it is no longer used and the build was failing because of it. We now use Quick-SQLite/IndexDB under the hood for Onyx.

Since Cameras are hardware features and VisionCamera V3 now uses the low-level Camera2 API, we def. need to be quick with feedback here - I just know there's gonna be some weird Samsungs or something that break for some reason.

If there are any issues with VisionCamera V3, just ping me on Slack or create an issue with details on the VisionCamera issues page!

@mrousavy
Copy link
Contributor Author

mrousavy commented Oct 9, 2023

I got some issues on my end, will try to fix them asap to get the build up and running
Screenshot 2023-10-09 at 14 08 33

@mrousavy
Copy link
Contributor Author

mrousavy commented Oct 9, 2023

Okay was just Gradle cache from the WishList branch!

Everything works for me now! :)

cc @AndrewGable

trim.A1EA3EBD-AA04-4EC0-A9A9-BB579B2EB78F.MOV

I'm working on a real fix in VisionCamera in the meantime :)
@mrousavy
Copy link
Contributor Author

@allroundexperts @mountiny @AndrewGable just created a hot-fix for the blackscreen issue. I identified the problem and can confirm that it will be fixed with this PR: mrousavy/react-native-vision-camera#1996

I pushed that VisionCamera patch here, so it should work fine now (confirmed on my Huawei something), but I'll now switch to VisionCamera to build a true solid fix for this. :)

Do we want to wait for that VisionCamera update, or do we want to merge with that hot-patch?

@mrousavy
Copy link
Contributor Author

I think it'd be better to wait for the true VisionCamera fix. Just give me a few days and that's done :)

@mrousavy
Copy link
Contributor Author

I think I got mrousavy/react-native-vision-camera#2049 working pretty good - that fixes a ton of concurrency issues since now finally everything is happening under an atomic mutex 😄

on Android this was especially tricky because of the PreviewView since that could just go out of sync from time to time. I'll test more to see if this is still an issue or if everything is fixed now :)

If everything's fixed, I can release this and we should be good to go with the upgrade here in this PR

@puneetlath
Copy link
Contributor

nice!

@mrousavy
Copy link
Contributor Author

Okay, I pushed the new changes and now we are using VisionCamera 3.6.x, which contains the new atomically single-lock core/ API on Android.

Can we do another test build to gather some feedback? This is pretty early since I just released the new library, but from my testing so far it looks quite good.

cc @puneetlath @mountiny @AndrewGable

@mountiny
Copy link
Contributor

@OSBotify
Copy link
Contributor

minSdkVersion = 21
minSdkVersion = 26
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Woah, this is a problem. We'd be blocking 6.8% of users from using the app... That doesn't seem worth it for an improved camera feature.

What specifically requires that we use a platform min of Android 8?

254630961-b427f24b-c3cb-4a99-b160-e43021cfd0f5

Copy link
Contributor

@Julesssss Julesssss Oct 25, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see the following listed as high-level new features with Android SDK 26:

Screenshot 2023-10-25 at 09 19 12

Copy link
Contributor

@Julesssss Julesssss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to discuss this. Merging the PR as is will block just under 7% of potential users from using the app.

@puneetlath
Copy link
Contributor

Created a new issue for this here: #30732

@mrousavy
Copy link
Contributor Author

update: I just got a prototype running on my end that works on API 21, so we don’t need to drop the minSdk requirement! 💪

@puneetlath
Copy link
Contributor

Nice!

@mrousavy
Copy link
Contributor Author

Important update, I created a new PR: #37483

@mountiny
Copy link
Contributor

Can we close this in favour of #37483

@mrousavy
Copy link
Contributor Author

Ja 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants