When android app is installed, does it keep only the resources required by the device current configuration (resolution, language etc) and remove all other redundant resources?
(What will be the point of keeping high resolution images when it won't use it ever?)
Whatever files you have in your APK will be persistent. it will not get deleted by any chance.
As far as I know, the idea is to make use of a single APK to be compatible with the different types of Android devices available. It is not a good practice to design different apk for different Devices.
But yes, some of your resources will never be used by the device and this is how it works.
if required you can create multiple apks for a single app itself.
And it is well explained here,
http://developer.android.com/guide/google/play/publishing/multiple-apks.html
Well, it is all compiled in one apk file, so no choice. It will keep all the resources.
Related
As stated in my question, I am going to develop an app to be published on Google Play, and that app will properly support phones and tablets.
This means the phone and tablet apps will share pretty much the same features, but will display possibily very different layouts in order to offer the best UX for these respective platforms.
At this point, I wanted to go about as following and was wondering if that was the correct way:
I believe App Bundles will help me achieve that, so let's assume I create a new Android Studio project from scratch.
Then, using File > New > New Module, which opens the module creation dialog, I would generate two Phone * Tablet Module and one Android Library module, a module that will contain all the shared same business logic, common to both aforementionned modules.
Then, using the Manifest, I would add the restriction to target phones and tablets separately.
I believe both app modules will need to have the same package name (application id).
Would that be the correct way ? Am I missing anything ? Is there a better standardized way to do so ?
Thanks for the help !
You only really want the layout to change, right? So just create different layouts for the different devices, you can add the qualifiers on creating a new layout file.
https://developer.android.com/training/multiscreen/screensizes
Check this for further information.
I have an app and that's already been made for large devices i.e 10 inch tablets and kiosk. I made the same design for the mobile phones but that was not looking good ,so I thought to move the mobile device to material design and the rest of the devices (tablets & kiosk) would remain same.
I know how can I make different layouts for the different devices i.e normal , large and x-large but I am worried about the code. So basically followings are my confusions....
What is a best way to Judge which device my app is running on in code so that I have to run some methods on the basis of that because my normal device is following material design and contains some widgets that are not present in the design of tablets and kiosk i.e RecyclerView (for some purpose)?
I have searched a lot for this problem and came to a point that there are 2 ways of supporting multiple devices
1> make two separate apks , 2> Make one apk and check in code to differentiate the devices, but as i said above in point no#1 that i have material design in normal devices and that is completely changed design in terms of widgets and layouts , fragments and even navigation, so what would you suggest is the best way to handle this?
If I make 1 apk and put a check in code , then I must say I have a ton of code , and resources and in either case (if the device is normal and large) some resources and classes will never gonna used and will make apk size larger so what is a best way to make a work around about this problem ?
I have also searched through stackOverflow and only came up with these two links that were close to my question but rest of the links are about different layouts not the code:
Android app for phone and tablet: 1 or 2 apps?
Creating different layout for android phone and tablet
I hope I am quiet clear in my question please answer my these question with some authentic reasons and links.
Multiple apks for a single app is supported in Google Play. However, unless your app is very large (greater than 100MB) they recommend you release one apk for all devices.
So you need to inspect the screen size at run-time. You can do this by category, by device independent pixels, or even in inches. Then, as you said, you would load the appropriate layouts and fragments accordingly.
Even if you were to use different apks, you would likely do it in a similar fashion because you probably want to share SOME code.
In Gradle you would make productFlavors for each apk, along with a variable to define the build like this:
productFlavors {
bigtablet {
buildConfigField "String", "deviceType", "\"bigtable\""
}
smalltablet {
buildConfigField "String", "deviceType", "\"smalltable\""
}
}
Then at runtime you would use the BuildConfig.deviceType to drive the exact same logic as the screen size did in the one apk method. With this method Gradle will strip out all the unused code from each apk.
The last option would be create completely different projects for each apk. Pushing all the shared code into libraries.
You can always put it all in one apk for now and switch to multiple productFlavors if the apk grows too large. Since the logic is similar it wouldn't be too hard to swicth. Hope this helps.
The Support Libraries are designed to minimize the amount of work you need to do to detect differences in the Android version where your app runs. For example, RecyclerView is available in the Support Library. Between this and layout-xxx folders, you can usually build a single APK for all API levels and device form factors.
I have a base android project that gets tweaked and would like to generate different APKs. Typically the changes are help links, icons/images, hiding certain functions etc.
In iOS (Xcode) and in Win store app (VS 2012 exp), it is possible to create multiple targets to control the resources bundled with the target as well us programmatically change behavior using the C flags.
Is it possible to do the same for an android project using eclipse ADT? The main issue I see is that, each APK changes the bundle signature (like com.xxx.yyy) and since every file has that package com.xxx.yyy in the files, it is not possible to use that file in a different project (which has a signature like comm.aaa.bbb).
In eclipse .apk builds with Ant and don't support multiple APKs build. Of course you can write your own script, but it will be difficult.
Fortunately, there is another build system, which is called Gradle and it's supported by android developers.
http://tools.android.com/tech-docs/new-build-system/user-guide
You are interested in a section called "Build Variants"
But not everything is so simple, Eclipse with ADT and Gradle are not compatible but Android Studio yes.
The source of this problem is Java itself, where you can't have things similar to #ifdef and most compiler don't allow completely replacing a class or part of it either.
I actually have a base project from which I build 6 APKs already, and more soon.
Each APK uses its own package name, however the whole code is under a single package, but that doesn't create any issue.
There's however many issues:
- All resources, all classes will be in the target APKs, whether used or not.
- Different behavior means different code or different resources, each of which must be handled differently.
For resources, it's "quite easy", just make replacement resources in the final application projects. However unused resources will be left over.
For classes, that's where it becomes very complicated.
To create slightly different behavior you can use reflection and interfaces, each APK implementing it's own version of the interface using a common name eg myActivityPrj which is retrieved using reflection.
Sometimes it's also easier to test the APK package name from within the code, so in the Application object, I set some boolean as to which APK is actually running. Making sure to use those only from the UI to avoid any performance hit.
To create very different behavior, for example an activity is not used in an APK, well, could use above method and a flag saying available or not, but what a waste of space inside the APK!
Another option is to break-down the central project in smaller pieces, if at all possible!
To actually make APK smaller, I found only one way so far: create a Java project which will copy the central project and then remove and/or replace files within this copy, from a remote source tree (a directory named "replacement-files" which contains a res and src folder).
For resources, that java project will actually parse all strings.xml and remove unused strings from a hard-coded list, can't trust lint output as some resources are used in sub-projects and lint doesn't care.
So far, the APK that includes all features is about 10MB, one variation is about 4MB, whereas it should actually be less than 2MB. Another variation is about 8MB, whereas it should really be 2 or 3MB. The above method is overly complicated and being able to removed unused code and resources is getting more and more complicated.
I've looked at various other solutions, but they're all very complicated with a lot of restrictions, constraints.
After 4 years of development on Android, my only conclusion is that Java is the poorest choice possible for a mobile device: slow, inefficient, resource hungry, and very inflexible. Looking at the NDK, it appears very inconvenient and very limited.
I created an application which has different layout for phones and tablets. Can I add my app in two apk on Google Play one for Phones & one for Tablets? I found supports-screens in the documentation but not sure about that. I have to do this because my app is dealing with images and if I merge images for both (phones & tablets) then size of app is very large.
Yes, you can target apks to specific device configurations. Here's the documentation on it: http://developer.android.com/guide/google/play/publishing/multiple-apks.html
Yes this is possible.
I'd recommend to set the name as:
"..." for phone
"... HD" for tablets
I'd also include a link in both descriptions, referring to eachother (so the phone app refers to the HD version and visa versa).
Also, i'd recommend to read this:
http://developer.android.com/guide/google/play/publishing/multiple-apks.html
Yes, you can have single app with multiple APKs. See Multiple APK support, but unless you really see the difference there like completely different assets which bloats the whole app, then sticking to single binary app helps maintaining it further
I developed pretty large Paid app for Android. It has many sections and plenty of images and videos. Now, I want to create a LITE version which will have only few section available (with some disabled functions and changed UI) and only some images and videos (80% less resources than the Paid version).
My question to you guys is what would be the best way to handle this problem. Obviously, I can just copy the project and remove unnecessary sections,resources, etc. However, it will make the project hard to maintain (for every bug I would have to fix two project independently). I know that in XCode for iPhone you can set targets and specify which resources can be disabled. Is there anything similar in Eclips?
Thanks
I was playing around with this earlier, because I also had a paid/free combination on a couple of apps and the manual process seemed too tedious.
I created a workspace with three projects
1. A library project with all the common code and resources
2. Free version
3. Paid version
All you have to do in the actual installable projects is register the activities. They can live in the common library project, but you just have to register them with fully qualified names in your app projects' manifests (same goes with a custom application class if you use one).
You can use the PackageManager to determine the fully qualified name of the running app and turn functionality on or off.