I'm trying to profile an APK using Android Studio profiler in 3.0. Since I am not on Android 7.0 I have to explicitly turn on advanced profiling in the module config.
The issue is that once this is done, Android Studio is still saying "Advanced profiling is unavailable for the selected process".
The reason I explicitly have to turn this on, is because on API level < 26 Android Studio has to inject some logic into the compiled apk.
To show you advanced profiling data, Android Studio must inject
monitoring logic into your compiled app.
https://developer.android.com/studio/preview/features/android-profiler.html
Feedback I got from searching around is that I'm supposed to recompile / rebuild the APK after setting these Run / Debug settings. However I have not been able to find any clear official documentation on this.
But let's assume that it's the case, how would I do this since I don't have access to the source code (obviously).
You might be inclined to say that source code would be required to do this, but I'd like to hear why Android 8.0 is able to do this straight out of the box.
Standard profiling is working without any issue as well.
Would it be possible to inject the logic needed manually?
Related
I'm looking for a way to perform profiling (memory, cpu..) on my tested app (right now only Android profiling is needed).
Currently, I can only do this manually, by opening Android Studio and using its built-in profiling tools whenever I perform a test.
I was wondering if there was any way to integrate these tools into the Appium automation script, in order to scale-out the profiling to many devices and many test variations, and to save precious time.
Alternatively, if anyone knows of a similar tool that can be integrated into Appium I'd love to know about it.
For memory profiling, you can always pull down the "perflib" package in the Android Studio source. That is a more-or-less standalone package (with a couple of dependencies from within the sdktools parent package, which are standalone). The code in com.android.tools.perflib.heap is what you want, and that has all the methods to open an Android HPROF and process it.
As for other resources (CPU and whatnot), look at the viewers associated with them in Android Studio source (com.android.tools.idea.monitor), and look at the interactions with ClientData or adb commands used to fetch that data.
I don't have experience in android development and I'd like to start writing an application.
The official developer tools page contains link to two different IDEs. The first contains a bundled ADT version of Eclipse.
Android Studio, the second IDE, is based on IntelliJ.
Apart from these differences I can't get if there is anything that I can do with only one of them (I guess the answer to this question is no) and what's the point of having two distinct official IDEs.
What are the differences between the two?
The first contains a bundled ADT version of Eclipse.
This is simply a packaging convenience. You are welcome to obtain Eclipse separately and add Android tooling to it.
Android Studio, the second IDE, is based on IntelliJ.
At the present time, this is an early-access preview. IMHO, it is not suited for someone who does not have experience in Android application development.
Apart from these differences I can't get if there is anything that I can do with only one of them
At the present time, Android Studio is an early-access preview, meaning that there are lots of things that it does not have integrated in. Now, by this time next year, and hopefully far sooner, Android Studio will have equivalent or superior integration than does Eclipse with the ADT plugin.
and what's the point of having two distinct official IDEs.
There are an infinite number of "official" tools. You are welcome to use a plain text editor and tools outside of any IDE, for example.
You are welcome to watch the Google I|O 2013 video on developer tools, where they describe a bit of the rationale behind the development of Android Studio.
Android Studio vs Eclipse – Main Differences:
Build Tools
Android Studio utilizes the fast growing Gradle build system. It
builds on top of the concepts of Apache Ant and Apache Maven but it
also introduces a Groovy DSL (Domain-Specific Language) that allows
for scripted builds which opens up many automation possibilities like
uploading your beta .apk to TestFlight for testing. Eclipse on the
other hand uses Apache Ant as its main build system which a very
robust XML based build system that many Java developers may already be
familiar with.
Advanced Code Completion/Refactoring
Both IDEs feature the standard Java code auto completion but in the
case of Android Studio, Google has baked in deeper support for
specific Android code and refactoring. Android Studio can refactor
your code in places where it’s just not possible using Eclipse and
ADT. In addition, in my opinion IntelliJ’s Java auto completion seems
more “intelligent” and predicts better what I want to do so there is
definitely an improvement in this area over Eclipse.
User Interface Design
One of the main selling point Google used to market Android Studio
when it came out was its completely redesigned user interface design
tool. After working with it for some time, it’s clear that the new
tool is much better than the old. It literally crashes it. The new
interface design too in Android Studio is faster, responds to changes
more rapidly and has more customization options that with Eclipse, you
had to manually set in the XML.
Project Organization
Both IDEs work differently in an effort to help you manage and
organize your projects. If you’ve used Eclipse then you must be
familiar with the concept of workspaces. When Eclipse starts, you
select the workspace that contains your projects and you can load all
project of that workspace in your tree navigation. If you want to
switch to a project in a different workspace, then you have to restart
the whole IDE. Android Studio treats this situation differently by
introducing the concept of modules. Your app could be one module, a
library that you just downloaded can be another and the Ad SDK you are
currently integrating could be a third. Each of these modules can have
their own Gradle build files and declare their own dependencies. To
me, Android Studio seems more natural but it takes some time to get
used to if you have been using Eclipse for a long time.
IDE Performance/Stability
Eclipse is a purely Java based software, and a big one. In order to
run it reliably you need to have more than decent amount of RAM and
good CPU power to back it up. Many user who do not strictly meet these
criteria are reporting very bad experiences with it. It is not unusual
for Eclipse to crash while exporting an apk or having to restart it
after using it for a few hours straight. Having said that, Android
Studio is still in beta so it comes with its own bugs that crash the
IDE every now and then but in the meanwhile, the whole experience
feels faster and more robust.
Conclusion
Having used both Android Studio and Eclipse for a while now, I would
personally say that Android Studio has the edge over the two. It might
be a bit unstable yet and some updates require a complete
re-installation of the software but when it eventually comes out of
beta, it will blow Eclipse with ADT out of the water. I especially
like the stability of the editor and not having to reboot every now
and then, the new and improved UI designer and the sexy themes that
make Android Studio a real eye candy. What side will you take in the
Android Studio vs Eclipse battle?
Besides the numerous points already made, while you can use the ADT tool for other projects outside Android, the Android Studio is purely dedicated to the development of Android apps.Android Studio also allows you to work faster as it gives you intelligent suggestions as you type, freeing you from the shackles of having to go back to your .java or .xml files to look up names of variable or other stuff you can't remember.I just started using Android Studio myself and i can say i am never leaving it.It is particularly good for new programmers.
I have been working with standard android for some time. Recently I have been building android sdk for windows and find some interesting things in Android build env. There is a command called lunch which can be used to list all available targets to build. However, it does not list sdk and its variants,even though they are valid options.
Does anyone know why is that the case?
Also can I build any specific module in Android sdk without building the whole sdk. (It could be a great help as I dont wanna build the whole sdk, if I gonna do a small change in one component.)
Thanks
Under the hood, lunch uses make, so if some pieces of SDK do not change, they won't be rebuilt.
My speculation about your first question: rebuilding SDK was never considered a major task of lunch. It is most often used to port or mod the system and produce an installable system image, and receive the ADK as by-product. Later, people realized that often (with root access to the device) you can iterate over one component without need to reinstall the whole system image.
As you may know there are three ways to deploy a Qt application on Android :
Use Ministro service to install Qt
Deploy local Qt libraries to temporary directory
Bundle Qt libraries in APK
The first method takes about 30 seconds and it also needs to install an extra apk . Ministro.
The second takes about 1 minute for me ! And anytime I try to run the program Qt creator pushes Qt libraries to the device.
The third one makes the .apk file really big and again takes about 1 minute for me.
I think with this situation that's not reasonable to develop Android application using Qt. Is there a way to make the deploying process faster?
Almost a full year since the OP and things have not changed at all. Deployment of a 7 MB APK takes over minute and a half for a project that compiles in 5 seconds. The reason I am answering is not that the problem got resolved, but to offer an alternative solution.
I've implemented a "workaround" consisting of two applications that work in tandem - one on the PC and one on the device - I created this mostly to compile files remotely, but it turned out to be a much faster alternative for deployment as well. On the host create an application that launches compilation in a separate process, when done copy the product file over network to the device to deploy. Besides remote compilation this reduced the time to deploy to like 10 seconds, I can live with that.
(Not a complete and fully tested answer yet, but I'll update if I find out more …)
Option 1: Copy the changed libraries to a rooted device
A new build will most often result only in one changed file: your libAppName.so, the native library containing your application's code. At least in 2015, it was possible to simply copy over this library to the Android device, without having to re-build the APK package. This only works with rooted Android devices (note that all emulators are rooted by default).
Step by step, according to this blog article and updated with the paths as I found them on my device:
Run the cross-compilation step on your build host system. So just make or the equivalent in Qt Creator.
Copy the resulting libAppName.so to the rooted Android device:
adb push build/path/libAppName.so /data/app/com.example.appname/lib/arm
Restart the application on the Android device.
If that works, you might even be able to integrate it as a custom deployment step in Qt Creator.
I did not test this technique yet due to lack of a rooted device. But it should still work given that (1) rooted Android devices still allow to overwrite all files and (2) debug builds of APKs can still be installed without code signing, so overwriting a library in an APK without code signing should be possible.
Option 2: Desktop targets as a workaround
I found out by chance that Qt's multi-platform character can be used to avoid the slow Android deployment 80% of the time. You just set up another compilation target; under Qt Creator you'd add a target under "Projects → Build & Run", using a kit for "Device Type: Desktop".
Now when you want to test anything that is not Android-specific, test instead in the Desktop version. Building and starting that will only take a few seconds.
This approach is further supported by using a framework for convergent application development so that the same user interface is usable both in the desktop and mobile versions. KDE Kirigami and MauiKit are two libraries for this purpose that build on Qt. Documentation for getting started is a bit scarce, but for Kirigami I wrote an extensive README for the setup of an example application.
I need to edit the original Android Apps from packages
in terms make my own distro/mod..
I want to make changes to the In Call screen, lock screen, contacts, calendar etc..
I understand that for doing this I will have to build everything from
source,
however I need to edit the source and to do so I need to open the OS provided apps as
eclipse projects,
When I did I saw that there are
missing imports which are hidden in the SDK (or missing)
hidden parameters within the classes..
I don't want to use reflection since the whole code is here and
available, but how do you build a platform development kit..
or PDK ?:)
Can any one help?
You start by reading the documentation.
EDIT:
If you are trying to download some single project from AOSP and compile it using the SDK, odds are very strong that it will not work, and that you will encounter problems like the ones you cite. You do not build Android by building individual apps; you build Android ("my own distro/mod") by building the entire firmware. Most AOSP applications are not designed to be compiled by the SDK, but need the whole firmware.
Please check Using eclipse to browse and edit AOSP. You can atleast edit your code using eclipse, but you will have to use AOSP build system to build your distro.
You might also check Debugging Android Java Framework services as that would help debug your changes.
Just open Eclipse,
then go to "window" +"preferences" +"android"
there you will get sdk location,then give the appropriate path of the android sdk for proper run...