While i am inserting this permission in manifest it shows error " Permission is only granted to system apps"
Actually i used this permission for developing application based on Oauth2 token. But i cant enable this permission. Can any Help me?
MODIFY_PHONE_STATE permission is granted to system apps only.
For your information, there are 2 types of Android apps: system & user
User apps are just all your normal app installations through the Google Play Store, Amazon Appstore or sideloading. These go into the
/data partition of your Android phone, which is the part of the
internal memory made available for user data and apps.
System apps are basically the apps that come pre-installed with your ROM. In a standard Android user environment, the user doesn’t
have write access to the /system partition and thus, installing or
uninstalling system apps directly isn’t possible.
In order to install an app as a system app on your Android device,
your device must either be rooted or have a custom recovery installed (or both).
That being said, that error is actually wrong because you have a valid code and compilation should work. It would be better if it gave a warning instead. In Eclipse you can easily fix it. Just go to:
Window -> Preferences -> Android -> Lint Error Checking.
Find ProtectedPermission from the list and set the severity to something other than error(info for example). This way your project will still compile.
Related
We have a C# Windows Forms client application. This application occasionally needs to check for updates to itself from a trusted internal web site, download them, install them, and restart itself.
To make the application compatible with User Account Control (UAC), we embedded a manifest in the .exe that requests the highest available privileges:
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<requestedExecutionLevel level="highestAvailable" uiAccess="false" />
</requestedPrivileges>
</security>
</trustInfo>
We want standard (non-administrator) users to be able to run the application without being prompted to elevate to administrator. We gave standard users full permissions to the entire application folder. This means the user has the power to mess with the software files, but that is acceptable.
The users have been working with this application on Windows 7, Windows 8, and Windows 8.1 for a while with UAC fully enabled. On these operating systems, when our application is launched, Windows does not prompt the user to elevate to administrator privileges.
We are now testing behavior on Windows 10. On a Windows 10 system, with full UAC enabled, Windows is prompting standard users to elevate to administrator. Nothing else has changed. The .EXE is the same, and the embedded manifest is the same requested execution level highestAvailable.
We have tested this with the client files in C:\Program Files and in C:\Users\Public. Both locations have the same behavior.
Why is the UAC elevation behavior different on Windows 10? Is the behavior on prior versions a bug in UAC? Should it have been prompting to elevate all along?
Note that we must keep UAC enabled. I am aware of how to disable it.
Also note that I have tested changing the manifest to requestedExecutionLevel of asInvoker. This is not prompting for elevation on Windows 10.
-- UPDATE --
We have tracked the elevation prompting to a difference between local users and domain users. This MSDN article says:
Application launch behavior for a standard user with additional privileges (E.G. Backup Operator)...[will] prompt for credentials before running the application
We are seeing local standard users not prompted for elevation, but local domain users are prompted for elevation. The only privileges the domain user has over the limited user is being a member of the Domain Users role.
You miss understand highestAvailable. This means request the full admin token if your account is part of the admin group, but for normal standard users no UAC dialog is shown and the process runs with the standard token.
If your program requires admin rights to function then you need to use requireAdministrator in the manifest. When a standard user starts such a process, the over-the-shoulder UAC dialog is shown, where the user can enter credentials of an admin account.
I want to create a Chrome extension and install it as part of a larger desktop software install. This is on Windows XP/Vista/7 etc. I've used the method described here and it works.
However, the extension is installed in a disabled state. The user has to explicitly enable it from the Chrome menu (the user has 3 chances to do that before the menu badge disappears) or from the extensions page. Enabling the extension brings up a prompt in which Chrome informs the user of the permissions the extension is requesting and asks the user to reject or accept the extension.
I understand that Google wants to ensure that users have a chance to reject external extensions. I also understand that Google prefers installs via its Web Store (for various logistical reasons, that is not a preferred option for this app). In fact, our application specifically asks the user for permission before installing the extension.
My issue is that the member has to affirmatively ask for the extension to be enabled before the permissions dialog comes up. Is there any programmatic/command line way to get Chrome to bring the permissions dialog up? The user still has the choice of rejecting the extension, but I would like to present the user with this choice, rather than relying on him/her to try and enable the extension later.
[ I realize that editing the Chrome Preferences file in the installation script will install the extension without any user intervention, but I don't want to do that.]
It's possible to trigger an install from a webpage. Have your installer open chrome with a small webpage that brings up this dialog to the user.
We have read other posts where it is said that for us to store a file in a google drive, the client must install a web app form the Chrome Store. But the fact is that we do not need a Web App and do not want to have our customers install a "non-app" just to get access to their drives. We have found suggestions to use the Document List API but we do not find it in the API Console as it has been deprecated.
The error we get is:
"googleapi: Error 403: The authenticated user has not installed the app with client id XXXXX"
Please advise.
Thanks
Check this question for the reason behind the installation requirement: Reason for installation through Chrome Web Store.
And stay tuned for announcements very soon!
I'm running into what seems to be a serious usability problem for users trying to use a Google Drive app from more than one account. In order for an app to be able to use Drive APIs on a user's behalf, the user must install the associated Chrome Web Store app while logged in as that user. The problem is that the Chrome Web Store seems to look for an app being installed per browser, whereas the Drive API needs the app to be installed per user.
As far as I can tell, the only way to install the same app for multiple users in the same (Chrome) browser is to install with one user, then log in as the second user, uninstall the app (which the CWS says is already installed), and then reinstall it (so that Drive will mark the app as installed for the second user). This is a very confusing experience, because during this process the app and the CWS are sending the user mixed messages about whether the app is installed.
I'm not sure if there's a canonical app to test for system bugs like this. Is DrEdit live somewhere? But if you want to see the problem behavior in our implementation, install the Graphing Calculator by Desmos.com as one user, launch it and log in using google drive and verify that everything is working. Then log out from the app, and use https://accounts.google.com to log in to google as a different user, and try using the app again. The app will tell you that it isn't installed (that's what Drive's APIs are telling us) and direct you to the CWS, which claims that the app is installed.
We are aware of the issue. And I agree this is a really bad experience for users using the same Browser (and the same Chrome session). One of the issue is that the account you are logged-into chrome can be different than the account you are logged into Google Web (Gmail, Chrome Web Store, Drive etc...) Therefore the Chrome Web Store has to make a choice to either use the apps's install status on the Browser or the Web Google account.
If you write an FAQ for your users maybe you can suggest that the most effective way to install the app for the second user is to simply install it using another browser like Firefox. Especially since Firefox won't be impacted by this issue because the app doesn't get installed on Firefox, only on the Drive account :)
The bug is filed internally, now we can only wait for it to be prioritized and fixed/sorted-out. We are also working on some other way for apps to have an install flow that doesn't involve the Chrome Web Store so that it will be less impacted by all of he Chrome Web Store/Chrome browser intricacies.
I'll make sure to ping our eng team on that issue again.
In order for google drive api calls to work, a user must install the app through the Chrome Web Store. I would like to know how to undo this process for testing. I tried uninstalling our CWS app, but drive api calls are still going through just fine. Is there some additional step beyond uninstalling the app that's necessary?
You can uninstall apps from Drive through the "Wheel" top right menu > Manage Apps... > Options > Remove this app.
If you just want to test the auth flow again (you know the first time you do open-with or create-new you go through the OAuth 2 grant screen) you can go to the following page https://accounts.google.com/IssuedAuthSubTokens .
It lets you revoke OAuth access to apps, if you revoke access to your app the next time you do open-with or create-new you will go through the OAuth 2 grant screen again.
(Very useful since only the first time you exchange the auth code will you get a refresh token)
I would usually do the later for development it's easier than uninstalling + reinstalling an app.