I'm trying to find out how to achieve the following:
The people in the chat hinted that it may be a system-app setting, but that was as far as I could get.
Even being a system-app setting I cannot find it anywhere, so what do I need to do in order for my app to be able to do the same thing?
Before anyone comes with comments stating how user-unfriendly this is and not to do it, this is not for a generic app but for a business centered work environment where it is important to ensure the notifications are not turned off, especially when the devices can be passed onto other colleagues between shifts and one of them could've turned something off and the others are not aware of.
As it seems this is only possible with system apps or at least with apps that have special access - which is not available to apps normally installed from the PlayStore or similar.
You can specify which app features your app requires. Such that if they turn off the feature, or don't have the feature, the app won't run. In the manifest file you would declare something like:
<uses-feature android:name="android.hardware.telephony" android:required="true" />
<uses-permission android:name= "android.permission.RECEIVE_WAP_PUSH" />
In your app, you would need to check if the user has granted the permission to RECEIVE_WAP_PUSH and if not, display an error message and force them to exit the app.
Related
I want to code an automotive app which should simply display a map while the user is driving. I am developing with Android Studio 4.0.1 and in Kotlin. In order to create an emulator for testing, I used Android Studio 4.2 Beta 1 to download an automotive system image because in 4.0.1 no automotive system image was available.
I am stuck to make this app "distraction optimized", so unfortunately the app still gets overlayed with a black screen and the text "You can't use this feature while driving".
When I follow the Guidelines ([https://source.android.com/devices/automotive/driver_distraction/guidelines][1]), it seems that I simply have to add the following metadata to the activity-element in the manifest.xml (I only have one activity):
<activity>
...
<meta-data android:name="distractionOptimized" android:value="true"/>
...
</activity>
Of course I also request the following needed permissions (amongst others) to the manifest-tag in the manifest.xml file:
...
<uses-permission android:name="android.car.permission.CAR_UX_RESTRICTIONS_CONFIGURATION" />
<uses-permission android:name="android.car.permission.CAR_DRIVING_STATE"/>
...
as well as to the permissions array which I pass to the requestPermissions(...)-function
val PERMISSIONS_ARRAY = arrayOf(
...
Car.PERMISSION_CAR_UX_RESTRICTIONS_CONFIGURATION,
Car.PERMISSION_CAR_DRIVING_STATE,
...
)
requestPermissions(PERMISSIONS_ARRAY, 0)
In onRequestPermissionsResult(...) I find out that these two permissions are denied. But the user was even not prompted / asked to give that permission at first app start. Also in the settings there is no possibility to give the app these permissions. In a later piece of code getActiveRestrictions() always returns 255, which means that all restrictions are active, right? Another indication that the app is not allowed to handle the Driver Distraction on it's own, and therefore the OS takes care of it by not showing the app at all...
What am I doing wrong? What do I possibly miss? Does anybody have an idea?
It is not sufficient to mark an activity as DO in the manifest, it must also be downloaded/installed from a trusted source (like Play Store) otherwise CarPackageManagerService won't allow the app to be displayed in any restricted driving-state.
Some insight (which is not fully provided by the website documentation) can be gained from reading the following comment in the source code for 'CarPackageManagerService', which performs the checks on apps and activities to see if they are Distraction Optimized (DO), among other things:
https://android.googlesource.com/platform/packages/services/Car/+/master/service/src/com/android/car/pm/CarPackageManagerService.java#740
Effectively, what this means is that your app needs to be either:
A system app,
Whitelisted in a config.xml file, which is a resource file for OEMs to create configurations for their car services, or
Tagged as DO in the app Manifest, and installed by an allowed source. The list of allowed sources is loaded from R.array.allowedAppInstallSources.
An exception to these rules is if your OS is a debug build.
After review, we found that your app does not qualify for use of the requested permissions. In your permissions declaration form, you had indicated that your app is a default handler; however, we were unable to detect that capability in your app’s manifest.
i had developed a app which can help in emergency so am using below permission
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.SEND_SMS" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.CALL_PHONE" />
i am using call_phone to call directly 100 and other emergency numbers
and send_sms to send direct sms to particular contacts.
while publishing they asked me core functionality
i had tick
default sms
default phone .. tick on first version
second version i have tick
deafaut sms
default phone
safety alert- emergency senior
both the time it got rejects saying same message.
please help me how to overcome rejection again and again
It is impossible to tell what you entered wrongfully - while a) not knowing what you've entered there (especially permissions SEND_SMS and CALL_PHONE might be problematic), as well as not having seen the app. an app not being a default handler generally means, that there might be an intent-filter missing in the Manifest.xml, which would enable it to be selected as the default handler for one or several intents. if you don't have one, you need to correct the submission form.
See this article on the Android Developers blog, which explains the permission problem you're facing.
The issue with old people is, that they barely can handle a smartphone - especially in case of emergency. there are phones with huge buttons, which have an additional ICE button in the back, which does just that - and while still remembering the button, this is far more reliable than having to unlock a smartphone. ICE means in case of emergency ...demanding technical understanding in such a situation, that can indeed be life threatening; just consider a stoke - which phone do you think is more likely to provide emergency services on time?
On Android, I'd rather suggest to set up the system default "ICE Information", if there are any medical conditions, which first-responders should be aware of, alike: medications, allergies, etc. This information is accessible without having to unlock the phone; just alike emergency calls.
I googled for an example source code for blocking calls and came across this EXAMPLE, But later I came to know that Google has updated their policy and
android.permission.MODIFY_PHONE_STATE
is an system level permission from android version 2.3, I have very important module placed on blocking a specific call.
How do I get a system level permission?
Please let me know if there is any way I can do this in my application. Its very important for the product and cannot be released without this functionality.
Please Help!
Thanks in advance
At least as of Android 5.0, MODIFY_PHONE_STATE has the following definition:
<permission android:name="android.permission.MODIFY_PHONE_STATE"
android:permissionGroup="android.permission-group.PHONE_CALLS"
android:protectionLevel="signature|system"
android:label="#string/permlab_modifyPhoneState"
android:description="#string/permdesc_modifyPhoneState" />
Your app can only hold this permission and use it to modify the phone state if it is signed by the firmware's signing key (the "your own custom ROM" scenario from Marcin's comment) or if your app is installed on the system partition. The latter can be accomplished by having your app pre-installed on the device (or having a rooted device user move your app to the system partition, as I understand it).
Let's say I have taken over development of an Android app, and my boss asks me why our app requires certain permissions to be displayed to users who buy the app on the Android Market.
Are there any tools or tricks I can use to determine what code triggers each permission, so I can figure out why our app functionally needs those permissions? In particular, I am interested in these permissions:
Phone Calls - Read phone status and identity
System Tools - Retrieve running applications - Allows app to retrieve information about currently and recently running tasks, May allow malicious apps to discover private information about other apps.
The app is a GPS tracking app, and it's not obvious why this permission might be needed.
It would also be helpful to get any tips on why this permission might be needed, even if you can't tell me how to directly analyze the code to find out.
Here is how I would track these down.
Step 1 - Find the manifest permissions declared in your AndroidManifest.xml
Basically everything inside the <uses-permission /> tags e.g.:
<uses-permission android:name="android.permission.READ_PHONE_STATE"/>
Step 2 - Search developer.android.com for classes that use these permissions
Let's take the case of READ_PHONE_STATE, the goal is to find which packages require this permission. A simple search on the dev portal for "READ_PHONE_STATE" starts our search, we are looking for classes here, in the top 5 search results I see the following classes:
TelephonyManager
PhoneStateListener
Click on the classes and get their package names:
android.telephony.TelephonyManager
android.telephony.PhoneStateListener
Step 3 Find classes in your project that import these packages
A simple grep will do, or a Ctrl-H in eclipse, File Search -> Containing text
Step 4 Comment out the import and see what breaks
These are likely candidates for why the permission is required. Confirm the methods in question by looking at the dev portal to validate that the permission is indeed required by that method.
Finally you should be able to tell your boss, READ_PHONE_STATE is required because we call function XYZ which gives us UVW.
Remove a permission and see where the app fails. The answer will be in the logcat output.
That's not an ideal solution though, since you might not know what you need to do in the app to trigger that permission.
I suspect "Read phone status and identity" means that the app is using the device IMEI or similar identifying information to uniquely identify the device to ensure that the app is only being run on a registered device. Or it might just be used as a sort of cookie to track the owner. Look for that code. And remove it, because that's the wrong way to do it. If you need to identify a specific android device, use ANDROID_ID from the Settings.Secure class. http://developer.android.com/reference/android/provider/Settings.Secure.html
As for "Retrieve running applications", I find that one somewhat suspicious. A very common way to implement GPS tracking is to launch a separate service in its own process. This way, if the app should crash, the service will keep going and can be re-attached. In this case, it's possible that the app is using the "Retrieve running applications" to identify and kill the service process. But if so, it's a clumsy way to do it.
With the latest build tools, you can run lint check which will highlight for you all the android SDK method calls which are requiring permissions.
See announcement here http://android-developers.blogspot.com/2015/07/get-your-hands-on-android-studio-13.html and documentation here https://developer.android.com/tools/debugging/annotations.html#permissions .
This is based on android annotations and after some adoption time 3rd party libraries can integrate permission annotations also
The answer for your boss is "because certain API features/calls/methods we use in our app require calee to hold certain permissions. It is for security reasons, and that's the way Android works". As for mentioned permissions - you have to check the code to see if these permissions are really required. Read phone status and identity may indicate your app try to get IMEI or something like this to uniquely identify device. Retrieve running applications - see no reason for GPS tracking app to hold this. But maybe you use 3rd party lib/code that uses this.
My application needs that GPS is active at startup as for it to proceed.
Iam testing the app, so I'm mocking the GPS by adding <uses-permission android:name="android.permission.ACCESS_MOCK_LOCATION" /> to my AndroidManisfest.xml file.
This works ok. But I want to keep things separate. Is it possible to add a permission at runtime when we are testing?
EDIT:
I know from the docs that:
Android has no mechanism for granting permissions dynamically (at run-time) because it complicates the user experience to the detriment of security.
But as a matter of testing the application, is there an alternative?
Thanks
There is no way to add Android permissions at run-time. They must be specified in your manifest.
If you have a separate test application, I believe you only need to put this permission on your test application.
EDIT A test application is really no different to Android than a regular one in terms of permissions. I would just put the permission in your test application's manifest and not worry about it.