For the next version of our application, I want to change the sharedUserId since we now use an internal control dashboard app which must write to the other app's settings files.
But since the app is already installed on many phones, will this be a problem? I ran a little test on the emulator, and I'm seeing exceptions in the device logs that *.bak versions of the preference files cannot be written. Not sure how critical that is. Curiously, safing settings still seems to work, even though the shared_prefs folder had been created using another Linux user ID.
Did anyone try this before?
And to answer my own question again:
No, it's not safe. Since updating an app via Android Market will not remove the database and preference files, the new version will not be able to read or write these files (since they were created under a different Linux user ID), and the app will crash after the update. You would have to ask your users to completely uninstall and reinstall the app, which is certainly not recommended.
As a general rule I conclude from this:
Whenever you start out developing a new app, make sure to set a manual android:process and android:sharedUserId attribute! It doesn't hurt in case you don't need it, but it gives you full control over which apps have access to this app's private resources.
No solution as of now, but starring at registered issues might get Google to fix this:
http://code.google.com/p/android/issues/detail?id=1227
http://code.google.com/p/android/issues/detail?id=14074
Related
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.
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 know there are plenty of questions about this on here, but I've tried everything (but the correct 'thing', obviously!) and nothing seems to shine any light on the problem I'm having.
I've written an app (for a customer), which is designed to be hosted on their own server. The app references a simple text file with the latest version code in it and checks it against it's own version. If it's out of date it goes off and downloads the update. Everything is working as intended up to this point.
I use the:
Intent i = new Intent(Intent.ACTION_VIEW);
i.setDataAndType(Uri.fromFile(outputFile), "application/vnd.android.package-archive");
i.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(i);
...code to start the install process of the newly downloaded .apk file. And that all starts as I would expect.
I click on "Install" - when I'm prompted to confirm the overwriting of the current app, with the new. It starts, and then displays:
App not installed. And existing package by the same name with a conflicting signature is already installed.
Now I'm aware that Android can't have multiple applications sharing the same package name, which is fine, but nothing comes up in LogCat and I can only assume that the OS is annoyed at me attempting to 'update' my app, even though I'm going through all the correct channels and using the inbuilt package manager to do it for me!
Can anyone tell me what the OS is moaning about? I'm not attempting to install two apps side by side, I want it to update it, which it starts to do, and then gets really confused.
Is it something to do with me using the same keystore for signing the packages? I highly doubt it as I've used the same keystores previously to handle updates to games and the like, but I just can't figure out what it's complaining about.
Hopefully someone out there has had this issue and solved it, and can point me in the right direction. I'm flying a bit blind with the limited information it's giving me :(
Cheers.
You have built the new and old versions using different signing keys; likely you either built them on different machines, or one is a debug certificate and the other a release one. When this happens, you typically have to manually and explicitly remove the old version before installing a new one with a different certificate - it's basically a safety measure against inadvertently installing a trojanized imposter update.
Note that you can move certificates between build machines (and may have to if you turn the codebase over to the customer), though you will want to be careful when doing so.
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.
I was wondering if it's even possible. Let's say I separated my app into "Library loader" and "Library" where library piece can be downloaded by "Library loader" from my server.
This way I don't need to rely on users to install updates to my app.
I understand it's probably not possible, but stillw wonder what you all know :)
This is internal business app and updates always pain. I do throw notifications to user, etc and there is still problem forcing user to upgrade.
Yes, I believe this is possible. Swype / the Swype Installer work this way. You might investigate it.
From what I remember:
You install the Swype Installer from an APK, then run it.
The installer downloads the Swype APK, and chaperones you through the system dialogs to install and enable Swype.
When Swype decides your beta key has expired, or whatever, it disables itself and then you use the installer to update.
This isn't dynamic linking at all though but it is a system to support forced updates.
Update:
Blog post from Google talks about dynamic class loading here:
http://android-developers.blogspot.com/2011/07/custom-class-loading-in-dalvik.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+blogspot%2FhsDu+%28Android+Developers+Blog%29
Possibly, and if you have root access, certainly, although what I'm thinking of would require the NDK. When you load data with the NDK, it is done dynamically. So if you replace that library, it would obviously update the functionality.
However, I do see many possible issues with this. The largest of which is I'm not sure if you have write access to where your library is stored (once the app is installed anyway). But I'm not sure of this. The folder is /data/data/(package name)/lib. I do know you have some limited access to the parent of that folder though (as that's where your database is stored).