I'm working on a contact directory integration. I know that I had this feature on an older phone and want to integrate this feature for my own app. Technical is my question similar to Provide the caller id for incoming call from my own app just that I want to support modern devices with Android 11+. On my Android 12 device my content provider is initialized and can be queried from my own code. However the phone app does not invoke my content provider.
Since I am absolutely sure that this feature has worked in the past. I used the emulator with the result that the app works fine with the API versions 27 and 29, but not with 30. Do you know an API change or was that feature silently dropped for privacy?
I talked with the Google Support and they told me that this feature would only work with work profiles in the context of the cooperate contacts from Google Work Accounts. Is that a general restriction or just something related with Google Accounts?
I made some deeper research and found the class ContactDirectoryManager. I modified the code so far that I was able to execute the onPackageChanged() method which detected my content provider correctly as expected. What am I doing wrong?
If you want some sample code check this repo: simplecallerid
Bonus question: Does that only work on Stock Android? I found a feature request for Samsung devices on their frensh community page. It seems that this is not supported there.
A bit late but I too was using "android.content.ContactDirectory". I can confirm that the AOSP dialer does not seem to invoke "phone_lookup" which was the only part my app was supporting.
I can query ContactsContract.Directory.ENTERPRISE_CONTENT_URI and see my app being registered and even make requests to it. But AOSP dialer no longer queries it.
Perhaps performance was reason for it to stop querying other directories.
I suppose we can dig in to AOSP commit history to find the change but who has the time?
My problem is there is a set of apps called good lock apps made by Samsung But they aren't supported by One UI core devices and some, not with android 11, So I would like to increase the API level of the application, add any android source code as well as somehow make it accessible by one UI core devices(By changing boolean).In Android studio, I tried the above but the code reverts back to the original, and am not able to run it, So can someone please say if the above is possible, if possible say how to proceed and if not please say what can be done alternatively, Thank you!
If it's a third party application, then the app would reside within data partition. And in any case you should be able to install the new version of a third party app unless you hold version number higher than the one present in the device.
While targeting SDK version higher than 25 make sure that you have REQUEST_INSTALL_PACKAGES to install a new application.
The other option is to uninstall the existing application (at your own risk), and reinstall the compiled version of the apk.
If you still face issues, please attach the logcat information while installing the apk, that could help us to look into the problem further.
I'm currently involved in an open source project which I regulary release in the Google PlayStore. As the statistics of android-usages show that less than 10% of my users use android 3 or lower I started to wonder if I should switch to Android 4.X. This gives me some more functionality which I can't include at the moment (SettingsFragment for example, which isn't even inside of the support library).
When I release a newer version with higher requirements in the PlayStore - what will happen to my users which don't fulfill this requirements? What about users who want to install my app with low android-versions? Is my app hidden for them as soon as I upgrade the app? Is there any chance that my current version of my app can still be found by lower devices and the newer version is available for newer devices? I would like to avoid having two seperate apps in the playstore as I would lose a few people.
I couldn't find anything in the Google-Docs so I needed to ask for help in this glory community ;)
You can target multiple different APIs using multiple APK's. Just use your current version for old versions and create a new APK for everyone else. More here: http://developer.android.com/google/play/publishing/multiple-apks.html
Hope this helps, let me know if you need more info.
I understand how multiple APKs work on Google Play, but so far I've supported a single APK for V7 (2.1) and up. I'd like to start using Android 3.x-4.x+ features that could be more difficult to make backwards compatible, and I wouldn't mind not having to build in that growing compatibility library. But I still want to make the product available to Android 2.x users, even though that version will be "frozen" and not receive future product enhancements.
So how should this best be done? I could use the basic multiple-APK approach, but then users of 2.x devices might see things in the product description that are not in the APK that they would be installing. But would the version number show up correctly based on the APK that matches the user's device?
Any other ideas from someone who's done this?
How should I make the choice ? What are the parameters I should take into account ?
First of all you should take into account relative number of devices running a given version of the Android platform
Have a look at Android versions market share. I would develop for 1.6+. If you will realize in the middle of development that you want some API feature from newer version, you will have 3 choices:
Don't use that feature
Detect Android version from the app and then decide what to do
Change required Android version in your manifest file and project settings
If possible, you should support the oldest Android version still in widespread use. That would be 1.5. If you need features from later versions, you might consider requiring newer versions, but if you can do your work on the oldest version still available, you should to increase the number of people who are able to use your app.
The Oldest version that supports all the functionality your application requires.
For example: Your app needs multitouch? Target version 2.1
My application doesn't need any functionality introduced in newer versions, so I target 1.5
I agree with the answers posted above, and I would add that on the android API reference site, most of the time the minimum API level is specified (http://developer.android.com/reference/android/package-summary.html).
You can have a look at this page to identify the Android version associated with a given API level: http://developer.android.com/guide/appendix/api-levels.html
Personally, I develop everything for 2.1. There are only a handful of devices that still run <2.0 and most of those people have already put custom roms on them already. I know it kind of screws people with older phones, but I don't like the idea of crippling my app just to make it backwards compatible.
Also I feel like developing for >2.0 encourages people to upgrade their phones =P
#Falmarri: I see some flaws in your logic. Usually I'd tend to follow the same path as you if I'd be developing on another Plattform, like Windows. I do my C# applications always against the latest (non-beta) version available, as the .NET Framework is freely available for everyone (take out the new releases not being available for Win2k, which is almost 10 years old now).
With Android this attempt don't work. A majority of the devices which run 1.5 and 1.6 do it because there is no update for this device, as the manufacturer stopped developing new versions for this phone (either to motivate users to get a new upgraded one) or because it's to time intensive to make backports to this "old" devices.
So this uses don't have the "free choice" of upgrading their phones. Technically it's possible of course with rooted/custom ROMs, however most users do not have the technical knowledge to root/flash their devices with custom ROMs or don't want to lose their warranty.
So if you want to offer your App to as much people as possible, you have to develop it in mind with a much older OS version. In Android case, against 1.5.
And this is basically what I do. I've done my Apps with 1.5 in mind.
If you are developing using Android Studio:
1. Go to Tools --> Android --> AVD Manager
2. Click the Create Virtual Device... button of the AVD Manager dialog.
3. Select a Device on the "Select Hardware" wizard page of the dialog and click Next.
4. In the bottom right of the "System Image" wizard page you will see the following:
If you click the "API level distribution chart" link, it will provide you a summary of cumulative distribution by API level. I assume the information is kept up-to-date with each release. From there you can click on an API level to get specific information about that API level. Based on the information presented there, you need to use API level 18 or lower in order for about 75% of the current Android Market to be able to use you application.
Perhaps this is the type of information you are looking for. Hope it helps!
This is a direct quote from the Android Docs:
Generally, it’s a good practice to support about 90% of the active devices, while targeting your app to the latest version.
In a practical sense, this is impossible unless you had an unlimited budget.
Even Android themselves are only releasing security updates from version 8 onward.
As of right now, I recommend supporting Android 7 onward. This should cover 57.9% of market share.
If you scroll to the bottom of this page, there is a table that shows Android support information.
It will be updated monthly as the figures I quote above will change with time.