While developing with IBM MobileFirst studio I've found that after building iOS/Android environment and generated native projects, even a blank app (e.g a quite simple Hello World Android app which do not use any native functionality), will take size more than 4Mb which is much larger than a real native exported Android apk file.
So are there any unused resources that can be deleted or other things we can do so that we can lose weight in the final exported apps?
Another detail, the classes.dex file inside the 'blank HelloWorld'apk file seems larger than a common apk file (4Mb size).
Starting MFP 7.0 you can now minify and concatenate mobile environments. This means that in addition to added security, by reducing the amount of files and contents of files, it can help - to some degree - with the filesize of the application.
Read more about application build settings
MFPF 7 supports by default many more hardware architectures. This support is required if you intend on using features such as JSONStore and others. The files adding this support are located at your-app\android\native\libs (arm64-v8a, armabi, armabi-v7a, mips, mips64, x86, x86-64). So if you know you're not using JSONStore for example, see if removing some or all of these files helps you. But also do a regression test in general to make sure that the app continues to work as required. I could be wrong about the scope of these files - which add 3.4MB on disk.
Related
I am a new guy in OC programming. Now I am involved in a framework development project.
I know the framework works as a library, which contains a group of methods. It's not an application that can run on devices.
Actually, our framework will work with customer's application. We want to investigate what happened inside our framework when customer's application crashed. So I want the 'DSYM' file of our framework, instead of an application.
As far as I know any iOS application does have corresponded 'DSYM', but I didn't find the 'DSYM' of our framework.
Does iOS framework project have 'DSYM'? If it does have, how can I obtain it?
By the way, I am using Xcode 8.1.
Thanks!
According to my observations, .dSYM files are generated for iOS dynamic framework built with Release configuration only.
After build succeeds, the debug symbols files can be found at these paths, for a device and simulator, respectively:
<Build_Root>/build/Release-iphoneos/<Product_Name>.framework.dSYM
<Build_Root>/build/Release-iphonesimulator/<Product_Name>.framework.dSYM
, where
<Build_Root> is usually a subdirectory within Derived Data directory;
<Product_Name>is the name of your framework.
Yes, you can generate dSYMs for dynamic frameworks. There are a few relevant build settings that control whether and where these files are generated:
DEBUG_INFORMATION_FORMAT = dwarf-with-dsym,
DWARF_DSYM_FOLDER_PATH = "$(CONFIGURATION_BUILD_DIR)",
DWARF_DSYM_FILE_NAME = "$(PRODUCT_NAME).dSYM"
Obviously, you can set these to whatever you want, either in your project's build settings in Xcode (the project.pbxproj file) or as arguments to xcodebuild (depending on how you generate your framework).
DSYM (Debugging SYMbols) files generally store the debugging symbols for your app. And if app crash any where symbols replaced with appropriate method name so that it could help developer in a readable form. And for that you can use the crash log and they can be find in the iPhone where the app is installed. Each app and device have their own crash log.
Also please check this link it might help you.
Read Crash Report
Upload Symbols for iOS Framework
Hopefully these might help you or guide in the right direction.
I need to distribute a webapp in an offline version on an USB. Electron seems like a great way to make the webapp feel native and work well on all platforms. There is (potentially) just one problem: The offline version requires several huge media files and therefore there is not enough space for each package to have its own folder with the media files. This can be solved by letting the packages share a common directory on the USB. Can you tell me if this is possible with Electron. And if so, how?
(Note that each package must be available on the USB.)
I have created a cocoa application primarily to run on OS 10.6.8. to convert certain types of proprietary legacy files. The app looks at the legacy files creator code and processes it accordingly if it is a known type. Once the file is identified, I call an external legacy app (which I have added to the project) using [NSWorkspace openFile: withApplication: ]to open the droplet and process the file conversion.
The application works just like it is supposed to until I archive it and try to run it from the application bundle. Actually, it will continue to work but it is using the converter app from the project. If I delete the converter in the project area, then the app in the app bundle can not open the external app in that location. One work around is to delete the external app from the bundle after its archived and replace it with a copy of the one in the project area.
I would appreciate any suggestions on resolving this. I'm not sure if the problem is in some Xcode build setting I can change to include an external apps resource fork when archiving, or if this is a launch services issue with apps hidden in packages, or , something I'm not even considering.
Thanks
Mike
Try setting the "Preserves HFS Data" (COPYING_PRESERVES_HFS_DATA) build setting.
I am developing app on Worklight 6.1 version and it contains default common folder which is being created by worklight itself while creating the project. As I am testing size of apk for Android environment , it gives 2.2MB. Size should be very small because till now I haven't added my files in the project.
My question is why the size is big when creating the default app with worklight as you can say Hello Worklight project. Size should be in KB.
So let me know whether worklight is adding any extra library for the project while building environment or something else.
If creating a new Worklight project with the Android environment and generating an .apk for it, the .apk weighs 2.3MB.
If you uncompress the .apk you will note that inside the assets folder, the worklight folder that houses the Worklight framework weighs at 1.2MB. If you then take these 1.2MB and compresses only them (so to see what is the framework size when inside the .apk) it will drop to ~500Kb, so out of the 2.3MB of the .apk, Worklight does not take the majority of the file size...
Now, ways to minimize the file size some more:
You can perhaps go to the res folder and remove image files from screen resolution folders that you know you are not going to support in your application, but that will shave a very very small amount of file size.
You can use Google's Closure compiler with the SIMPLE_OPTIMIZATION option (not ADVANCED_OPTIMIZATION, this will break things and is not supported) to minify the files and thus reduce from the size some more.
The above is true also to the app web resources and not just for the Worklight framework files.
You can also enable Google's Android ProGuard which helps in reducing file size as well.
I just downloaded the full 4.0.1_r1 Android Source Code repository according to the official instructions. Can someone help me understand the repository's basic naming scheme?
For example, in the root directory of the repository, what exactly is the "frameworks" directory? How does this differ from the "packages" directory?
I have spend quite a bit of time around the android source code the last few years, so let me take a shot at explaining the different folders in the root. These are roughly (depending a bit on the android version):
bionic
The standard c library used and developed for Android specifically.
bootable
Contains the bootloader (which the device manufacture normally provides) and the recovery application which is execute when the phone is booted into recovery mode.
build
Android has very unique modular build system, which itself is built on top of ordinary make-files. For example in build/target/products you will find all the generic build targets you see when you launch lunch.
cts
Compatibility Test Suite. When a device manufactures wants to get their device certified (and thus get Google Play and other proprietary apps) they need to pass the CTS. The source of CTS is contained in this directory.
dalvik
The dalvik virtual machine. Android uses java for the better part of the framework as well as for all the apps. Because each app runs as its own process under its own uid, in its own virtual machine, the virtual machine have to have a rather small memory footprint, so Android have chosen to use a custom virtual machine for Java called dalvik. The source of dalvik is placed here.
development
I haven't used this repository really, but it seems supporting stuff for developing android apps are placed here.
device
Each device vendor put all the stuff that defines their specific devices here. For example you can provide a devices/{yourname}/products/{yourdevice}.mk defining exactly which apps should be build for your device (as well as a few other things). This adds an entry to the lunch menu called {yourdevice} that you can build.
docs
As far as I understand this is actually the source of http://source.android.com.
external
Almost all of the third party projects that Android pull in and which makes up the base Android Linux OS are located here. They are maintained in their own git repositories, which makes it easy to pull new versions from upstream. You see things like bzip2, dbus, ping, tcpdump, and many other projects here.
frameworks
This is the source of the Android framework. All the stuff that you use when you build an app for Android. I think it is somewhere around 50% Java code and 50% C++ (and sometimes C), which is bound together using jni. When you for example play some audio in an app, you are probably accessing AudioManager. The source of AudioManager as well as all the internal Android source supporting AudioManager is placed under frameworks/base/media. You will find the bulk of the Android SDK implemented somewhere under frameworks/base/.
hardware
Android talks to a set of libraries which then controls the hardware (such as vibrator, lights, proximity sensor, gps, audio, etc.). These libraries are collectively called the HAL (Hardware Abstraction Layer). Some default implementations are contained in the hardware folder, however manufactures implement their own libraries and place them in hardware/{manufcaturename} (or in device/{manufacture}).
libcore
I don't know about this one.
ndk
The native development kit which allows app developers to code some (or all) of their apps as native code (in c and c++ usually). Basically it is a toolchain to crosscompile to the different cpu architectures Android runs on.
out
All Android build artifacts are placed here. So removing the out folder will clean the sources completely. out is divided into different folders, the main ones are host and target where stuff compiled for the host machine (e.g. adb) and for the target device (most of the android system) are separated. There are further subdivisions below, and in general the out folder is quite nicely sorted, so you should just explore it a bit yourself.
packages
These contains all the default apps, providers, inputmethods, and so on, that are built along with Android. The phone app, contacts, calender, calculator, default soft-keyboard, etc, are placed here. They are not 3rd party apps, they are internal apps where many of them are build against non-public android apis. So most of the apps here cannot build against the public Android SDK (e.g. in eclipse), but have to be build as part of the complete Android build process.
prebuilt
Stuff that is distributed along with Android as binaries. The primary thing located here are the crosscompiler(s) for building Android for ARM (and now also x86). They are prebuilt such that you do not have to actually build the crosscompilers yourself. (This could be very time-consuming if you besides Android also had to compile the crosscompilers.)
sdk
All the tools that are part of the Android SDK, such as ddms, the emulator, sdkmanager, etc.
system
The core system processes running on an android device. These are native (c or c++) programs. Mediaservice is an example of such a system service.
This is all from my experience with working with the Android source, I do not have any (other) references. I hope this helps you get an overview of the folder structure.