Change android phone's System date on button click from android application - android

I trying some stuffs with android as i am learning android development, now i have a scenario here.
I want to change the android phone's system date through my application( first i would like to know is this doable? )
Layout is as below
Now what i want is when the user clicks the button the date should increase by say 20 days
how can i do this.
i am unable to start...please help

As I already said that's impossible. You need the SET_TIME permission and that permission is granted by system only to applications that are in the Android system image. If You are able to gain that privilege you can easily change with the AlarmManager. SystemClock.setCurrentTimeMillis write the /dev/allarm file
adb shell ls -l /dev/alarm
crw-rw-r-- system radio 10, 46 2013-06-12 10:46 alarm
c stays for Character special file (stored in /dev).
system is the owner of the file
radio is the group
system and radio have read and write permissions (rw-, tree bits, int value 6), the others have only the read permission (r, int value 4). So the file permission is 664. If you can get root user (running su), you can change the permission of this file and wrote in it a new value. A bug report has been filled in order to ask google to allow apps to modify programmatically the mobile date but it has been declied. Here the reference

On Android, the only way for an application do have write access to the time&date is to get the SET_TIME permission, which is only possible for "applications that are in the Android system image or that are signed with the same certificate as the application that declared the permission." (see signatureOrSystem protection level).
The only way for your application to reach this protection level is to run on a rooted device, or build and sign your own android rom.
If this is your case, you can easily use the AlarmManager or simply the Calendar instance.
Good luck!

Normal user applications does not have permission to change the device time. Read the answer by cashbash in the following post for the alternate option.

Unfortunately, blackbelt is right; android lets us do a lot of cool things, but changing system time programmatically is not one of them.
Since I see that you are looking for more credible/official sources, I suggest you check out this open ticket with Google, which suggests this is an open problem--it ought to work, but doesn't, and it doesn't seem Google is going to fix it anytime soon. The gist of it is that the SET_TIME protection level is set higher than it ought to be. (for more information on permissions, see here)
Although this is not quite the same as changing the time programmatically, you can still make the user change the system time for you if for some reason you do need system time to be changed. This thread will explain how to go about implementing that if you want to go that route.
Hope this was helpful information!

Related

Android Espresso Test - Changing System Time Format

In my android App, there is an Activity which shows time string according to the System Time Format (12Hr. / 24Hr.).
I am writing espresso test to test this behavior whether the time displays gets changed as the System time format changes.
In order to achieve this, i want to change my System time format through my Instrumentation test for pure testing purpose. and i've added permission in test project's manifest, like this
<uses-permission android:name="android.permission.WRITE_SETTINGS"/>
and wrote the following code to change system time format
Context context = InstrumentationRegistry.getContext();
Settings.System.putString(context.getContentResolver(),Settings.System.TIME_12_24, "12");
and it is throwing Permission Denial error. (you can use below link to see the stack trace)
Error StackTrace Screenshot
i am not able to understand, since the code which is trying to change the system time format in the test project itself and it has permission to change the system time setting,
I verified Using this command
adb shell dumpsys package com.my.app.package | grep permission
Please tell me, what i am missing here ?
I've already found an explanation to your issue. Here is it:
The user application does not have permission to change the device
time. Please read the answer by cashbash in the following post
for the alternate option.
Copying here for quick reference:
According to this thread, user apps cannot set the time,
regardless of the permissions we give it. Instead, the best approach
is to make the user set the time manually. We will use:
startActivity(new Intent(android.provider.Settings.ACTION_DATE_SETTINGS));
Unfortunately, there is no way to link them directly to the time
setting (which would save them one more click). By making use of
ellapsedRealtime, we can ensure that the user sets the time correctly.
From: Set Android's date/time programmatically
Try also instead of using Espresso, use uiatomator as that instrumentation test framework can perform actions with Dialogs, Marshmallow permissions or lockscreen.
It works perfectly with Espresso.
Check this site: http://qathread.blogspot.com/2015/05/espresso-uiautomator-perfect-tandem.html
Hope it help

Which android API calls need these permission?

I'm trying to figure out which android API calls need these permissions:
android.permission.HARDWARE_TEST
android.permission.DEVICE_POWER
android.permission.DIAGNOSTIC
android.permission.GET_TOP_ACTIVITY_INFO
I read the descriptions on the Android developer website, but I found no way to perform the operations that these permissions allow.
EDIT after HexAndBugs answer: I know these permission are not intended for third-party application, but I'd like to use them in a experimental environment, playing the role of the manufacturer.
These aren't intended to be used in your apps (unless you are a device manufacturer), so you won't find things that need them in the API. Note that they all say Not for use by third-party applications. See, for example, DEVICE_POWER
Although these settings are not for usual app but if you have a rooted device and you need to control, lets say hardware test then you would have to add it to your apps permisson and override the ususal CET testing pannel
But FYI it can brick the phone or device if you tweaksomething wrong so beaware;
i personally have used couple of these permisson for e.g getTop Activity info to monitor that my app is always on foreground

How to manage installed apps (with root permission if necessary )?

Android users can go to the "manage application" (AKA "applications manager") screen, choose an app and make a choice of what to do there using the "App-info" screen.
I wish to make an app that allows the user to make those choices in even an easier way (maybe even batch operations).
How do I access each of the features there? Which permissions would I need and for features that are not available via the API, how could I get them via root access?
The features I'm talking about are:
Force stop.
Uninstall last updates.
Disable.
Uninstall - for this I actually know how to do it, but it needs confirmation of course:
final Uri packageURI=Uri.parse("package:"+packageName);
final Intent uninstallIntent=new Intent(Intent.ACTION_DELETE,packageURI);
Toggle "show notificaions".
Clear data
Clear cache
Clear defaults. I would also like to know how to set as default and get all registered intents and their currently default apps (which will handle them).
View app storage usage in both external & internal storage (and cache)
If you don't know what I mean, here's a screenshot of the app-info page:
I've also found some interesting Android permissions that existed ever since API 1, but I can't find any examples of how to use them. Such permissions are CLEAR_APP_CACHE , DELETE_PACKAGES , and CLEAR_APP_USER_DATA.
What I have found is a Samsung code example (available here) that has a permission of CLEAR_APP_CACHE, but I can't find where they use it, if at all.

How do I determine why my Android app requires certain permissions?

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.

intervening Android Install-time Permission granting mechanism

I'm new in Android. I have an Idea to enrich user's knowledge whilst installing a desired application.
the idea is developing an application that can analyze .apk file of the application to check if it's over-privileged or not. and inform the user if this application which he's trying to install is over-privileged or not.
but since there's already a mechanism from Android which asks user's consent to grant whatever permission the application requests, I'm not sure if my application can somehow intervene this mechanism, postpone it, pause it or it can not.
I'm not sure if my application can somehow intervene this mechanism, postpone it, pause it
None of these are possible, sorry. You are welcome to create your own custom firmware that has this feature, but you cannot create this capability via an SDK application, for obvious security reasons.
I am not far from where you are ~ the entire mechanization you seek is based on an xml file in the "root" of the installation - it is called AndroidManifest.xml = all permission based issues should begin original first efforts on that file:
The AndroidManifest.xml File
Every application must have an AndroidManifest.xml file (with precisely that name) in its root directory. The manifest presents essential information about the application to the Android system, information the system must have before it can run any of the application's code. Among other things, the manifest does the following: .....
the "app-store" web based distribution system is supposed to pick that up and not only make some decisions on what to present to the user but as well differentiate to some extent what to do in the matter but as I just got a Droid-X emulator available in my installation I can tell you for a fact that "versioning" is subject to oversimplification as we cannot rely on users being tech-geeks

Categories

Resources