Access caller name without READ_CONTACTS permission - android - android

I have thought about creating a temporary permission or access in some way to the incoming call create screen methods and use their values, but i have no idea how do so.
It is very important for me to not use this permission. Any ideas?

Sorry, but the security model of Android requires you to request the permission. There is no way to work around this unless you're running a custom rom on the device.

Related

Grant permissions via voice input

Since Android 6 permissions can be requested on runtime. The user has the chance to grant or revoke permissions. He is always asked by the UI in form of a dialog popping up.
Is it somehow possible to grant permissions via voice input? I searched by myself but didn't find any approach for that. Is there any information to find about this topic? At least maybe some research how to make that possible maybe in future Android versions?
It would be great to find any kind of useful information about. that topic
I do not think so. It would not be safe, the user could accuse the application after capturing his audio without permission, for example.
You must EXPLICITLY allow anything (even acess the microphone to capture anything) that involves application access. So it's complicated for you to define something as explicit when using voice. The user may claim that he was only in a normal conversation when the application was granted permissions, and this can cause problems ...

I cannot grant the following permission on my app..Kindly suggest any alternative?

<uses-permission android:name="android.permission.CALL_PRIVILEGED"/>
I cannot grant this permission in the android manifest file as it shows the following
error:
Permissions with the protection level signature or signatureOrSystem are only granted to system apps. If an app is a regular non-system app, it will never be able to use these permissions.
So,what should i do now?
Permissions with the protection level signature or signatureOrSystem
are only granted to system apps. If an app is a regular non-system
app, it will never be able to use these permissions.
So,what should i do now?
If your app is expected to run on non-rooted devices, then you're simply doomed - you can do nothing, unless you have platform keys to sign your app with it.
Alternatively, you may narrow your audience to rooted devices only but that would allow you to do what you want incl. using features usually reserved for the platform or system apps ony.
Finally you may rethink your approach. Perhaps what you want to do can be achieved other way, w/o need of elevating app privileges.
For this "CALL_PRIVILEGED" permission , you will need a rooted device and the app must be installed as a system app only.
From the documentation (https://developer.android.com/reference/android/Manifest.permission.html#CALL_PRIVILEGED):
String CALL_PRIVILEGED
Allows an application to call any phone number, including emergency numbers,
without going through the Dialer user interface for the user to confirm the
call being placed.
Not for use by third-party applications.
So, the short answer is that you can't use it. What are you trying to accomplish?

How to know when WRITE_EXTERNAL_STORAGE is required

I am upgrading my Android app's Target SDK Version to 23 (Android M) which has the new Runtime permissions (https://developer.android.com/training/permissions/requesting.html). My app has declared WRITE_EXTERNAL_STORAGE in its manifest, which must now me requested at runtime. Of course, I'd like to only request it when necessary.
I have an abstraction for different storage types, one implements local storage through normal File I/O (not the Android Content Provider stuff). In this class, I get a file path (like /mnt/sdcard/... or /data/data/...) and before accessing that file (read and write mode), I want to check if I have to call RequestPermissions for WRITE_EXTERNAL_STORAGE.
So the question is: What's the safest and simplest way to determine whether a file can be read and written without that permission (e.g. because it's inside getExternalFilesDir()) or not?
You can see here that you only have to ask for WRITE_EXTERNAL_STORAGE when your application needs to write to external storage.
But:
Starting in API level 19, this permission is not required to
read/write files in your application-specific directories returned by
getExternalFilesDir(String) and getExternalCacheDir().
First of all I recommend you to avoid requesting permissions using Intents, because it's a best practice and improves a lot the user experience.
If you can't use an Intent to avoid writing with your app, and you know that some day the user will have to write externally, I think the better would be to ask for the permissions the first time the user takes the "write in external storage" path.
As far as I know, in API23 you only have to ask for permissions once, so I think the easyest way would be to ask for the permissions at the first time that the user needs the functionality, I think that then when he'll execute it again, permissions would remain accepted. You can check your granted permissions with the procedure shown here.
Here you can read:
The user is prompted to give permission once, either at run time or at
install time (depending on the user's Android version). After that,
your app can perform the operation without requiring additional
interaction from the user. However, if the user doesn't grant the
permission (or revokes it later on), your app becomes unable to
perform the operation at all.

Android 6.0 Permissions - Where to place permission requests?

with Androids new permission system, I was wondering how to implement it right. The tutorials about how and when to use the permissions seem to be pretty clear. However, I don't know who requests the permissions and where to request them.
So, basically my question is: should the Activity, who starts another Activity request the permission beforehand or should the Activity which requires the permission place the request?
If the Activity which requires the permission should request for it, should I call requestForPermission inside onCreate or in onStart?
Though it seems to be very simple questions, I haven't found any hints in the documentation.
Thanks.
should the Activity, who starts another Activity request the permission beforehand or should the Activity which requires the permission place the request?
That is up to you. The main guidance is that there should be a clear tie from something the user does to your request for permissions:
If your app needs certain permissions to do anything meaningful, ask for them when your app starts up, perhaps after any sort of "welcome" presentation to advise them about why you need the permissions.
If your app needs certain permissions to do something based on the user performing some in-app action, like tapping on an action bar item or ListView row, ask for the permission when the user performs that action.
Asking for permissions at semi-random points in the app will simply lead to user confusion ("what did I do? why is it asking me this? and why are these questions appearing in an Stack Overflow answer?!?").
If your app can't function properly without a particular permission might be good to have a welcome permission flow where you explain why need the permissions and ask for the grants. For example : Google maps and location permission
If some specific parts of the app need a separate permission you can call the permission check just before doing a method call that needs permission. In this case you can create a wrapper for your function that needs contact permission and always call that wrapper instead of the actual method. For example : Google maps and microphone permission when you try to use the search with voice functionality
More details http://inthecheesefactory.com/blog/things-you-need-to-know-about-android-m-permission-developer-edition/en
also check out https://github.com/permissions-dispatcher/PermissionsDispatcher could reduce a lot of permission code.
When ever your X task struck due to some "Y" permission then only ask for permission. There is no point of asking in onCreate or onStart method.
if you ask for "Y" permission at the start of Activity then there is no difference between Android M and below model. Exploit the beauty of Android M. for example if your require storage permission for creating a temp it's better make a temp file in App internal area i.e /data/data/your package name/files/ rather than asking for storage permission to users. Overall my point is exploit these options as much as you before it become necessary condition to ask for "Y" permission.
Regarding Activity concern , your task must be running be over some fragment or activity let that activity handle the onRequestPermission results.

Security Exception: Permission denial for DEVICE_POWER

I am trying to write a simple android app that switches off my phone screen. When I am runnning this app I get Security Exception: Permission denial app requires android.permission.DEVICE_POWER. I know that this is a protected permission but my phone is rooted. What do I specify that I can use this permission? I have already tried declaring DEVICE_ADMIN permssion along with the DEVICE_POWER permission but it still doesn't work.
Rooting potentially lets you circumvent or modify the android security model, but it doesn't necessarily mean you get special privileges for an android API which enforces it. You cannot ordinarily run an application itself as root, while code in a helper executable which you could start as root will have substantial difficulty interacting with the Android APIs.
What you are trying to do may really not be a very good idea. But if you really want to do it, you would need to either install your own build of Android so that you have a (self generated) key matching that which you used to sign the platform, which you can then use to sign your application, or else try to install your application on the system partition.
If all you want to do is turn the screen off, then why don't you use the PowerManager? According to the documentation, the goToSleep() function will force the device to go to sleep.

Categories

Resources