Android 10设备标识符权限异常及游戏进度恢复咨询

Hey there, let's work through your two problems step by step—they're common hurdles when adapting to Android's privacy restrictions, so you're not alone!

1. Stop Unwanted READ_PHONE_STATE Permission Requests #

The issue here is that some of your dependencies (with minSDK < 4) are automatically merging the READ_PHONE_STATE permission into your app's manifest, even after you removed your own declaration. Here's the fix:

Add this line directly to your app's AndroidManifest.xml to force-remove the permission, overriding any additions from dependencies:

<uses-permission android:name="android.permission.READ_PHONE_STATE" tools:node="remove" />

Make sure you have the xmlns:tools="http://schemas.android.com/tools" attribute in your root <manifest> tag for this to work.

If you want to track down exactly which dependency is adding the permission, run this command in your project root:

./gradlew app:dependencies

Look through the dependency tree for any library that includes the permission—but even if you don't find it, the tools:node="remove" trick will reliably block it from being included in your final APK.

2. Migrate User Identifiers Without Losing Game Progress #

Switching away from device IDs requires a smooth data migration to keep users' progress intact. Here's a solid approach:

Step 1: Generate a New Persistent User ID #

Create a new, stable user identifier that doesn't rely on restricted device info. The most straightforward option is a UUID:

// Generate and store a UUID on first launch
SharedPreferences prefs = getSharedPreferences("AppPrefs", MODE_PRIVATE);
String newUserId = prefs.getString("new_user_id", null);
if (newUserId == null) {
    newUserId = UUID.randomUUID().toString();
    prefs.edit().putString("new_user_id", newUserId).apply();
}

Alternatively, you could use Firebase Anonymous Authentication (if you're using Firebase) for a cloud-backed ID that can persist across app reinstalls (users can later link it to a Google/Facebook account if they want).

Step 2: Migrate Existing Data #

When the app starts, check if there's an old device ID stored (either in SharedPreferences or your database). If it exists and the new user ID hasn't been linked yet:

• Run a background database update to replace all references to the old device ID with the new user ID.
• Mark the migration as complete (e.g., save a flag in SharedPreferences) so it doesn't run again.

Example pseudocode for the migration:

String oldDeviceId = getOldDeviceIdFromStorage(); // Your existing method to get ANDROID_ID/IMEI
String newUserId = getNewUserId(); // The UUID from above

if (oldDeviceId != null && !isMigrationComplete()) {
    // Run this on a background thread to avoid ANR
    new AsyncTask<Void, Void, Void>() {
        @Override
        protected Void doInBackground(Void... voids) {
            gameDatabase.progressDao().updateUserId(oldDeviceId, newUserId);
            return null;
        }

        @Override
        protected void onPostExecute(Void aVoid) {
            markMigrationComplete(); // Save a flag in SharedPreferences
        }
    }.execute();
}

Step 3: Support Fallback During Transition #

For a few versions, keep the old device ID field in your database. When loading a user's progress, first check for the new user ID. If no data is found, check the old device ID, run the migration on the fly, and then use the new ID going forward. This ensures even users who haven't opened the app in a while don't lose progress when they update.

Step 4: Deprecate Old Device ID Logic #

Once you're confident most users have migrated (track this with analytics if possible), you can remove all code related to the old device ID and clean up the database field.

内容的提问来源于stack exchange，提问作者Gag Baghdasaryan