Fix android build #106
Fix android build #106
Conversation
|
Warning Rate limit exceeded@cp-sneha-s has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 15 minutes and 27 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. WalkthroughThe changes in this pull request involve modifications to the Android build configuration and workflow files. The Changes
Possibly related PRs
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Outside diff range and nitpick comments (4)
android/app/build.gradle (2)
31-32: Use consistent version property referencesFor consistency with other Flutter properties, use the same property access style:
-versionCode = flutter.versionCode -versionName = flutter.versionName +versionCode flutter.versionCode +versionName flutter.versionName
19-19: Use consistent Java version referenceFor consistency with compileOptions:
-jvmTarget = JavaVersion.VERSION_1_8 +jvmTarget = '1.8'lib/ui/sign_in/bloc/sign_in_view_bloc.dart (2)
Line range hint
67-77: Enhance Apple sign-in error handling and flow.While the current implementation is good, consider these improvements:
- Handle more specific FirebaseAuthException codes
- Move the null check earlier in the flow
- Use more specific error messages
Consider this improved implementation:
- } catch (e, stack) { - if (e is FirebaseAuthException && e.code == 'canceled') { + } on FirebaseAuthException catch (e, stack) { + if (e.code == 'canceled' || e.code == 'popup_closed_by_user') { emit(state.copyWith(appleSignInLoading: false)); return; } + String errorMessage = switch (e.code) { + 'invalid-credential' => 'Invalid credentials provided', + 'user-disabled' => 'This account has been disabled', + _ => somethingWentWrongError + }; FirebaseCrashlytics.instance .recordError(e, stack, reason: 'Apple Sign In Error'); emit(state.copyWith( - appleSignInLoading: false, error: somethingWentWrongError)); + appleSignInLoading: false, error: errorMessage)); + } catch (e, stack) { + FirebaseCrashlytics.instance + .recordError(e, stack, reason: 'Apple Sign In Error'); + emit(state.copyWith( + appleSignInLoading: false, error: somethingWentWrongError)); }
Line range hint
1-85: Consider architectural improvements for better maintainability.The current implementation could benefit from:
- Centralizing error handling logic to ensure consistency between sign-in methods
- Extracting common sign-in flow logic to reduce code duplication
Consider creating:
- A common error handler:
class AuthErrorHandler { static SignInState handleError( dynamic error, StackTrace stack, String source, bool loading, ) { if (error is FirebaseAuthException) { if (error.code == 'canceled' || error.code == 'popup_closed_by_user') { return SignInState(loading: false); } // Handle other specific cases } FirebaseCrashlytics.instance.recordError(error, stack, reason: '$source Error'); return SignInState(loading: false, error: somethingWentWrongError); } }
- A base sign-in method:
Future<SignInState> _handleSignIn( Future<firebase_auth.User?> Function() signInMethod, Future<Account?> Function(firebase_auth.User) getUserMethod, bool loading, ) async { try { final authUser = await signInMethod(); if (authUser == null) return SignInState(loading: false); final user = await getUserMethod(authUser); if (user == null) { return SignInState( loading: false, error: 'User not found', firebaseAuthUser: authUser, ); } await _userStateNotifier.setUser(user); return SignInState(loading: false, signInSuccess: true); } catch (e, stack) { return AuthErrorHandler.handleError(e, stack, 'Sign In', loading); } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (10)
.github/workflows/android_build.yml(0 hunks)android/app/build.gradle(2 hunks)android/app/src/debug/AndroidManifest.xml(1 hunks)android/app/src/main/AndroidManifest.xml(1 hunks)android/app/src/main/kotlin/com/canopas/projectunity/MainActivity.kt(0 hunks)android/app/src/main/kotlin/com/canopas/unity/MainActivity.kt(0 hunks)android/app/src/profile/AndroidManifest.xml(1 hunks)android/gradle/wrapper/gradle-wrapper.properties(1 hunks)android/settings.gradle(1 hunks)lib/ui/sign_in/bloc/sign_in_view_bloc.dart(1 hunks)
💤 Files with no reviewable changes (3)
- android/app/src/main/kotlin/com/canopas/projectunity/MainActivity.kt
- android/app/src/main/kotlin/com/canopas/unity/MainActivity.kt
- .github/workflows/android_build.yml
✅ Files skipped from review due to trivial changes (3)
- android/app/src/profile/AndroidManifest.xml
- android/app/src/debug/AndroidManifest.xml
- android/gradle/wrapper/gradle-wrapper.properties
🔇 Additional comments (2)
android/app/src/main/AndroidManifest.xml (1)
1-1: Verify package name configuration
The package attribute has been removed from the manifest. While this is supported when using the Android Gradle Plugin namespace feature, ensure that:
- All resource references in code are updated
- The namespace in build.gradle matches the previous package name to maintain compatibility
Also applies to: 3-3
✅ Verification successful
The previous commands didn't yield results, so let's try a broader search to:
- Find namespace configuration in build.gradle
- Look for R imports across different file types
- Check package declarations in source files
- Examine MainActivity implementation
This will help us verify the package name configuration and its impact on resource references.
Package configuration is properly set up
The package name is correctly configured in the Android project:
- The namespace is defined in build.gradle as
com.example.canopas_unity - The applicationId is set to
com.canopas.projectunity - MainActivity is properly declared in the correct package structure
The removal of the package attribute from AndroidManifest.xml is safe as the Android Gradle Plugin's namespace feature is being used correctly. No resource reference issues were found in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for potential resource reference issues
rg "R\." --type kotlin --type java
# Check for activity class references
rg "\.MainActivity" --type kotlin --type java
Length of output: 84
Script:
#!/bin/bash
# Check build.gradle files for namespace configuration
fd "build.gradle" --type f --exec cat {}
# Check for any R imports or references in all text files
rg -t txt -t java -t kotlin -t xml "import.*R" -A 2
# Look for package declarations in Java/Kotlin files
rg "package\s+[\w\.]+" --type kotlin --type java
# Check MainActivity declarations
fd "MainActivity" --type f --exec cat {}
Length of output: 3463
android/app/build.gradle (1)
Line range hint 33-37: Verify APK naming convention
The APK naming uses versionName and versionCode variables. Ensure these are properly populated from flutter.versionName and flutter.versionCode:
✅ Verification successful
APK naming convention is correctly configured ✅
The version properties are properly set up:
- Flutter version is defined in
pubspec.yamlas1.0.2+2 - The
build.gradlecorrectly referencesflutter.versionNameandflutter.versionCode - These values are properly used in the APK naming convention
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if version properties are defined in Flutter
grep -r "version:" $(find . -name "pubspec.yaml")
Length of output: 79
Script:
#!/bin/bash
# Check how versionName and versionCode are defined in build.gradle files
rg "versionName|versionCode" -A 2 --type gradle
Length of output: 517
| android { | ||
| compileSdkVersion 34//flutter.compileSdkVersion | ||
| namespace = "com.example.canopas_unity" |
There was a problem hiding this comment.
Update namespace to use production domain
The namespace is using an example domain which should not be used in production:
-namespace = "com.example.canopas_unity"
+namespace = "com.canopas.projectunity"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| namespace = "com.example.canopas_unity" | |
| namespace = "com.canopas.projectunity" |
| compileSdkVersion 34//flutter.compileSdkVersion | ||
| namespace = "com.example.canopas_unity" | ||
| compileSdk = flutter.compileSdkVersion | ||
| ndkVersion = flutter.ndkVersion |
There was a problem hiding this comment.
Fix inconsistent SDK version configuration
The compileSdkVersion is both hardcoded and referenced from flutter:
-compileSdkVersion 34//flutter.compileSdkVersion
-compileSdk = flutter.compileSdkVersion
+compileSdkVersion flutter.compileSdkVersionCommittable suggestion skipped: line range outside the PR's diff.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (2)
android/app/build.gradle (2)
Line range hint
39-49: Security: Remove debug signing configuration from productionThe fallback signing configuration uses development keys which should not be included in the production build configuration. Consider moving this to a separate debug configuration file.
Line range hint
66-71: Debug builds should not use minificationEnabling minification for debug builds can make debugging more difficult. Consider disabling minification for debug builds:
debug { - minifyEnabled true + minifyEnabled false debuggable true signingConfig signingConfigs.release }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
.github/workflows/android_build.yml(1 hunks)android/app/build.gradle(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/workflows/android_build.yml
🔇 Additional comments (6)
android/app/build.gradle (6)
8-8: Fix inconsistent SDK version configuration
The compileSdkVersion is both hardcoded and referenced from flutter.
9-9: Update namespace to use production domain
The namespace is using an example domain which should not be used in production.
19-19: LGTM: Improved JVM target configuration
Good improvement using JavaVersion constant instead of string literal for better type safety.
29-30: Critical: Extremely high minSdkVersion
Setting minSdkVersion to 34 (Android 14) will prevent the app from running on most Android devices.
30-32: LGTM: Proper version configuration
Good use of Flutter version references for consistent version management.
82-82: LGTM: Proper file ending
Good practice to end the file with a newline.
Purpose
Summary of Changes
Test steps
Conformity
Visual Evidence (Video, Images or Gif)
Summary by CodeRabbit
Release Notes
New Features
Bug Fixes
Chores
Documentation