Develop Reference

Using AHardwareBuffer_fromHardwareBuffer() in Android vendor software?

I am implementing an Android ODM system. I would like to create a VirtualDisplay constructed around an ImageReader so that the process providing the virtual display will receive the series of frames coming out of SurfaceFlinger as HardwareBuffer instances.
The intention is to fetch out the Linux dmabuf handle to each received HardwareBuffer by using AHardwareBuffer_fromHardwareBuffer() to get the corresponding native object, then convert it to an EGLImage with eglCreateNativeClientBufferANDROID() and then finally use eglExportDMABUFImageMESA() to obtain the dmabuf filedescriptor.
The critical piece of API -- AHardwareBuffer_fromHardwareBuffer() -- lives in the native library called "libandroid". Google documentation (see https://source.android.com/devices/architecture/images/vndk_design_android_o.pdf) explicitly indicates that vendor programs are prohibited from using API in libandroid.
This seems strange, because libandroid is already exposed in the application NDK. I think this means that backward portability in all future Android releases is therefore already demanded of libandroid.
Is there any existing way that I can make my vendor program link against this API? If not, could AHardwareBuffer_fromHardwareBuffer() be migrated out to the VNDK in a similar way as some of the other native C++ API's related to AHardwareBuffer have been?
Updated:
It's a pre-installed service that needs (in addition to doing these VirtualDisplay and ImageReader mechanics) to do some interaction with a custom HAL (so: not anything that implements one of the standard Google HIDL interfaces) that my customer is implementing.
I think that relegates us to needing to pre-install into the /vendor partition, right? I don't know whether this technically speaking makes me a "VNDK process", but the restriction against linking against libandroid kicks in anytime that I put "vendor: true" into the Blueprint file.
This pre-installed service sits in the AOSP tree because I'd like to sign it with the platform key so that the service can set its android:persistent property in AndroidManifest.xml to avoid it being subject to arbitrary shutdown from ActivityManager.
Other pre-installed applications will go badly if this VirtualDisplay doesn't end get instantiated. I'm uncertain what this means for GSI. Maybe you're likely to say that, with a GSI image installed for testing, none of those other preinstalled apps are present either so there's no problem.

Is this process a regular application (APK that provides Activities, Services, etc.) that just happens to be pre-installed on the device? I'd imagine it is if you're using VirtualDisplay and ImageReader. If so, there should be no problem using libandroid.
The restriction on libandroid is specifically for VNDK processes, i.e. lower level parts of the system. The restriction is there because several things in libandroid depend on the Android Framework, ART runtime, etc. as well as unversioned and non-fixed internal interfaces to them. So the usual versioning of VNDK-available libraries, where literally vndk binaries from old versions of the OS must work on newer versions of the OS, doesn't work for libandroid because of those dependencies on non-stable internal interfaces.
But if you're writing something that sits above the framework and is only using public APIs, then it's not a VNDK process and those restrictions don't apply.
(Note: I work on Android and have been involved in AHardwareBuffer APIs. But I'm not a VNDK expert nor an expert on the rules around vendor processes and vendor-preinstalled applications. So take this as reflecting my own personal understanding, and not an official statement from the Android team: if there's official documentation that contradicts what I've said, it's probably right and I'm wrong.)

What is the perfect use case for using Room.inMemoryDatabaseBuilder()?

So I am creating this application where there are lots of personal information and data which shouldn't be persisted in the device to avoid security issues. When learning about Room, I came across this Room.inMemoryDatabaseBuilder() which as the documentation states:
Creates a RoomDatabase.Builder for an in memory database. Information stored in an in memory database disappears when the process is killed. Once a database is built, you should keep a reference to it and re-use it.
I was wondering whether this would be a perfect usecase for my situation. Since the data will only exist in memory and not stored in the device.
It seems like a good idea. My only concern is that I haven't seen an implementation of this in an actual application yet. The only usecase which I saw this Room.inMemoryDatabaseBuilder() used was for testing (so then you don't have to worry about database clean-up on each and every test run).
Can anyone offer some advice? It would be much appreciated.
Thank you very much.

I posted this same context question in #Florina Muntenescu Blog here
Her answer was:
Hi,
Yes, it can be used for any use case that requires the data to be kept in memory only. Testing is one of them.
So basically, Room.inMemoryDatabaseBuilder() can be used for other use cases where data should only be kept in memory.

Room.inMemoryDatabaseBuilder() has been designed mostly for testing purposes. I would never use it in production because you can't know when the process is killed by the system, so any use which goes above an advanced structured cache or similar is probably not a good idea.
I think you have a lot of options to solve the problem without relying on this API.
You can use one or more of the following options:
Encrypt Room database using SQLCipher and store it in application private folder.
Use the Android Keystore to store private information or passwords to access personal information.
Block some sensitive part of your application if the device is rooted using SafetyNet api
Don't store sensitive data in database at all, but ask for them to the server at runtime only when explicitly requested by the user.

How should I code to resist "one-click piracy"?

The app I am working on is automatically cracked by antiLVL (although I am not using the LVL in my app).
In order of protecting my app from "one-click piracy", I am implementing tampering detection techniques explained at Google IO.
I have tried checking the signature both with getPackageInfo() and reflection (invoke()), but AntiLVL was able to crack the app automatically in both cases.
How can I write code that will not be automatically cracked by the current version of antiLVL (1.4.0)? I mean, apart from using JNI.
PS: I am not talking about preventing piracy in general. I just want the pirate to dig into the code by hand rather than using an automatic cracker.

The problem is, any API that only serves to check the validity of your application can be subverted and replaced with a version that always returns the result you expect. I haven't looked at Anti-LVL in detail, but I would imagine it is doing this, which is why your attempts to verify your code using Dalvik's built-in APIs for this purpose are failing.
In order to make it work, you'll have to do the work yourself, using only APIs that have multiple purposes and cannot be so easily subverted.
One way of doing it is to calculate a checksum of either your .apk file or just the classes.dex file inside it, and verify it against some external resource (online server with list of known correct versions, file downloaded to SD card on first execution, etc, resource in the .apk file that isn't included in classes.dex). This prevents code modification, which I believe is how anti-LVL works. I haven't tried this myself, but suspect it should work.

The Presentation Notes from Evading Pirates and Stopping Vampires
Some basic keypoints
Modify the LVL
Implement LVL Tamper Resistance
Use obfuscation
Add reflection
Please note, the #:r.page.X at the end of the links I've provided will not always bring you to that specific slide page number for whatever reason. If it doesn't, take note and browse manually.

How to go about detecting data usage in the Android environment

I would like to be able to detect all forms of data usage using the Android environment. Is it possible to keep tabs on which applications call on say RTP vs WAP, etc. such that I can know at all times when data is being used by a native program or third-party app?

If you are talking about an Android API to monitor network statistics by application then such an API seems to have been added in Android 2.2 (Froyo).
The main class you'll need is TrafficStats.
You can use getUid{Rx|Tx}Bytes(int uid) for the given process user ID (which you can get from ActivityManager.getRunningAppProcesses()).
The API is very simple and simply gives you the total bytes received/sent, so you'll have to do some more work to keep track of hourly, daily, and monthly stats. Well, that all depends on your needs.
I haven't tried using it myself, so I cannot give you any more detail, nor do I know the supported devices (not all devices will support this as the API points out).

I-Jetty or Jetty

I have a web application to be hosted on android device. I am currently using the emulator available with android sdk. My application will serve both static as well as dynamic data. I am currently using jetty version 6.1.22. I wanted to ask what will be a better option to be used.
1. Jetty webserver with stripped off code.
2. I-Jetty.
My application uses following features-
ResourceHandler to serve static resources.
A Generic servlet to serve synchronous data requests.
An extension to CometServlet to serve asynchronous data requests.
I am looking forward to following criteria for comparison.
Application size. Size of apk which will contain the code.
Memory and CPU usage under a maximum load of 30 requests/sec. These are short bursts which occur very few times in app-life cycle. The average load would be approximately 5 requests/sec.
Ease of maintenance. Including important upgrades of Jetty in application.
Any other side-effects which I probably am missing out at.

I too have been searching for information on embedding the i-Jetty server in an application. Like the original poster, I need to serve both static and dynamic resources. I found the following post to be a helpful start:
http://puregeekjoy.blogspot.com/2011/06/running-embedded-jetty-in-android-app.html
I notice that in searching for answers about embedding a web server in an Android app that many responders, rather than providing a helpful answer, chide the original poster for wanting to do such a thing "in a phone". They then proceed to give all the reasons not to. There are more Android devices out there than just phones. My project involves just such a device. Thanks for all the helpful answers on this and other sites that guided me in my efforts. I hope the link I provided helps other searchers.

There are good reasons for embedding a web server in your app. May not be the best way but you have to do it when Android ties your hands. An example is when you want to decrypt video on the fly at runtime and use the media player to play it. Android media player does not allow me to feed it an in-memory stream as would come from a decryption pipe.
In this case, one solution (help me think of others please!) is to embed a web server that would serve up the stream - because Android does accept a stream from a URL!!
The other solution would be port some native library over and write a JNI interface to it. Too much work and unstable at best.
The point is, there are valid enough reasons out there.

It you need to decrypt video or serve content, you might consider just writing a simple web server yourself that can specifically handle your application's needs without any bloat. Adding an existing web server or web container might be more than you need. It very much depends on your application's needs though.

I have a web application to be hosted
on android device.
Why? It won't be usable, except maybe on a WiFi LAN. It won't be able to run terribly long, because services cannot run forever. Etc.
Whatever technical problem you think you're solving by using a Web server on Android can be better solved by other means.
I wanted to ask what will be a better
option to be used. 1. Jetty webserver
with stripped off code. 2. I-Jetty.
Arguably "neither", not only due to the technical issues, but that Greg Wilkins (creator of Jetty) does not like Android much. Of the two, though, i-jetty is at least regularly tested on Android.
Memory and CPU usage under a maximum
load of 30 requests/sec. These are
short bursts which occur very few
times in app-life cycle. The average
load would be approximately 5
requests/sec.
While running, battery life will suck, because you are going to keep the CPU and WiFi running all of the time to support the Web server, let alone the load.