My question may look strange but I'll try to explain somehow. Let's imagine there is an Android device with software that adjusts some settings based on application package name - it's a real-life scenario. This software may provide better performance for listed applications and there is no way to add my application to that list. What I'm capable of doing is to release my application under one of listed package names (not to Google Play, just provide APK on GitHub so that anyone who wants to use it will install it manually). And there comes my question:
is it legal to use some company's existing package name for my own application? Is it protected legally? My app is free & open source application.
Just to be clear: I'm not doing this to impersonate "real" application with bad intentions. I just want my application to use full range of device capabilities... And download page will state it clearly & visibly :)
In other words: can I release app with package name e.g. com.google.android.talk? I know that it won't override existing app if someone has it installed etc. (it's not my goal to override some application). I'm just talking about such possibility and legality.
This is totally legal, as you can use whatever String you want for your app/package name.
However, just doing this will most probably be not enough to "impersonate" the other app, as this would be a serious security flaw. First of all, there can never be two apps with the same package name installed.
If the app you speak about is created by a "serious" developer, say Google or one of the OEMs, it will check both package and signature of the app and will therefore know your app is not the same as the replaced app.
Also, when the user tries to install your app, a package conflict will happen, followed by the signature conflict. There are two scenarios here:
If the app you are replacing is a standard app, the user will be able to install your app from adb, but only after thay accept to completely wipe the data of the original app. You have probably seen this dialog while developing stuff.
If the app is provided by the OEM and has system permissions, the installation will simply fail, with no possibility to "overwrite" the app. This can be dodged by having the devices rooted, replacing the .apk file in the system directory and restarting the phone.
Please mind that none of the above will work by just uploading the .apk to the phone. This needs to be done from adb. On-phone installer will just fail.
Related
I want to access the apk file of any app before installation.
In more details: in google play store when the user clicks on Install button I want my application to access the apk file of the application that the user wants to download, and analyze this apk file and be able to whether allow the installation or stop it.
is that possible and if so how to approach this
On Android this functionality was introduced in Android 4.2. It is usually used by anti-malware products like Google Play Protect is known as a "Package Verifier". There is a good blog post on it here.
The short answer is this has to be done as part of the phone manufacturing process as it is so critical to security. So the answer is it can be done, but if you write this code you will need to get a phone manufacturer to include your code as part of a phone system image.
Most third party anti-malware products instead rely on analyzing the APK after the install happens by listening to the package added notification.
Definitely not possible in the way that you want. Android's OS is pretty well locked down. You might be able to do something if the device was rooted but at that point you may as well write your own OS fork. You can attempt to do someting with https://developer.android.com/reference/android/content/Intent.html#ACTION_PACKAGE_ADDED broadcast but you will not be able to analyze the apk freely nor will you be able to stop the installation of it.
The device my Android app is running does not have Playstore on it. The plan is to pre-install the software when shipping the device. I am now looking for a strategy to upgrade the application.
I found this useful link to install an Android app from the apk file:
Android: install .apk programmatically
I am thinking I will use this logic to auto-upgrade my app. I am wondering if it is even possible. I am thinking the upgrade will first try to uninstall existing version but will fail as the executable is still running and the file may be locked. Is there a better way? Regards.
Peter, we've just implemented the same thing.
Users have the software pre-installed on their device and we host update APK's on the companies servers.
From the app they can then check for updates where we have a WCF service which extracts the APK file (essentially a .zip) and returns the manifest details. From there we have the version of the APK and can compare it against the local version.
If the user decides to upgrade they can download the APK and you can automatically launch it. At which point the user will be told the application is going to be updated. There are no file locks etc, the app will just close and restart using the new version.
Note: Downgrading is not "automatic". The user would have to first uninstall the app. For upgrades, however, it's a simple case of downloading and launching the APK version (the user will be told they need to allow installations from unknown sources if this is not checked).
You have a couple of options, depending upon your target system.
Use the link you posted. This will provide the user with a traditional install dialog, whereby the user can choose to install or not. You should avoid doing that automatically, as APKs can be large and you might irritate the user if they don't want updates.
You can install updates magically, but you will require the firmware signing key (or possibly root, but I haven't tested that). That will not ask for consent from the user. You will need to add additional code using reflection to access the installation methods of Android. If you go this way, you should build an opt-out/in mechanism.
If your app is open-source, F-Droid would solve the problem for you.
F-Droid is an installable catalogue of FOSS (Free and Open Source
Software) applications for the Android platform. The client makes it
easy to browse, install, and keep track of updates on your device.
Mainly, it updates your app when necessary. (Or just have a look at its source code for inspiration on how to do it).
Yes but as far as I remember only if you had Root privileges in order to have access to the INSTALL_PACKAGES permission.
I'm building an MDM application for Android devices and I want to be able to silently update the MDM app in order to patch security holes, add new features, etc. I know it is possible to achieve this by accessing the Android Package Manager Installer but from what I can tell this requires the application to be signed with the same signature from a specific OEM.
Is it possible to do a silent update for an MDM application without rooting the device?
You cannot, and this is viewed as a Good Thing from the point of view of the user, because the code that I install cannot be changed by anybody except software signed by a trusted key (such as Google's Play), or with manual approval.
I can think of two workarounds:
Check if there's an update, download it, then refuse to do anything until the user updates the app.
Dynamically load most of your app's functionality at runtime from a JAR that your app downloads. You could silently update this at will.
Heck, you could even combine the two options, so that if the wrapper needs updating, it will bother the user. The second method will make the nags very infrequent.
You should probably let the user know that this is happening, at least in an initial info-screen. I know I would uninstall any app that tried to go behind my back in this manner, if I found out about it.
I am developing 2 android applications, which are clients for my server. I cannot install both applications on my android phone. I install the first app to phone, everything is ok. Then when I try to install the second app on the phone, I get the message that the application will replace another application (the first one), and then I get following error:
Application not installed: an existing package by the same name with a conflicting signature is already installed.
I mention that I have created one separate keystore file for every application, export them as in the android official signing application guide, then zipaligned them.
So the OS thinks that it is a single application? But in fact there are 2 different apps.
What am I doing wrong?
I think you are using the same package, which is not allowed for two different apps.
But for anyone who have the same error for installing another version on top of previously installed app:
I wanted to test released version of my app when the problem occured. I've had the app previously installed using eclipse, and than I wanted to install the same app but with released signature. I have even uninstalled the app using apps gallery, but the problem persisted.
The solution for me was to unistall the app using Settings->Apps->"the app"->top right corner menu->Uninstall for all users
I had the same error message, but these answers did not help. On a 4.3 nexus 7, I was using a user who was NOT the owner. I had uninstalled the older version but I kept getting the same message.
Solution: I had to login as the owner and go to the settings->apps... Scroll down to the end of the list where my old version was listed with a mark 'not installed'. Select it and press the 'settings' button in the top right corner and finally 'uninstall for all users'
Not sure what happens when you use the same signing key, because in all honesty, I never really tried it.
That being said, as Anand Tiwari, in his comment, has already simplified the answer, you cannot install two different applications with the same package name on one device. They, logically speaking, may be different to you, but for the OS, they are in fact, the same.
The problem also manifests itself when you try to upload the applications to the Android Market (Google Play). Google Play will simply not accept the second application. There is a short and simple explanation by Warren Faith here: https://stackoverflow.com/a/5788664/450534
As an example of how similar applications with a few changes are published to the Google Play store:
The free version of FriendCaster is: https://play.google.com/store/apps/details?id=uk.co.senab.blueNotifyFree
The paid version if the same app is: https://play.google.com/store/apps/details?id=uk.co.senab.blueNotify
Notice the ending of the package names. In this case, you will be able to install both the apps simultaneously on one device.
I think your problem is that both your files have the same package name. You can name both apps with similar packages, but they can't be identical. In fact, using the same package base can be used to communicate between applications ie. App1: com.mypkg.app1 and App2: com.mypkg.app2. However, they both can't be called com.mypkg.app - the package name is how Android identifies apps, and can't be identical.
You should be able to sign as many different apps (assuming their package is different) with the same key.
Make sure not to lose your signing certificate, if you lose it, you will not be able to upload a new app with the same package name. If you lose your signing certificate, you will be in big trouble.
Good luck.
I'm experimenting with Android and I want to know if the following is possible: can I modify/patch an installed APP using another APP?
I know it's possible with root access, but I was wondering about non-rooted phones.
The only solution that comes to mind is the following:
-Create copy of original APK from data/app/ folder
-Patch/rebuild it
-Launch installation of the patched APK
The user would need to confirm the installation, but in theory it would work right? Any other tecniques that I haven't thought of?
In case you're wondering, I'm interested in injecting different strings and other resources into existing apps to provide translations or other modifications (ex: cheats in games), without changing the source of original apps.
You are right, you can do this on a device. Smali/Baksmali can be used on Android, also the apktool should be callable (I have only tried smali).
A year ago or so I have tried to use smali on a device and autopatch the source output. There was some information on the net (which I'm currently unable to find, sorry) but it was very limited, at least someone showed how to use smali/baksmali correctly. I have abandoned this approach because I'm not that good at java and the resources on a phone are rather limited.
Another approach I thought of was to offload the actual work to a server somewhere in the net. But this has its very own problem as you need to transfer the files, you may need the framework.apks, and so on.
This is interesting but hard stuff, you need to decode/parse/patch/rebuild apks and this has to be reliable. When you fail, the worst thing is that the users phone is broken (I wanted to modify critical system apks, bad idea ;)).
Better if the reinstall is seamless and for that you need: INSTALL_PACKAGES permission.
Now, INSTALL_PACKAGES android:protectionLevel is "signatureOrSystem" which means the app needs to be signed with the same certificate that was used to sign the system image.
Now to sign one's app with the same certificate as the one used to sign the system image might seem like a difficult if not impossible task since vendors may not be to willing to let other's use their certificate. Then again, some might want your app included in their system image. In any case it doesn't matter per sey since it's Android and Android has a ROM market.
Android ROMS are more and more synonymous with the general 'workings' or 'features' of Android. It is something that Android users come to expect. There are ROM manager apps available on the Android market that will list and install ROMs etc..
So in essense for an app to gain the INSTALL_PACKAGES permission one can make their own ROM, OR, work with the people who make ROMS and either have the app included with the ROM or use the certificate used to sign the ROM's system image to sign the app.
Again it is entirely possible that a vendor include the app in their "firmware" (system image). You would have to approach them.
:)
if both are your app use .content provider to share data between apps.and if other app is from another developer then you simply can't modify the app.