Autofill Suggestion Prevention

Overview

Autofill Suggestion Prevention disables third-party autofill services and keyboard IME suggestions on sensitive input fields within your application. When enabled, the SDK automatically identifies password fields, credit card inputs, and other sensitive EditText views and prevents them from being indexed by autofill providers and suggestion engines. This mitigates the risk of credentials and personally identifiable information (PII) being harvested by malicious third-party autofill services or keyboard applications installed by the user.

The control uses Android's standard importantForAutofill attribute combined with input type flags to harden sensitive fields against autofill and IME caching without requiring manual instrumentation of every input in your application.

How It Works

Automatic Hardening

When protection is enabled, the control:

1. Registers activity lifecycle callbacks to monitor all activities in your application
2. On each activity resume, walks the view hierarchy starting from the window's decor view
3. Identifies sensitive EditText fields based on:

• Input type variations (TYPE_TEXT_VARIATION_PASSWORD, TYPE_TEXT_VARIATION_WEB_PASSWORD, TYPE_NUMBER_VARIATION_PASSWORD)
• PasswordTransformationMethod presence
• Autofill hints: password, newPassword, creditCardNumber, creditCardSecurityCode, smsOTPCode, username, emailAddress

1. For each sensitive field, applies:

• android:importantForAutofill="noExcludeDescendants" (blocks autofill services)
• TYPE_TEXT_FLAG_NO_SUGGESTIONS (blocks IME suggestion caching)

Dynamic View Detection

The control installs a ViewTreeObserver.OnGlobalLayoutListener on each activity to detect dynamically-added or modified views during runtime. This ensures protection coverage even for views created after the activity resumes, such as fragments inflated on-demand or views added by third-party libraries.

Manual Opt-In: markSensitive() API

For views that are not automatically detected (e.g., non-standard input fields or custom view components), you can explicitly request hardening using the public API:

import com.example.mobiledefender.MobileDefender;

// Mark a single view
EditText customPasswordField = findViewById(R.id.custom_password);
MobileDefender.markSensitive(customPasswordField);

// Or mark an entire ViewGroup (walks all children)
LinearLayout formContainer = findViewById(R.id.sensitive_form);
MobileDefender.markSensitive(formContainer);

This API is safe to call repeatedly (idempotent) and can be invoked at any point in your activity lifecycle.

Threats Mitigated

• Malicious Autofill Services: Prevents third-party autofill providers (including those distributed as malware or backdoored apps) from harvesting credentials, credit card numbers, social security numbers, and other PII entered into your application
• Keyboard Suggestion Caching: Blocks IME keyboard applications from caching sensitive input for later retrieval or suggestion, reducing exposure if the device is compromised
• Cross-App Data Leakage: Prevents autofill services from correlating user input across multiple applications installed on the device
• PII Exfiltration: Mitigates the risk of sensitive data being transmitted to remote servers operated by third-party autofill or keyboard vendors

Caveats

Impact on Legitimate Password Managers

When autofill is disabled on a field, legitimate password managers (e.g., Google Password Manager, 1Password, LastPass) will also be unable to fill credentials for that field. Users must manually copy-paste passwords or type them by hand.

Trade-off: This control prioritizes security over convenience. If your application's threat model does not require blocking all autofill providers, consider using manual opt-in (markSensitive()) only for the most sensitive fields (e.g., master password, PIN entry) rather than enabling global protection.

Coverage Limitations

The control only protects EditText views and their descendants. Custom input components that do not extend EditText (e.g., WebView form inputs, native C++ UI elements, game engine text fields) are not automatically protected and must be hardened separately if applicable.

Keyboard Suggestions on Non-Text Fields

The TYPE_TEXT_FLAG_NO_SUGGESTIONS flag only applies to TYPE_CLASS_TEXT input types. Numeric password fields (TYPE_CLASS_NUMBER with TYPE_NUMBER_VARIATION_PASSWORD) will have autofill blocked but may still receive IME suggestions on some keyboards. This is an Android platform limitation and cannot be fully mitigated without replacing the system keyboard.

Focused Fields

The control skips hardening for fields that currently have focus to avoid IME flickering and cursor jump issues. If a user is actively typing in a sensitive field when protection is enabled, that field will be hardened on the next layout pass or when focus moves to another view.

Support Matrix

How to Enable the Control

Navigate to Preventative Controls from the AppTego portal, and expand the Data Sharing Protection section. Under this section you will find the Autofill Suggestion Prevention control. Click Enable to enable it for the next build or for it to be applied with a live push (if enabled).

API Configuration Example

{
  "AutofillSuggestionPrevention": {
    "protection": true,
    "detection": false,
    "action": "none",
    "title": "Autofill Protection Enabled",
    "message": "Sensitive fields are now protected from third-party autofill services.",
    "buttons": ["OK"],
    "actions": ["close"],
    "redirects": [""]
  }
}

• protection: true — Enable automatic hardening of sensitive fields
• detection: false — No detection logic implemented; leave as false
• action, title, message, buttons, actions, redirects — Configure the MessagePrompt (currently not dispatched by this control; reserved for future use)

Set protection: false to disable automatic hardening (you can still use markSensitive() manually).

Best Practices

1. Test with Real Autofill Services: Before deploying to production, install third-party autofill applications (e.g., a password manager) on a test device and verify that sensitive fields do not offer autofill suggestions
2. User Communication: If your application previously supported autofill and you enable this control, consider notifying users that they will need to manually enter credentials or use copy-paste from their password manager
3. Selective Hardening: For applications with moderate security requirements, prefer using markSensitive() on critical fields (e.g., master password, 2FA codes) rather than enabling global protection, to preserve autofill convenience for less-sensitive fields
4. WebView Forms: If your application uses WebView with HTML form inputs, note that this control does not affect WebView. Use WebSettings.setSaveFormData(false) and consider the WebViewHardeningPrevention control for WebView-specific protections
5. Monitor False Positives: Review your application's EditText fields to ensure non-sensitive fields (e.g., search boxes, address forms) are not incorrectly classified as sensitive based on autofill hints. Remove or modify hints if necessary

Deployment Checklist

1. ✅ Test autofill behavior on devices with third-party password managers installed
2. ✅ Verify that WebView forms (if any) are not affected and harden separately if needed
3. ✅ Communicate autofill limitations to users if previously supported
4. ✅ Identify any custom input components and harden manually using markSensitive()
5. ✅ Confirm that non-sensitive fields are not incorrectly hardened
6. ✅ Test on API 26, 28, 31, and latest Android versions to ensure compatibility