As per Android 8.0 Behavior Changes,
For apps installed on a device running Android 8.0, the value of ANDROID_ID is now scoped per app signing key, as well as per user. The value of ANDROID_ID is unique for each combination of app-signing key, user, and device. As a result, apps with different signing keys running on the same device no longer see the same Android ID (even for the same user).
To test above changes, I made two test APK and found below behavior (tested on Nexus 5X, OS 8.0.0):
In case when targetSdkVersion 26, compileSdkVersion 26, buildToolsVersion 26.0.0, The two different apk (along with different package name) generated from the same windows machine is displaying same ANDROID_ID. When APK is generated with same package name from the different machine, is displaying the different ANDROID_ID.
Below is my query:
Is this correct behaviour ? Why is two different APK showing the same ANDROID_ID?
Any change if my application's ANDROID_ID may get changed (without un-install/ re-install)?
Getting same behaviour on Nexus 5x, OS 6.0.1,
targetSdkVersion 23, compileSdkVersion 23, buildToolsVersion 25.0.0 . I don't see any specific behaviour change in Android O. What I am missing ? Why getting same behaviour ?
As other answers explain why you are getting same id for different apks, they are correct.
Best way to check this behaviour with creating two different certificates and sign your apk using these two certificate.
Summarizing to all your confusion, [From Changes to Device Identifiers in Android O]
The ANDROID_ID value won't change on package uninstall/reinstall, as long as the package name and signing key are the same. Apps can rely on this value to maintain state across reinstalls.
If an app was installed on a device running an earlier version of Android, the Android ID remains the same when the device is updated to Android O, unless the app is uninstalled and reinstalled.
The Android ID value only changes if the device is factory reset or if the signing key rotates between uninstall and reinstall events.
This change is only required for device manufacturers shipping with Google Play services and Advertising ID. Other device manufacturers may provide an alternative resettable ID or continue to provide ANDROID ID.
Its behaving as intended.
As highlighted by you in the question:
As a result, apps with different signing keys running on the same
device no longer see the same Android ID
When you use Android studio to build different APKs the debug signing key is same. As a consequence you would see same Android_ID
But when you use different PC, the debug signing key is different. Hence you see different Android_ID.
Related
I've been trying to simulate a scenario where I want to check how my Android app behaves after an OS update. But I don't have access to physical device at the moment where I can run an actual OS update scenario, so I have to resort to trying it out on android emulator (AVD).
Is there a way I can update the OS on AVD as if it were a real phone, and be able to see how my app would behave?
What I essentially want to test out is this:
Let's say that I have android with API level 21 installed on a device. I install an app with maxSdkVersion 21 on it. Now my device upgrades to API level 22. What will happen to my app?
Will the OS silently get my app uninstalled and keep it that way?
Will the OS check with play store to see if a build of my app with a supported SDK level is available and download and install that instead?
Will the OS at least give me a visual warning or prompt that this particular app is not compatible on the device anymore and tell me what I could do next?
The Android Developer Docs recommends that using maxSdkVersion is not a good idea since in some cases uninstalls would happen.
An application declaring maxSdkVersion="5" in its manifest is published on Google Play. A user whose device is running Android 1.6 (API Level 4) downloads and installs the app. After a few weeks, the user receives an over-the-air system update to Android 2.0 (API Level 5). After the update is installed, the system checks the application's maxSdkVersion and successfully re-validates it. The application functions normally. However, some time later, the device receives another system update, this time to Android 2.0.1 (API Level 6). After the update, the system can no longer re-validate the application because the system's own API Level (6) is now higher than the maximum supported by the application (5). The system prevents the application from being visible to the user, in effect removing it from the device.
Warning: Declaring this attribute is not recommended. First, there is no need to set the attribute as means of blocking deployment of your application onto new versions of the Android platform as they are released. By design, new versions of the platform are fully backward-compatible. Your application should work properly on new versions, provided it uses only standard APIs and follows development best practices. Second, note that in some cases, declaring the attribute can result in your application being removed from users' devices after a system update to a higher API Level. Most devices on which your application is likely to be installed will receive periodic system updates over the air, so you should consider their effect on your application before setting this attribute.
What I also want to figure out is what happens next. And what does "in some cases" essentially mean?
I have created 2 demo apps to check your questions using the emulator. I have updated emulator's API level and restart it because every device gets restart after the system update. Please see this video what happening :)
Will the OS silently get my app uninstalled and keep it that way?
yes app get uninstlled
Will the OS at least give me a visual warning or prompt that this
particular app is not compatible on the device anymore and tell me
what I could do next?
app getting uninstalled without any message or warning
Will the OS check with play store to see if a build of my app with a
supported SDK level is available and download and install that
instead?
I think this can be check if the app is available on the play store. So I'm unable to test this. If anyone knows the answer to this question, please comment
I recently switched mobile phone operator and I brought my number with me. However, the number stored in the SIM, which is visible to Android, is incorrect (it is the number that was given to me before the switch over).
Somebody wrote a little app a few years ago that allows changing the number on the SIM:
https://github.com/fommil/MyPhoneNumber/blob/master/src/org/lytsing/myphonenumber/MyPhoneNumber.java
I have no idea how the original author ever got it to compile, I've needed to use reflection (as others have discovered).
But there is an additional problem: apparently this must be run by an app signed with the "system signature key": https://stackoverflow.com/a/6029410/1041691
There is IntelliJ documentation for signing Android apps, but I am failing to interpret/translate the (Eclipse) instructions for dealing with this fabled "system" key: https://stackoverflow.com/a/3651653/1041691
How do I run an app on my Nexus 5 with full access? (which is physically connected by USB)
How do I run an app on my Nexus 5 with full access?
You don't, except perhaps by compiling your own version of the Android OS from source, rolling that into a ROM mod, and installing that ROM mod. Then, the signing key will be your own generated one, and you can sign other SDK apps with that key to grant them access to system-level permissions.
You might be able to install some off-the-shelf ROM, if they publish their signing key, and I have no idea if any of them do. I certainly wouldn't.
I'm wondering, if I have an APK that supports for example Android 2.3.7 and below and another that supports 3.0 and above what will happen if a user with a device with 2.3.7 updates it's OS to 4.0 ?
For example, a Samsung Galaxy S II update from 2.3.X to 4.0 ?
Will the app be auto-magically replaced? Will it crash?
I think it depends on your version numbering scheme. If the app version that supports 3.0+ has a higher version number than the one that doesn't, the market will likely show an upgrade available. It should update like any other app (but it may not be immediate): if the user has auto-updating on for the app, it will update itself after a while, but if not, it will appear to the user as having an update available and will wait on them to download it. Unless the permissions are different between the versions.
Whether it crashes or not will be determined by the app itself: what happens if you yourself install the 2.3.7 APK on a 4.0 device (which may or may not require a quick change to the manifest file)?
I'm pretty sure it won't be replaced. The documentation says, that you publish multiple APKs under one Google Play (Market) entry. So if user has a specific APK which has a max-sdk parameter set in Manifest, then it won't work on newer system. But if you don't have max-sdk specified and there are no conflicts, it will.
EDIT: But as Jon O said, it should be possible for the user to update the app, because it's still the same Google Play entry.
I'm sure this is a dumb question but Googling got me nowhere.
Does each device vendor do its own Android build? More to the point, does each device vendor sign its build with its (the vendor's) own system signature key, such that we should not expect any two Android devices (at least, devices from different vendors) to utilize the same system signature key?
Example: I know I'm not the first person to want to run an app with sharedUserId="android.uid.phone" and process="com.android.phone". But this requires my app to have been signed with the system signature key. If, by some miracle, I were able to obtain the system singnature key for my Acer device and sign my app with it, would this restrict my app to run on Acer devices (or perhaps just my particular model), since other vendors' devices would have their own Android builds and their own system signature keys?
More to the point, does each device vendor sign its build with its (the vendor's) own system signature key, such that we should not expect any two Android devices (at least, devices from different vendors) to utilize the same system signature key?
Generally, yes. At least, all the serious vendors do.
If, by some miracle, I were able to obtain the system singnature key for my Acer device and sign my app with it, would this restrict my app to run on Acer devices (or perhaps just my particular model), since other vendors' devices would have their own Android builds and their own system signature keys?
Well, your app probably would run on other devices, but it will not be able to obtain that shared user ID.
My application is targeted for API 8 (Froyo) minimum, however I'm getting a message in the Android Market that says "This report was sent in by a pre-Froyo client, which did not include a stack trace."
When does Android check that the Min-sdk is greater than or equal to the API version on the phone. Is it at runtime or market download time?
Your app's minSdkVersion is filtered by the Market and the phone, however there are a few ROMs out there that disable this filtering at the phone-level. If you're seeing a report from a phone that is below your minSdkVersion it usually means the user installed the app directly, not from the market, and their phone tried to run it even though the SDK version wasn't usable by the device. This would result in a bug report being posted to the Market, but the Market app doesn't ask the device how it got the app in the first place.
You'll see this once in a really long while--it's nothing to be alarmed about.
I believe it filters in the market. Perhaps somebody got ahold of your APK and distributed it to a pre-Froyo phone? Just a guess.
edit - taken from the ref http://developer.android.com/guide/topics/manifest/uses-sdk-element.html: An integer designating the minimum API Level required for the application to run. The Android system will prevent the user from installing the application if the system's API Level is lower than the value specified in this attribute. You should always declare this attribute.
Perhaps you have confused minSdkVersion and targetSdkVersion?