Is there any way to programmatically verify the software version of a given android environment, and the entity that created that build? Something along the lines of a system level digital signature?
This link suggests that android builds are signed which gives me some hope, but I so far can't find any information as to whether there's some sort of model in place for an app to check the integrity of the system it's running on.
http://www.kandroid.org/online-pdk/guide/release_keys.html#signing
Related
I’m building an android SDK/library.
In the library I want to know whether app is either
running on simulator
physical device
whether it’s in beta testing on google play
or it’s product build
Based on my knowledge, I can only detect simulator vs physical based on some checks on Build class values. And there is no way for library to know about beta testing vs production unless the developer of the app using the library provides that information via a public API
Could someone confirm this limitation OR provide some insights if there is a way to do this ?
Reason is to route API calls and data to a particular endpoint so various data doesn’t end up skewing production data.
I can do that via different API Keys for all for cases, but that’s off the limits right now.
I don't think its possible for a third-party library/SDK such as yours to know how, where, or when any developer is running in a testing/QA/production environment. Any real device could be for development or production.
Even for the primary app developer deploying to the Google Play Store there are limited options for track detection as Is it possible to detect that an android app is either a beta version or production version? shows.
I agree with you that if there are Development/QA/Production restrictions (i.e. your backend services) you'll need to provide a public API of some kind to your library to select the appropriate one as you've excluded different API keys.
Sadly you'll also have to be prepared that developers will release your library in the wrong state into production causing other business related effects (production data going to QA or the opposite).
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 would like some general info on system apps. I am working with a manufacturer who is willing to give me the info required to make my app a system app. However, I do not know exactly what this information should be and how to change with my app to make it a system app with the given information. I believe I need the something in my manifest like this
android:sharedUserId="android.uid.system"
and then I need to sign my app with the manufactures key? I am not sure could someone explain to me exactly what the process would be please?
Also the reason my app needs to be a system app is so the user cannot uninstall it, but my app still needs to update. Is it possible to update my app when it is a system app? I would be updating if from google play like normal.
Thanks for any help I simply could not find very much information on this subject and would appreciate the help.
This link here would give you a bit of information.
A System application is NOT an application which is signed by the OS’s
platform signatures. This is a common mistake believed by many and we
shall come to this later on. A System application is merely an
application which is placed under /system/app folder in an Android
device. An application can only be installed in that folder if we have
access to the OS’s ROM (system.img). The application is placed under
/app folder after the ROM has been extracted. A device which loads the
custom ROM will have the new System application added. The benefit of
a System application is that the application cannot be removed from
the device (cannot be uninstalled by the user). This is only because
/system/app is a read-only folder.
http://ricston.com/blog/explaining-behavior-android-application-system-apps-nonsystem-apps/
As for updating your app through the play store, I am assuming you should be able to do that without any problems, if the app is on the play store, and you use the same signature every time. It need not be the manufacturer's certificate, but it's better to use that certificate to sign your app.
So, the only thing that you need to ensure is that, while building the ROM, the manufacturer puts your apk into the system folder, and it should work.
Use mkkey.sh http://www.kandroid.org/online-pdk/guide/release_keys.html script to create new certificates, including x509 certificates. you wont need these steps as manufacturer is giving you the keys.
In AndroidManifest.xml of your application : under the element add the attribute android:sharedUserId=”android.uid.system”
Export an unsigned version of your Android application using eclipse.
Project >> Android Tools >> Export Unsigned Application Package
Use /out/host//framework/signapk.jar to sign your app using platform.x509.pem and platform.pk8 in /build/target/product/security/ generated earlier
java –jar signapk.jar platform.x509.pem platform.pk8 your_app_unsigned.apk your_app_signed.apk
Answer to some of your other questions are already given by Kumar Bibek. These are the steps I followed when I had to do the same. This was in done in Android ICS. The steps might have changed but still worth a try.
Since Android O (Oreo), you need to sign the system apps with dev keys, unlike in the past versions you can just copy them to a system folder which has varied in the past.
I guess this could be a common problem for new android developer like myself so I thought to ask it even so it is not a big deal.
I would like to have both the current published stable version of an app and the under development version on my device. Yet when I want to install both I get
Re-installation failed due to different application signatures.
You must perform a full uninstall of the application.
I understand it technically yet I was wondering how I could have an easy way around this so I can have both application on my phone. I could change the package name for the time being but I hope there is an even more straight forward way to get it done.
Thanks
UPDATE
Solution as given by "Marc Bernstein" in the following post - thx Algo for posting the link to it
How to change package name of an Android Application
There is a way to change the package name easily in Eclipse. Right click on your project, scroll down to Android Tools, and then click on Rename Application Package.
Just change package name of your published and development version Application. Changing Package name is really very simple and easy, follow that post
https://stackoverflow.com/a/9171773/185022
The "published" version should be signed using a release keystore.
The "development" version should be signed using a debug keystore.
At installation time, Android will complain that the two applications (having the same package name) have different signatures, and won't install the latest one (Re-installation failed due to different application signatures.).
To fix this (normal) behavior, change the package name of your application while developing it (ex: com.example.myapp-dev).
My lecturer gave me a project on patching APK files. I wrote a sample application, using Apk_Manager 5.0 to patch the app. It's ok. But then I tried with an application downloaded from market.android.com, the re-signed application can't run on my Android Virtual Device. What's the problem?
As a security feature Android will not let you install an updated version of an app that was not signed using the same keys. If this were allowed a malicious app with the same package name could gain access to private data stored by the original app. To install an app with the same package name but different signing keys you must first uninstall the original app, which will remove the app's private data.
Since you mentioned that you are attempting to modify other people's apps potentially without their knowledge or consent, please respect the copyrights of others. Many developers may consider this to be a breach of license.