Develop Reference

Does "/proc/{pid}/reclaim" not used in current Android source code?

Linux kernel has a feature to reclaim process memory by writing 1/2/3 to /proc/{pid}/reclaim as https://lwn.net/Articles/548431/. but when I check current Android source code, it not exist. So I am wondering if such feature has deprected or moved?

Finally I think I found the reason from the commit message:
https://android-review.googlesource.com/c/platform/frameworks/base/+/1730078
Edgar Arriaga Edgar Arriaga, a year ago (August 13th, 2020 4:03am)
Migrate to use process_madvise syscall instead of procfs interface for memory compaction
Currently the system uses procfs and we are migrating to use a syscall called process_madvise
which makes the code upstreamable and will allow for making compaction widely available for multiple
android devices.
It also opens room for future developments that involve a finer grain VMA compressions
than the current procfs allows.

Clarification on What happens after installing MultiDex

After I installed MultiDex I noticed,first ever launch of the app takes extra 4-5 seconds. However after a few researches, I noticed that the app size inside the phone settings(app manager) went from 7 MB to 19 MB and if I clear data, app goes back to 7 MB. But every time that I launch the app for the first time, app size increases to more than double.
Now my question is, what happens that makes the app size increase so much?
So far I have found a few topics on slackoverflow about MultiDex but none talks about what really happen with the code, and what kind of data MultiDex saves/caches.

Multi-Dexing is enabled in your gradle and extended in your Application class.
This is used when you use over 64,000 methods.
https://developer.android.com/studio/build/multidex
I would say probably 90% of the time if you are hitting multi dex needs, you have likely not properly managed your dependencies. I'm NOT saying every time. However, typically the issue is people bring in entire Google dependencies instead of just the ones you need. For example the Google Play Services. If you include this, it will instantly force you into multi-dexing. However, this does come with a performance hit. You now have multiple dex files to load. There is some pre-dexing of course for things that will not change such as 3rd party dependencies to help your speed a bit on building and deploying. However, having multiple lookup tables comes with it's speed consequences. For example, if you included.
com.google.android.gms
has about 44,000 methods alone in it, You should specify which one you want like
com.google.android.gms:play-services-location:16.0.0
for example.
So before you go down the road of using Multi-Dex, ensure you have properly cleaned up your unused dependencies, and that you are properly managing your transitive dependency tree. Also don't forget to use ProGuard or the new D8 minification process as that may also help you, although may require you to run in Debug as well if you have that heavy of dependencies.
If you have done all that and you still need to use Multi-Dex (and I have run into this at larger companies that force tons of bloat libraries on you) then you go for it.
Now as for what is happening, well Dex stands for Dalvik Executable. It is the process of packaging the code into Dalvik bytes for execution. This is limited to 65,536 methods. They say 64k in the documentation, but everywhere I've read shows 65k+. Many of Google's libraries already contain 17k methods which puts you 1/4 of the way there right out the gate.
I believe the issue has something to do with the header allocation of 2 bytes per method signature and the lookup table. they are limited on number of unique IDs they can create. So it requires you to create multiple dex files with multiple lookup tables for the method signatures. So the short answer is, it makes multiple Dalvik Executable files to ensure unique method signatures are properly found and executed on the Dalvic Virtual Machine.
Other important things to note, is that prior to Android API 21, the Virtual Machine only supports 1 dex file. Therefore you need to do multi-dex install on your application onCreate to get the rest brought in properly. However, if you are using proguard, your additional dex files could have been removed so you may need to address a MultDexProguard file as well.
Now, it's important to realize that Android completely redid their Virtual Machine and no longer relies on Dex for their modern OS virtual machines. So then the next question is "should you still use it"?
Well if you are still needing to support pre-Lollipop, then you are better off leaving your multi-dex in place. Otherwise if you are Lollipop and up. Android uses ART (Android Runtime) and does not have this limitation. Honestly the population that has pre-Lollipop is so small that it is not worth supporting in my personal opinion, but it depends on your product and your needs.
Hope that helps shed some light on things here.
Happy Coding

A single .dex file can have 65,536 methods(references) so if the number of references exceeds 65,536, you go with multidex.
Maybe as your app is storing more than one .dex file it is allocating more space for new .dex files.
Breakdown your APK using APK Analyser to see what is causing the app size to increase
use the following link refer
https://developer.android.com/studio/build/apk-analyzer
if you want to decrease the size of the app this article is helpful
https://medium.com/exploring-code/how-you-can-decrease-application-size-by-60-in-only-5-minutes-47eff3e7874e

Converting source blob Android kernel back to Git repository

Hope this is the right place to ask, and not softwareengineering.stackexchange.
A couple of enterprising people released a CM11 build for my ancient (Samsung Galaxy S DUOS, released 2012) Android device some time ago. I successfully rebuilt it against the LineageOS 11 code, and now I am wondering about updating it to something newer. It is probably not the best place to start, since newer Androids can use older kernels, but I am looking at the kernel. Basically the kernel in the sources is a source blob based on 3.0 (presumably what Samsung supplied) in a Git repository with a hundred or so commits on top. Using git log -S and internet search I can see that a lot of the difference against android-3.0 is back-ported patches. So the question is how best to convert the blob into a normal Git repository.
My first idea is to locate the appropriate changes in the kernel.org/Android/CodeAurora git trees and cherry pick or git-am them into an android-3.0 tree until I have reduced the difference to something manageable, then to apply the rest as a final commit, and after that to try rebasing to a later (android-3.3 for a start) kernel version. I am sure though that someone out there will be able to suggest ways to improve on that (maybe Git has some clever tricks that I am not aware of).

Does Android cache the libraries?

I am working on a device driver which android apps use. Whenever I make a small modification to the driver and recompile the modified drivers, it seems like the app is not using the modified driver but still use=ing the previous version. I am sure about this because the modifications made includes print statement which doesn't showup when the app runs.
However, once I delete the driver and rebuild it or restart the system then it seems to work fine.
The problem with doing this is that it is time consuming, because I have to be sure that the app is using the latest driver.
So my question is that whether android cache the libraries? If so are there any simple hacks to prevent it from doing so?
EDIT:
As a matter of fact I can delete my device driver and the app which uses it still runs without reporting a problem about missing driver !!!!!!!!!!!!!!!!!

Yes, android apks do cache the libraries. If you have installed xyz.apk on your board, then there will be folder created called com.xyz, this folder will contain a cache folder which will cache the libraries, so newly modified driver is not picked up by the apk.
To bypass this effect you can
Manually delete the cache folder from the above mentioned location.
Uninstall the apk and re-install it agian
Reboot the board

HTTP caching is both important, as it reduces bandwidth use and improves performance, and complex, as the rules are far from simple. In my experience, most Java and Android applications either don’t do HTTP caching, or they roll their own and up doing it wrong or in way too complicated a fashion. In other words, they create a non-standard, one off, unmaintainable solution. And IMHO, that’s no solution at all.
If you find yourself using HttpClient, you can use HttpClient-Cache, which is an easy drop in for Java. See my previous post about HttpClient-Cache for Android. But if you’re using HttpUrlConnection (aka java.net.URL.openConnection()), there’s no good solution for regular Java or Android. Well, in Android 4.0 and later, you can use HttpResponseCache, but with only a small percentage of Android devices using 4.0 or later, that’s not a terribly good solution. If you use Android 4.0+’s HttpResponseCache as recommended by Google, then all previous Android versions end up with no HTTP response caching – this causes excess load on your servers, slower performance for the app, and unnecessary bandwidth use.
To fix this problem, I grabbed all the code from AOSP that implements Android 4.0′s HttpResponseCache and made it a separate library. This library is easy to use, works on Java 1.5+, all versions of Android, and is licensed under APLv2 (just like everything else in AOSP). Really, there’s no reason not to use it! You can even use in Java server applications, such as those that use Spring.

Developing Android App | Should I set minSdkVersion to 10? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Via developer.android I still see that API 10 (2.3.3) still has a large usage, and it would seem to be good to support it; however, I do see that API 16+ (4.1+) are increasing in usage pretty fast. It looks like it is doing so by reducing usage of API 10.
I have been wanting to see a chart that could have showed be the usage of API 10 over the years and see the RATE at which it is being reduced by. I have looked at Google's Cached version, but that only take me back a week. I have looked at Wayback Machine's version, but they don't contain the pictures anymore!!
I know that API 10 (basically all of Gingerbread) is being used less and less, and I am just trying to figure out how long from now (based on trajectories) when API 10 will be basically a real question if it should be built for or not...right now it kind of is a necessity (33%)...IF you look at it in a static context!!
Is it worth the time and money to implement API 10 if in 6 months (or 1 year) from now that percentage is only 5 - 10%?

According to the docs:
The dashboard for Platform Versions is updated regularly to show the
distribution of active devices running each version of Android, based
on the number of devices that visit the Google Play Store. Generally,
it’s a good practice to support about 90% of the active devices, while
targeting your app to the latest version.
emphasis added
IMO, it doesn't matter if Gingerbread will vanished within 6 months. Until there you could lose a lot of clients to your competitors.

OK, a lot of the ideas of whether to do this are subjective in nature. I have seen suggestions pointed out by Exception-al before...with it being good practice to support 90% of all active devices. I do agree with that on a high level; however, my question was pointed at the (near) future, and trying to predict that from past data via information Google releases in its Dashboards.
In a static context, the 33% would seem very reasonable to implement it as a minSdkVersion. However, with my research, I stated This is subjective, but seems like the drop in usage will be large in the next 6 - 12 months. I just want to know if I am right...or wrong., and I have recieved the following I think your time frame and percentage estimations are reasonable. – FoamyGuy
However, that is still very subjective! I want data to back up my thoughts.
I found this one chart before...now I can only find a YouTube video with it here, but the level of detail is bad. However, I just found Android Platform Usage in Wikipedia! Which has a saved history!!
This is NOT the best format...but it gives me some actual real data to go off of. I guess I will start a discussion there if someone could go through all the info and publish that data on that Wiki, or elsewhere.
NOTE: If anyone else finds something better, then I will accept there answer

http://developer.android.com/guide/topics/manifest/uses-sdk-element.html
from the above link
Selecting a platform version and API Level
When you are developing your application, you will need to choose the platform version against which you will compile the application. In general, you should compile your application against the lowest possible version of the platform that your application can support.
You can determine the lowest possible platform version by compiling the application against successively lower build targets. After you determine the lowest version, you should create an AVD using the corresponding platform version (and API Level) and fully test your application. Make sure to declare a android:minSdkVersion attribute in the application's manifest and set its value to the API Level of the platform version.
Set your min sdk to the lowest api level that will support your app. Set your target api level to the highest api level available.
Examples of setting min to 18
Using Network Device Manager so home networks are aware of your app.
Using low power bluetooth
Examples of setting min to 7
Using the action bar (support v7 library)
Examples of setting min to 4
Using fragments (with support library v4)