Anybody have any idea why
Intent pairIntent = new Intent(android.provider.Settings.ACTION_BLUETOOTH_SETTINGS);
startActivityForResult(pairIntent, 0);
Crashes on all Samsung devices, but works fine on emulator, HTC, Sony, LG etc.
EDITED -----------------------------------
Turns out Samsung also requires BLUETOOTH_ADMIN in the manifest
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
If you have an app in production, you need to have something that will allow you to get crash logs. That could be the default stuff that you get from shipping through the Play Store, or an open source solution like ACRA, or any number of service providers.
With regards to your crash, there is no guarantee that this activity is available. Quoting the documentation:
In some cases, a matching Activity may not exist, so ensure you safeguard against this.
The "safeguard" could be wrapping your startActivity() call in an exception handler, watching for ActivityNotFoundException.
Also, please note that you use startActivity(), not startActivityForResult(), with this Intent action. Again, quoting the documentation:
Output: Nothing.
This means that there is no result, and using startActivityForResult() is a waste of time.
Related
Here is my code:-
public void onClick(View v) {
try {
startActivity(new Intent(
"android.intent.action.SHOW_ALARMS"));
} catch (ActivityNotFoundException ignore) {
Toast.makeText(ac, "ActivityNotFoundException",
Toast.LENGTH_LONG).show();
}
}
This works on the Android emulator running Android 12 API 31: it shows the system clock application with the alarms page. On my Samsung Galaxy S21, also running Android 12 API 31, I get this error:-
Process: uk.co.yahoo.p1rpp.secondsclock, PID: 27629
java.lang.SecurityException: Permission Denial: starting Intent { act=android.intent.action.SHOW_ALARMS cmp=com.sec.android.app.clockpackage/.alarm.activity.AlarmCTSHandleActivity } from ProcessRecord{769a91e 27629:uk.co.yahoo.p1rpp.secondsclock/u0a362} (pid=27629, uid=10362) requires com.android.alarm.permission.SET_ALARM
at android.os.Parcel.createExceptionOrNull(Parcel.java:2437)
at android.os.Parcel.createException(Parcel.java:2421)
at android.os.Parcel.readException(Parcel.java:2404)
at android.os.Parcel.readException(Parcel.java:2346)
at android.app.IActivityTaskManager$Stub$Proxy.startActivity(IActivityTaskManager.java:2878)
at android.app.Instrumentation.execStartActivity(Instrumentation.java:1743)
at android.app.Activity.startActivityForResult(Activity.java:5465)
at android.app.Activity.startActivityForResult(Activity.java:5423)
at android.app.Activity.startActivity(Activity.java:5809)
at android.app.Activity.startActivity(Activity.java:5762)
at uk.co.yahoo.p1rpp.secondsclock.SettingsActivity$25.onClick(SettingsActivity.java:538)
...
Here is the first bit of my AndroidManifest.xml:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="uk.co.yahoo.p1rpp.secondsclock">
<uses-permission android:name="android.permission.SET_ALARM" />
...
I'm actually asking for the permission even though I shouldn't need it since I'm asking to look at the alarms, not to set one. Without the permission request in the manifest, it still works on the emulator and fails in the same way on the phone.
I see the same behaviour (on both the emulator and the phone) with both debug and release builds.
In case someone asks why I'm doing this, I've written a home screen seconds clock widget, which will be published on github when I have it fully working. I want clicking on the widget to go to the system's clock app, which doesn't work because of this problem. The code shown is test code to check why the code in the widget fails, because the widget code executes in the context of the home screen launcher and is harder to debug.
I can go to the system clock app by using an Intent with its ComponentName (and this works without an error on the phone), but different Android phone models have different clock apps with different Componentnames, so it will only work on one type of phone. I did have code to search the PackageManager for the ComponentName of a clock, but Google's latest security upgrade in API 31 doesn't allow me to do that any more.
Why is the SecurityException happening and what if anything can I do to prevent it?
Why is the SecurityException happening
Samsung apparently has an android:permission attribute for that <activity> requiring that callers need to hold that permission to be able to start that activity.
what if anything can I do to prevent it?
You cannot prevent it. Samsung requires that permission, either intentionally or due to some screwup. You either need to hold the permission or you need to wrap the startActivity() call in a try/catch and "gracefully degrade" if you get that exception.
It does not required the permission that you have mentioned above rather it requires a different permission.
Replace this
<uses-permission android:name="android.permission.SET_ALARM" />
With
<uses-permission android:name="com.android.alarm.permission.SET_ALARM" />
I have an app that allows users to login using fingerprint authentication. The feature has been in production for a couple of months, but in the last day I started seeing many of these exceptions:
java.lang.SecurityException: Must have android.permission.USE_FINGERPRINT permission.: Neither user ##### nor current process has android.permission.USE_FINGERPRINT.
The crash occurs when I call fingerprintManager.isHardwareDetected() to check whether or not the device supports fingerprint authentication. I have the USE_FINGERPRINT permission declared in the manifest, so I don't know why the system would think that the process does not have this permission. This should not be something that I have to check at run time since USE_FINGERPRINT is a normal permission.
This has been working fine for months, and when it started crashing yesterday, we had been on a stable release for about a month. This problem sounds almost identical to this FingerprintManager.isHardwareDetected() throwing java.lang.SecurityException?. I am only seeing the crash on Oreo devices.
My current plan is to catch the Security Exception and proceed as if the device did not have the hardware, but my worry is that this might mean that no one is able to use the feature for login if this problem persists. Has anyone else had a recent issue with this exception? Or if not, does anyone have any ideas about why this might have just started happening all of a sudden like this? Thanks for the help!
Use the FingerprintManagerCompat instead, that was handling permissions correctly for me.
See:
https://developer.android.com/reference/android/support/v4/hardware/fingerprint/FingerprintManagerCompat
Additionally you might want to declare the permissions in your Android Manifest:
<!-- Fingerprint -->
<uses-permission-sdk-23 android:name="android.permission.USE_FINGERPRINT" />
Note that I used uses-permission-sdk-23, since I found that FingerprintManager doesn't work reliable in older versions of Android, I know there are some Samsung Galaxy devices with fingerprint reader, but before API 23 you were granting permissions at installation time; that depends more on your market. Try it and see if it makes a difference for your users.
See: https://developer.android.com/guide/topics/manifest/uses-permission-sdk-23-element
I have an APP to end call automaticly using ITelephony.aidl. It works on almost every devices except Samsung J6. When I try to finish the call, the exception will be thrown casued of Modify_phone_state permissin.
If it works, consider yourself lucky. Google has been removing ways of programmatically ending calls for years, almost as quickly as they pop up. Its not functionality they want us to have. If you do have a new way, expect it to be removed.
Samsung's behavior is actually correct. You aren't supposed to be able to end a call unless you have that permission, which is a system privlidged permission not available to apps without being pre-installed or rooting.
I am using Device Policy Manager in my Android App and I have a problem with Honeycomb devices. When attempting to call resetPassword I get an exception thrown. This is not the case in Froyo or Gingerbread, as both of those work fine.
The error is:
java.lang.RuntimeException: Unable to start receiver Package.Name.Test: java.lang.SecurityException: Permission Denial: writing com.android.providers.settings.SettingsProvider uri content://settings/secure from pid=x, uid=y requires android.permission.WRITE_SETTINGS
My Android Code is as follows:
DevicePolicyManager mDPM = (DevicePolicyManager) context.getSystemService(Context.DEVICE_POLICY_SERVICE);
if ((mDPM.getActiveAdmins() != null) && (mDPM.isAdminActive(new ComponentName(context, DeviceAdmin.class)))) {
mDPM.resetPassword(extra, DevicePolicyManager.RESET_PASSWORD_REQUIRE_ENTRY);
mDPM.lockNow();
} else {
Log.d(TAG, "Could not lock because device admin not enabled");
}
The problem occurs at:
mDPM.resetPassword(extra, DevicePolicyManager.RESET_PASSWORD_REQUIRE_ENTRY);
My Device_Admin.xml is:
<device-admin xmlns:android="http://schemas.android.com/apk/res/android">
<uses-policies>
<force-lock />
<wipe-data />
<reset-password />
</uses-policies>
</device-admin>
Like I said the device admin works great on Froyo and Gingerbread devices, although I do have some problems with users using different keyguards, an example is the Droid X and HTC Sense. This problem is with timing. When I call lockNow the device will turn off the screen but HTC Sense or MotoBlur will not actually lock the keyguard until the time that was set in Settings, Security, Lock Phone After.
Any help would be awesome! I just recently got a honeycomb tablet at I/O and haven't tested the app out on this device yet, but I see the errors on the market website with users with the Xoom running 3.0. Have not seen any 3.1 devices yet.
I struggled with this also. The solution is also listed on one of your links, but I'll mention it here also in case it helps someone else.
If the device is brand new (or factory reset) the code fails as you describe.
If the user enters a password using the settings menu just once, somehow the same code starts working and keeps on working.
A very weird bug indeed!!
On Android Honeycomb 3.0 platform, the DevicePolicyServiceManager is very different from Gingerbread, the whole flow of resetPassword() is:
DevicePolicyServiceManager.resetPassword() -->
LockPatternUtils.checkPasswordInHistory() -->
LockPatternUtils.passwordToHash() -->
LockPatternUtils.getSalt() -->
LockPatternUtils.putLong(SALT_KEY, salt) -->
Settings.Secure.putLong(SALT_KEY, salt)
Here you should know why WRITE_SETTINGS is required, it seems that this is Google's mistake, they did not put the LockPatternUtils.checkPasswordInHistory() method in Binder.clearCallingIndentity() block.
One more thing, even if you add WRITE_SETTINGS permission in your AndroidManifest.xml file, it will tell you that WRTITE_SECURE_SETTINGS permission is also required.
Hope Google can fix this issue ASAP.
P.S. It seems that this issue has been fixed on ICS platform, Google has removed the checkPasswordInHistory() from resetPassword() block. I do not think this is a good solutoin and i don't know why? Maybe they wanna release ICS as soon as possible?
I also faced this problem, what i can tell is if you didn't set the password manually even single time, the it will give force close asking for write_settings permission but if you try once by setting password manually from there on-wards it will work like charm.
I was looking at this problem (which is readily reproducible on 3.1 as well, btw), but it appears that you already figured it out, based upon the issue you filed. I just wanted to note that here in case anyone else tried to research the answer.
I have declared the launch mode of my activity to be singleTask. If I
launch my application, press the home button, go to an email client
(gmail in this case) & preview an attachment using my application, I
am experiencing a security exception on Android versions 2.3 & later,
which says that I do not have the permissions to access gmail
attachments. The exception does not occur on prior versions & if I do
not use singleTask as the launchMode.
The exception occurs on this line-
mContext.getContentResolver().openInputStream(intent.getData());
where mContext is the activity context.
Is this a known issue?
Any help will be really appreciated.
Thanks,
Akshay
I had posted this on Android-developers and got this response from Dianne Hackborn-
"Sorry, this is probably a bug in 2.3 with trying to grant a URI permission to an activity instance that is already running. I'll look in to this. In the mean-time, the only solution may be to not use singleTask for the activity being launched to a preview an attachment. This is actually the preferred thing to do, since your preview activity should be running as its own instance as part of the gmail task."
The problem might happen because the called intent's activity in the 2.3 implementation does not fit the launchMode:"standard" or launchMode:"singleTop" requirement stated in the android:launchMode description.
But it would be also useful to take a look at this issue: Behaviour of launchMode=“singleTask” not as described. It is scary, hopefully your problem isn't rooted there, and can be solved within the current versions.