So when you create mobile apps, you usually intend to distribute your app to multiple platforms and architectures. However, since object code usually is dependent on factors like the architecture, you would have to compile the app for all the different mobile phones out there. So is you application really compiled for all the different phones that the app will be made available for? Is this specifically targeted compilation then done whenever a user runs the app on his/her device? Like on the device itself or is the compilation done before the app is actually installed on the phone?
So is you application really compiled for all the different phones
that the app will be made available for?
Short answer: yes.
Is this specifically targeted compilation then done whenever a user
runs the app on his/her device?
No; this is done when the package is created (else you'd be sending all your source code in the app!) This means a package may contain multiple libraries required for it to run on multiple architectures.
Like on the device itself or is the compilation done before the app is actually installed on the phone?
For the shared object to be put into the package, compilation is done before the package is created. The required shared objects are copied onto the phone during installation of the package (and I suspect that the non-required ones are discarded, but it's possible they're not!).
There are however only a relatively small number of architectures that android supports; and while supporting them all does increase the size of the package, the size is rarely an issue.
Alternative:
If you don't want to put the shared object in the package, an alternative is to host them and download the appropriate one during runtime.
The problem with this is that this does impact user experience (I personally hate when I download an app, and then it states that it wants to download more; it feels like it's a mechanism of bypassing any security checks google want to do)
Related
Short:
Is it possible to write a mobile application where you can download some kind of extensions/add-ons (like in desktop programs) that are not previously shipped in the app archive?
Long:
I am developing a mobile app with a shared base functionality but different modules for different clients. As the app is growing rapidly and the modules are quite different, it would make sense, not to pack every module into the apk from the beginning but to ship only the base code to all clients and they can select and download the modules they would like to use. Regarding apk size and speed this would offer definately advantages. Splitting the app into several smaller apps with different package names on the other hand would be very hard to maintain. Currently I'm using Ionic but the question would be equally interesting for native apps.
Searching the web returned nothing of value, so I'm wondering whether there is a way to acchieve this...
Well, i'm not sure if you can have a class loader as you have in Java for doing such things. But the res folder probably will not work.
Another approach is to launch every plugin as a different application, and design those activities to work with startForResult so you can communicate and open all other apps while looking like you are within the same application.
In the current state of the project I'm currently working on, I have a classic Android Studio project with a classic app on it.
For some good reasons (it's an embedded app), I would like to include an auto-update feature in the app, which doesn't require to exit it (I must stay inside the app or another app and never show the underlying Android system).
I have two solutions to do this :
Create another "updater" app which updates the app using the package manager command. It requires a rooted device to work, but it would suit my needs : when an update is available, the main app closes itself and opens the updater app which updates the main app and starts it back
Have the actual code of the application stored to the external storage and turn the APK into a bootstraper which downloads and runs the app
The later solution is the better one since it doesn't require a rooted device.
This is why I would like to write an elegant system to achieve this ; the development of the app should not be crippled by this (e.g. I don't have to upload the new classes at each build, I don't need to do extra voodoo work to add activities or permissions to the manifest...).
I thought of using the build variants of Android Studio :
Debug variant : build the app like usual, don't use the bootstraper
Release variant : don't include all the classes in the APK, build an external JAR which contains them and use the boostraper in launcher intent
I saw how to load external classes from the external storage, but I couldn't find anything on how to externalize the whole app code, including activities. I have the feeling that we just can't.
Would such a system be possible to develop ?
I code Adobe AIR games with Flash Builder IDE. When exporting release version, the Android one offers two options: one with embedded active runtime and other with shared AIR.
Which is the best option should we choose? In case we select shared AIR, is any risk for our games? I mean, is this true that all Android device always have AIR now? (For us a smaller APK is always better, right? :D)
Normally which option do you choose?
It is not true that all Android devices have AIR installed. Likely it's far from it (though unfortunately I have no empirical data to give you - other than Adobe's blog which in Spring of 2014 claimed 50 million+ installs)
So while you will hit a very sizable % of potential users (using shared AIR runtime), there is no guarantee that the end user will have the correct (or any) version of AIR installed on their Android device.
So if you want to target the broadest audience possible (at the expense of filesize), you would want to export with the run time embedded.
Of course, some users will be put off by your app if it's too big (especially the gamer crowd) so you have to balance that with having to inconvenience some users with downloading AIR first.
Only you can decide what is best and you should consider the following:
Who is my target audience? (gamers are more likely to have AIR already installed), casual users are way less likely to bother with AIR or know anything about it or updating it
How big is my app without the runtime? If you're app is 200mb by itself, then adding the runtime doesn't really make much difference. But if your app is only 2mb, then you're getting a 4-5x bloat.
You do want embedded since this is a guaranty that your game will work correctly. If you choose shared then your app won't install on system with an older AIR runtime version and user might no know how to update it so they won't be able to try your app. Embed and you avoid all these potential problems.
(Sorry for my english)
I'm new using Android (in fact, I'm just testing android) and I have a lot of questions...
Well, let me explain you the situation. In this moment, in my job, I am writing my code with C# and run it on Windows Mobile 6, the apps are used to make sales, send bills, reserves, etc. The devices (iPAQ 216) are given to the salesmen, and they must use the apps and update them via internet.
Each salesman have a unique client list, unique data and (in some cases) an unique set of apps, which means that I need to prepare a different package for each salesman. Using a Microsoft tool (cabwiz) I can prepare automaticaly a different package for each one of the 150 salesmen. They download their specific package using a tool wirtten by me, and install it and everyone is very happy (maybe)...
Is that possible in Android? How? and if it is not possible, do you know an idea how to accomplish somewhat like that...?
It's not going to be as easy as cabwiz, I can tell you that. But it would be possible, theoretically, to write a script that modifies/generates the unique portions of the source and then compiles a new copy for each user.
If the only difference between the apps is the data on them, then there is no need to generate a different package for each user: have the app download the data from your server and save it after the app is installed. You could also make some modules (I can only guess what kind of functionality you're talking about with regards to different apps per user) only accessible to particular users.
Yes, it's possible however:
You may want to look into writing in java rather than C# as that's more officially supported on android
There are some limitations of the android APIs, in particular there are basic behaviors of the device that can't be altered - without rooting there's no equivalent to the "hook" functionality of windows.
Make sure you get devices with the menu option to enable installation of applications from 'unknown sources'; otherwise deployment will be a lot more difficult. At that moment, this amounts to avoiding AT&T, as their devices presently confine you to the android market or physical connection to a machine running the developer tools as distribution channels. (As a work around you can upload your apps to the market and not publish them, though that won't fully keep them private unless you also include something to require authorization when they run. You could also install the minimal set of dev tools on the salesmens' laptops)
You will probably want to learn about the command-line application build tools and scripting in order to generate a custom apk for each salesman. Once the devices are set to allow unknown sources, you should be able to email the salesman the apk (or a link to it) as an attachment. You should also be able to make the custom apk refuse to run except on a device matching some fingerprint data you've previously collected. While you can develop for android under windows, you may want to look into switching to linux in order to make some of this scripting a little more natively elegant.
I am writing an Android application that uses some functionality that has been published under the Apache 2.0 license. The functionality is available in 2 ways:
As java code
As an intent in an Android application.
Being the typical developer that I am, I don't want to make the user install a separate application so that they can use my own application - because it would definitely put me off using the application if I had to.
On the other hand, doing the work to get the application up and running using the Java code will take much longer.
My questions are thus:
What are most developers doing now? Are they using intents from other apps?
Does it matter to the average consumer that they need to download a separate application to make it work?
In my application EmailAlbum, I first depended on the presence of OpenIntents OIFileManager on the user phone to pick a file on SDCard or chose a destination folder for exporting a generated file.
Later, I integrated my own version of the code of OIFileManager in my app's source code for several reasons:
Depending on another app for basic (but essential) application features is like a suicide. If your app can't really live without the other app and this app is not installed on most devices, your app won't get used. Most people want apps that work on first start.
Another app was on the market which was providing it's own (bad) implementation of the same intent and was making my app crash... users having it installed on their phone thought that was my app's fault.
Providing a consistent UI was not possible.
I think using public Intents is great to allow people to chose from various applications to extend your applications features or to reuse the content generated by your application. BUT your application has to be able to live on its own, depending only on standard apps provided with ALL android devices (ie. not even depending on Google proprietary apps if you want your app to be able to be used on devices which have not been approved by Google, those which come without the Android Market or GMail).
Most developers are going to use a common intent (phone call, web browser, camera, etc.) to call an activity. If your app replaces one of these common intents, then you shouldn't have anything to worry about.
Developers do sometimes include intents to use other (non-common apps). One example that comes to my mind is OpenWatch that provides an API for other developers to build on. Of course, in this case, if you are using a bluetooth watch like this, then you most likely already have OpenWatch installed, therefore it isn't much of a bother to get another app that builds on top of it.
If you think people are going to use it, I'd say provide an API.
Might also want to take a look at here: http://www.openintents.org/en/
I think even google had an app at one time that depended on a third party package. At application startup the user was greeted with a dialogue that asked him to download said package. If he declined, the respective functionality was disabled.
But I'd only use that approach for tech savvy users, the regular joe will much likely be put off by it. If the functionality isn't crucial, just use it as an added bonus and leave it out otherwise.