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?
Related
We use a 3rd party SDK that crashes 100% of the time on Asus devices running Android 7.0 (we can't get rid of the SDK). The same device running 7.1 will not crash. I know I can block specific devices using the Google Play Developer Console, but I'd rather not block the devices since there's a chance that they either haven't updated to 7.0, or they have been updated to 7.1.
I asked Google Play support if there was something I was missing in the console, and they said it's not possible to block a manufacturer-API combination from the dev console. However, they said there was a way to do so using the manifest, but that they weren't qualified to tell me exactly how. I haven't been able to find any information on this. The docs mention how to declare restricted screen support using the manifest, but nothing about a manufacturer.
Does anybody know a way to accomplish this using the manifest?
I am wondering if that if I only test this application in this version of API, will it work still the same as API versions above? If it doesn't, what's a good way to develop an application? Create it 1 by 1 for each API?
I heard from my friend that he developed his app in KitKat but when he tested it in Marshmallow, some features are not working right.
My friend also met a problem similar to your friend's. His app runs well in kitkat but when he use Lollipop, the camera cannot work. There is nothing absolute, you can only test your app on as many devices as possible.
For some deprecated methods, you should keep an eye on them to make sure they can still work on higher sdk levels.
Something even more annoying is that some manufactures change the API so that they can customize the OS deeper such as Xiaomi MIUI.
There is no such guarantee. You should pay attention every time a new major android version is released as it might affect your app, even if you're targetting a lower api level.
For example, Android O will limit background execution, even if you don't target api level 26. See: https://developer.android.com/preview/behavior-changes.html#atap
Things are changing since every android update and here are a few of the many things which one should keep in mind while developing an application:
Runtime permissions are a major change in Marshmallow and onwards. Gone are the days when developers could add whatsoever permissions. Runtime permissions prompts the user to grant a permission to run a specific feature in the application and the user has an option of denying it. In case you haven't checked if your app has been granted the required permissions before conducting an operation you will get a security exception.
Permission groups has been added. Each group has a set of permissions and one should check in which group your required permission falls before prompting for it.
Location services API has also undergone some changes. As per the old API the user would be taken to the settings page in order to turn on the location services. This has changed and now the user can be prompted to turn on the location services using the new API. Check documentation for more details.
Android O limits the number of background tasks which can be executed. So as a developer you have to be wise about which task is being executed in which thread.
App signing process has also changed significantly especially for application supporting marshmallow and above.
These are just a few of the things which one may keep in mind while developing an application. Also look out for deprecated api's.
after searching a lot on internet i didn't get the answer I am looking.
Suppose if I made an application or if I have downloaded another application from play store then How can I test or check whether application is well developed or not. OR in short how can I find some flows in an application.
For example :
Application is taking more time then a benchmark time to start or
navigating to page.
Or its design is not good.
It is not supported on a lot of device. etc.
Is there any platform to test an android application. Or some online resources , books or test cases using which I can follow those guideline to test or to make an efficient and better application.
As asked in comments to specify whether i am asking about well developed or a well working application. Actually i am asking about well working application for an already built application. And well developed for developing an application.
UI related issues check.
1) A phone can be built well, and have fast internals, but if the touch(UI Designing) of the app is of poor quality, the experience will be damaged. This is of special concern with Android.
2) Check for image quality issues
3) Sensitivity and multiple-touch
Programming related issues check.
1) Detect flaws immediately and release a bug-free app straight away
2) Applause ANALYTICS
3) DO data testing or Load testing
4) Apps should provide the performance, stability, and responsiveness expected by users
5) From each app screen, press the device's Home key, then re-launch the app from the All Apps screen.
Or you can see more Test Procedure Here.
For the first one, I really don't know.
For its design, you have to get real people who test it and give some feedback.
For supporting devices, you could check you Google Play Developer Console. Check the APK section, and see it.
For more devices: Lower your API.
API 9 is for Android Version 2.3.3+ & API 23 is for Android 6.0 only.
So if you use a lower API, more devices can download your application.
Source: Android Developer
did not want to revive an old thread.
OMA DRM v1 & v2 support on Android
we are trying to implement a DRM solution for video content for both streaming and offline. And have searched both high and low, these where are the few which repeats itself every time.
http://www.irdeto.com/documents/HL_CW_OMA_DRM_Android_EN_H.pdf
http://www.discretix.com/Android_Security.html
http://www.haihaisoft.com/customize_android_media_player.aspx
http://www.authentec.com/a/Production/Home.aspx
we are targeting phones & tabs
so android 3.0 can be helpful, went through the sdk docs, still couldn't make out how to use them.
also read somewhere android 2.4 (for phones) will support the DRM framework, in the meantime the market we are targeting may not upgrade to android 2.4 so soon. this requires us to find some custom implementation.
have been hitting the wall on all sides. please give your invaluable insights.
if i have missed something very obvious, correct me as well.
Security through obscurity. It's the only way that DRM can work on a device owned by someone else. Obsfucate your code and require updates to the latest version, which changes every week.
It's like putting a lock on a box, then putting the key in the lock, and hoping that no one finds the lock and key. The solution is to change the location of the lock and key every few days, so that the vast majority of users can't be bothered to find it themselves or even to get the latest "crack".
Old thread -- but you may want to look at Adobe Access as well (http://www.adobe.com/support/documentation/en/adobeaccess/). Supports Android with both streaming and offline possible.
I've programmed my app with Eclipse and android 2.2. However I think that my app would work for previous version and so it would allow more users to use my app. The problem is that I'm not sure... for instance I'm using Gestures which I think is a more recent feature... but otherwise I'm just using some Button, ListView, and WebView.
So is there a way to detect automatically the Minimum Sdk Version needed ( by checking which function my app is using) ?
I can't download the SDK of each previous version of android and test it until it doesn't work ...
Thanks
I can't download the SDK of each previous version of android and test it until it doesn't work ..
Why cant you? This is what the rest of us do. Create various different Emulators and test it out. I've released many apps by testing this way.
Take a look at the Compatibility page on Android's developer website.
It has some great information on how to make sure your application will work on different versions of Android and how to stop users from downloading the application if they do not have the right features on their device. In your case that would be the gestures feature.
To manage this, Android defines
feature IDs. Every capability has a
corresponding feature ID defined by
the Android platform. For instance,
the feature ID for compass is
“android.hardware.sensor.compass”,
while the feature ID for Live
Wallpapers is
“android.software.live_wallpapers”.
Each of these IDs also has a
corresponding Java-language constant
on the PackageManager class that you
can use to query whether feature is
supported at runtime.
To be totally sure you have to test your app against every platform version you target. Otherwise users of your app will do it for you (and that might be not good for app rating).
On the https://developer.android.com/about/dashboards/index.html page you can see the latest up-to-date platforms share info. So just decide how many potential users you're going to leave without your app :)