I'm creating a white-labeled application. I run the project through aapt with the --rename-manifest-package option.
This allows me write
com.foobar
And release
com.foobar.demo and com.foobar.extended versions to be installed on the same device.
However, even though the services are set via both permission android:permission="#string/permission_name" (which changes per install) and android:exported="false" each app wants to call the other apps services!
I.e. when I start com.foobar.extended I get a security exception about it not having permission for com.foobar.demo's service!
It appears that -rename-manifest-package doesn't change the service intent filters, so they remain com.foobar.services.X meaning that one apps services have higher priority for processing the intents.
How can I prevent this issue? (Maybe a startLocalService() which doesn't send the intents outside the application...)
Thanks,
John
You haven't provided a copy of your manifest file, but I would guess that you have used absolute names there, whereas you should have been using relative names.
Instead of
<service android:name="com.foobar.demo.service" />
you should use
<service android:name=".service" />
(Notice that the name starts with a period).
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.
Does the Android Manifest check for the available components to be used before an application starts running, or does the system check for the Android Manifest every time a new component is being instantiated? By components I mean activities, services, etc...
What is the process involved?
Also, can an application still go back and forth to check on the android manifest even after it is running to check on xml activity attributes such as the android:name, android:label, or even intent filters, for different purposes such as to see whether a component to be used has already been defined?
Well to say it in a simple way-
Manifest contains permission like- "SD card read/write permission". So, while installing an app if you don't have a SD card than your won't get installed.
Again manifest contains "minimum SDK version"- which checks what OS version you have in your mobile, if your mobile OS version is less than the minimum version defined in manifest than the app won't install in your mobile.
In the manifest you have a list of all the activities and services too. So, without adding these in the manifest- your activities/services wont work.
So, these sort of checking and permissions are in manifest - the information the system must have before it can run any of the app's code.
Hope i have been able to keep it short and simple :-D
The manifest is a part of the app - it gets packaged with the app in its installation APK.
The manifest tells the system what APIs the application will use. When the app is installed, the system tells the user what sets of potentially sensitive APIs the application will use (as listed int he manifest) and if the user allows the app to be installed the system then assumes that the use of those APIs is permitted.
The OS will not permit the app to use other sensitive APIs that the app did not declare in the manifest.
Android Manifest file contains important information like the Java package name of the application, permissions, descriptions about activities,services... The system must have these information before running the app code.By this reason, the system doesn´t check the Android Manifest in runtime.
More here:
Android Manifest - Android Developer
In Android it is possible to create a Service to do background tasks, etc by creating a subclass of Service. It order to use the Service it must be specified in the manifest for the app:
All services must be represented by elements in the manifest file. Any that are not declared there will not be seen by the system and will never be run.
One of the parameters for a Service in the manifest is the 'enabled' option:
Whether or not the service can be instantiated by the system — "true" if it can be, and "false" if not.
What is the purpose in declaring a Service to be disabled - if I didn't want the Service surely I just wouldn't write it / add it to the manifest in the first place?
The only use I can see for disabling a Service in the manifest, and it seems of limited value, is if it's a Service used only for debugging, and I want it disabled for production. Am I missing something?
The android:enabled attribute set to a boolean value defined in a resource file. The purpose of this attribute is to enable or disable the service on devices running on different Android OS version.
For example, to disable the service on devices running Android 4.3 or lower include menifest attribute android:enabled="#bool/atLeastKitKat".
In addition to including this attribute in the manifest, you need to do the following:
In your bool.xml resources file under res/values/, add this line:
<bool name="atLeastKitKat">false</bool>
In your bool.xml resources file under res/values-v19/, add this line:
<bool name="atLeastKitKat">true</bool>
if I didn't want the Service surely I just wouldn't write it / add it to the manifest in the first place?
In the very specific case of a Service, I agree that it would be rare for you to want to disable it. One possibility would be for a service that plugs into the system (e.g., input method editor, accessibility service) that you only want to enable at runtime (via PackageManager and setComponentEnabledSetting()) if the user make an in-app purchase that unlocks the feature. I am sure that there are other Service scenarios for this, though none are leaping to mind at this early hour of the day (yawn!).
However, I suspect that Service "inherits" its android:enabled setting by virtue of being one of the Android component types, along with activities, providers, and receivers. Other scenarios for android:enabled will be a bit more common with other component types. For example, it is considered good form to have your BOOT_COMPLETED receiver be disabled until you know that you need it. So, for example, if the BOOT_COMPLETED receiver is only used to resume a download interrupted by a reboot, you only need that receiver enabled if you are doing a download. At all other times, you may as well leave it disabled, so you don't waste the user's time during "normal" reboots.
I've implemented a WearableListenerService in both my main app and the companion Wear app. In the manifests, the service needs to be declared as android:exported="true" (or not declared at all and left to default to true) since it's started by Google Play Services. An exported service with no permissions can be called by any app on the system, but I can't find the correct permission to add to the service declaration to secure it. I've looked through the permissions on both the phone and the Wear device with pm list permissions but I don't see anything that looks like what I need.
Is there a permission that I can/should add to secure my services?
If not, is it a good idea to manually secure the service by checking the package name of the caller?
The best way to see how to implement a WearableListenerService on Android Wear is to look at one of the existing samples provided by the SDK. If you look at the DataLayer sample included at $SDK/samples/android-20/wearable/DataLayer it has a full implementation of what you are wanting to do.
If you look in the AndroidManifest.xml for the wearable side, you can see it has the following:
<meta-data
android:name="com.google.android.gms.version"
android:value="#integer/google_play_services_version" />
<service
android:name=".DataLayerListenerService" >
<intent-filter>
<action android:name="com.google.android.gms.wearable.BIND_LISTENER" />
</intent-filter>
</service>
For your security concerns ... When we declare a service in manifest and add a filter to it, it automatically becomes an exported service. So in general, other apps can bind to that service. In case of WearableListenerService, there is a security check that happens in the framework to make sure that the agent binding to that is Google Play Services so no one else can really bind to that service, unless the app developer exposes other intent filters in which case the intention is for others to access it.
So if you implement your code in the same way as the Wear SDK samples, your app should be secure and you do not need to worry about any extra permissions, etc.
Is there a permission that I can/should add to secure my services?
If not, is it a good idea to manually secure the service by checking the package name of the caller?
You don't need to worry about securing your WearableListenerService implementation with permissions or caller package checks. As #Wayne pointed in his answer: there is a security check that happens in the framework. This check is done in the WearableListenerService base class. You can find further security analysis of the Wearable SDK in the following article:
https://labs.mwrinfosecurity.com/blog/android-wear-security-analysis. Here is the quote from it:
The method pr() first checks if com.google.android.gms is Google
signed and then calls cU() to check if the calling process UID is for
the package com.google.android.gms (the Google Play Service package).
If the class is further decompiled, it can be seen that this security
check happens in each method exposed in WearableListenerService.
Unfortunately currently Lint checker produces false positive warning for the wearable listener service declaration whenever it doesn't contain BIND_LISTENER filter (which inclusion produces other warning since it's now deprecated and should be avoided):
Exported services should define a permission that an entity must have in order to launch the service or bind to it. Without this, any application can use this service.
This is certainly a bug in the security detector code (it just wasn't updated when BIND_LISTENER intent became deprecated). I've opened an issue regarding this on the Android bug tracker. Meanwhile to get rid of the warning one needs to add tools:ignore="ExportedService" to its wearable listener service declaration.
In my Application I am not having any UI part, so I need to start a Service as soon as the Applicaton gets installed on the Device. I saw many links from which the answer was that its not possible but I guess it is surely possible. Just have a look at PlanB Application on the Android Market that does fulfil my requirement. Below is my Manifest file how I tried, but the Service was not called at all. So, let me know what is the best possible way to start a Service when the Application gets Installed.
UPDATE
I also tried using android.intent.action.PACKAGE_ADDED it works fine for detecting the Package for the other Applications but not for itself.
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.auto.start"
android:versionCode="1"
android:versionName="1.0" >
<uses-sdk android:minSdkVersion="8" />
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>
<application
android:icon="#drawable/ic_launcher" >
<service android:name=".MyService">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</service>
<receiver android:name=".BootUpReceiver">
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED"/>
<category android:name="android.intent.category.DEFAULT"/>
<action android:name="android.intent.action.PACKAGE_INSTALL" />
<action android:name="android.intent.action.PACKAGE_ADDED" />
<data android:scheme="package"/>
</intent-filter>
</receiver>
</application>
</manifest>
Fortunately, Plan B does not work on Android 3.1+, as tested on a XOOM and a Galaxy Nexus.
What Plan B does is exploit a security hole that could be used by drive-by malware, which is specifically why Android prevents it from happening anymore.
UPDATE
To clarify: As inazaruk posted and I put into comments on other answers, all applications, upon installation, are placed in a "stopped" state. This is the same state that the application winds up in after the user force-stops the app from the Settings application. While in this "stopped" state, the application will not run for any reason, except by a manual launch of an activity. Notably, no BroadcastReceviers will be invoked, regardless of the event for which they have registered, until the user runs the app manually.
This block covers the Plan B scenario of remote-install-and-run, which they were taking advantage of previously. After all, with that, anyone with a hacked Google account would be at risk of having their device infected, hands-free as it were.
So, when the OP says:
I need to start a Service as soon as the Applicaton gets installed on the Device
the OP will be unsuccessful and will need to redesign the application to avoid this purported "need".
Applications installed on the /system partition are not subject to being placed into the "stopped" state after installation. If you have root, you can do,
$ adb root
$ adb remount
$ adb push your.apk /system/app
And it can immediately receive broadcast intents. This certainly doesn't provide a general purpose solution, but i wanted to mention it for completeness.
EDIT: Keep in mind that different versions of Android locate system APKs in different places. For example, Android 8 puts them under /system/app//.apk. Shell into your device and poke around and follow the same scheme used for other system APKs.
I agree with CommonsWare's answer to question: How to start android service on installation. In other words, you can't automatically start your service after you've just been installed.
One more thing about newer Android platforms: if you don't have UI at all, you'll have trouble starting your service even when using BOOT_COMPLETE intent on Android 3.1+.
That's because all installed applications are in stopped state. In this state applications will not receive ANY broadcast notifications.
In order to activate your application some other application (or user) needs to start your service or activity, or content provider. The usual workflow is when user clicks on your application's icon.
I've written a detailed explanations about this in my blog post.
Plan B does this launch by listening to the events which happen in the system. It uses a receiver which literally listenes to hundreds of events hoping that some of them will eventually fire up. So this is how you can do it. Otherwise, there are no built-in means to launch the application as soon as it gets installed.
I'm not sure what your constraints/purpose is, but if you can install another application that has an activity you can have it send an intent with the flag FLAG_INCLUDE_STOPPED_PACKAGES.
This will use your application for the intent resolution, even though it's in a stopped state. If the action of the intent matches one of your filters, it will also bring the package out of the stopped state.
I don't think so You can start service immediately after installed your application on device,
The application must first be invoked by the user through some sort of Activity.The only things you have to register some Broadcast Receiver with appropriate intents in manifest which invoke you service when something is happening on device but this remaing to Android 3.1 version.
EDIT:
After Android 3.1+ onwards you can not use any Broadcast for starting your application, because all application remains in inactive state after completion of device boot and to launch the application the user have to invoke it.(By touching the app icon).
As stated by CommonsWare in the answer to this question (which I suppose you have all ready seen, but chose to ignore) starting a Service on install is not possible - it is simply not a thing that is implemented into the platform.
Starting it automaticly at the next boot is however possible.
As stated in the Technical Details for PlanB:
Plan B will attempt to launch as soon as it downloads, but in some cases you will need to send an SMS to get it started.
My guess is that on a rooted phone you might be able to start the Service on install - but there's no guarantee that the phone is rooted, which is why PlanB will require recieving a text in some cases because that can be registered by the IntentFilter of the app and then used to start the Service.
there is an app on google play Android Lost which invoke the registration service for google push messages via an incoming sms without launching the app even once for version 3.0+.
Perhaps the best way to accomplish this (and now I'm speaking to the specific intent of the OP, a program that gets installed in order to retrieve a stolen phone, not the general question) is social engineering, not software engineering.
So, an icon with text like "Password List" or "My Bank Accounts" which suddenly appeared on the home screen would undoubtedly be clicked on. Look at the success of all sorts of other phishing, and here you would be targeting a thief, who's already motivated to continue nefarious activity. Let the thief start it for you. :)
HEY I think using a BroadcastRecivier to automatically start the app on restart of device hence it will automatically start on device start.Hope this will help