Okay, this is a frustrating situation, but let\’s break down the likely causes and best steps to take to resolve this Play Store rejection. It seems like Google\’s review process is still flagging your app due to the historical use of the Accessibility API, even though you\’ve removed the library. Here\’s a comprehensive approach to get your app approved:\n\n**Understanding the Problem**\n\n* **Google\’s Lingering Flag:** The most probable reason for the continued rejection is that Google\’s automated and human review processes are still detecting traces of accessibility service usage, even after removing the library. This might be due to:\n * Cached app information on Google\’s side.\n * The original manifest from a previous build being associated with your app ID.\n * Potential remnants of the library\’s code inadvertently left in your project.\n\n* **Misinterpretation of \”Prominent Disclosure\”:** Even if you\’ve added a Terms & Conditions screen and UI for prominent disclosure, Google might not find it sufficient because it\’s still associated with *accessibility*. The core issue isn\’t just the disclosure; it\’s *why* the disclosure is there if you\’re not actively using the Accessibility API. The current implementation might confuse the review team.\n\n* **Target SDK 31 Implications:** While not directly related to the Accessibility API (unless improperly implemented), targeting API level 31 (Android 12) increases the scrutiny of permission requests and user data handling.\n\n**Best Answer Steps (Actionable & Detailed)**\n\nHere\’s a phased approach to tackle the problem, starting with the most likely solutions:\n\n**Phase 1: Clean Build & Manifest Verification (Most Likely Fix)**\n\n1. **Complete Code Cleanup:**\n * **Thoroughly Review Your Entire Project:** Use your IDE\’s search/find functionality to search for these terms:\n * `android.permission.BIND_ACCESSIBILITY_SERVICE`\n * `AccessibilityService`\n * The name of the cobrowse library you removed (e.g., `com.cobrowse.sdk`)\n * Any related class names or methods from the cobrowse library\’s documentation.\n * **Check all Gradle Files:** Review `build.gradle` files (both project-level and app-level) for any leftover dependencies or configurations related to the cobrowse library. Remove any remnants completely. Sync your Gradle files after making changes.\n * **Clean Project:** In Android Studio/IntelliJ IDEA, use **Build > Clean Project**.\n * **Rebuild Project:** Then, use **Build > Rebuild Project**. This forces a complete recompilation.\n\n2. **Manifest Check (Absolutely Critical):**\n * **Double-Check `AndroidManifest.xml`:** Ensure the following is **absolutely absent**:\n * ``\n * Any `` elements that define an `android.accessibilityservice` intent filter. Example of what to remove:\n “`xml\n \n \n \n \n\n \n “`\n * **Merged Manifest:** After cleaning and rebuilding, inspect the **Merged Manifest**. In Android Studio, open `AndroidManifest.xml`, and at the bottom, click the \”Merged Manifest\” tab. This shows the final manifest that will be packaged with your app. Verify that the accessibility permission and service are *completely* gone. The merged manifest reveals what the build system is actually using, after Gradle merges all the manifests from your modules and dependencies.\n\n3. **APK Analyzer:**\n * Build a release APK (Build > Build Bundles(s)/APK(s) > Build APK(s)).\n * Use Android Studio\’s **Build > Analyze APK…** to inspect the generated APK.\n * Check the `AndroidManifest.xml` inside the APK to *absolutely confirm* that the accessibility permission and service are not present. This is the ultimate verification.\n\n4. **Remove Unnecessary Prominent Disclosure:**\n\n * **Stop referring to Accessibility API:** If you\’ve removed the library and the accessibility service and permission, **remove the accessibility-related prominent disclosure from your app.** Keeping it will only confuse the Google review team. Your prominent disclosure should only focus on the permissions your app *actually* uses (camera, microphone, location, etc.) and *why* you need them.\n\n5. **New Release:**\n * Increment your `versionCode` and `versionName` in your `build.gradle` (app-level). This is crucial. Google might be caching information based on your app version. A new version will force them to re-evaluate.\n * Create a new release in the Play Console and upload the new APK.\n * In the \”What\’s new in this release?\” section, explicitly state: \”**Removed Accessibility API Usage:** The app no longer uses the Accessibility API. We have removed the third-party library that previously required this permission. The app functions as intended without the Accessibility API.\”\n\n**Phase 2: Adjusting Disclosure and Communication (If Phase 1 Fails)**\n\nIf the above steps don\’t work, it\’s possible Google is still concerned about *how* you\’re handling permissions in general. Even without accessibility, your prominent disclosure might not be clear enough.\n\n1. **Refine Prominent Disclosure (If Applicable):**\n * **Contextual Explanation:** Ensure that the prominent disclosure UI appears *immediately* before requesting each sensitive permission (camera, microphone, location, etc.). Don\’t bundle all permissions into a single disclosure.\n * **Clear Language:** Use straightforward language that explains *exactly* why the app needs the permission and how it will be used. Avoid technical jargon.\n * **Example:** \”To take and share photos, this app needs access to your camera. We will only use the camera when you tap the camera button in the app.\”\n * **User Consent:** The prominent disclosure should clearly ask for the user\’s consent *before* the permission dialog is shown. For example, a button labeled \”Allow [Permission]\” or \”Continue.\”\n\n2. **Play Console Communication (Use Sparingly):**\n * **Reply to the Review Team:** In the Play Console, find the rejection notice. There should be a way to reply to the review team (though it can be difficult to find).\n * **Polite and Concise Message:** Keep your message extremely brief and focused:\n * \”We have completely removed the Accessibility API from our app. The latest version (version code X) does not contain any code or permissions related to the Accessibility API.\”\n * \”We have verified this by cleaning the project, rebuilding, inspecting the merged manifest, and analyzing the APK file.\”\n * \”Please re-review the app to confirm the removal of the Accessibility API. Thank you for your time and attention to this matter.\”\n\n**Phase 3: Last Resort – Internal Testing & Contacting Google**\n\n1. **Internal Test Track:**\n * Release your app to the Internal Test track in the Play Console. This allows you to distribute the app to a small group of testers (yourself, colleagues, etc.).\n * Have your testers install the app and thoroughly use all features. Verify that no accessibility features are being triggered or referenced.\n * Sometimes, going through the internal test track can help \”reset\” the app\’s status in Google\’s system.\n\n2. **Google Play Support (Difficult but Try):**\n * While you mentioned difficulty contacting them, keep trying to find a way to contact Google Play Developer Support. Look for a \”Contact Us\” or \”Help\” link in the Play Console. Be persistent.\n * When you do get in touch, be polite, professional, and provide all the details: your app\’s package name, the rejection reason, the steps you\’ve taken to resolve the issue, and the new version code.\n\n**Important Considerations:**\n\n* **Be Patient (Unfortunately):** The Google Play review process can be slow and frustrating. Continue to be patient and persistent.\n* **Honesty is Key:** Never try to deceive the Google Play review team. Be transparent about what you\’ve done to address the issue.\n* **Legal Advice (If Necessary):** If you\’re facing significant financial losses due to the app rejection, consider seeking legal advice from an attorney who specializes in app store policies.\n\nBy following these steps meticulously, you should be able to resolve the issue and get your app approved. The key is to demonstrate clearly to Google that you\’ve completely removed the Accessibility API and are handling permissions responsibly. Good luck!\n
