defer · HackerTrans

5 maanden geledendiscuss

No, the SMS is initiated by the device upon calling emergency, not requested by the emergency service. The standard is called AML.

The format is not secret either, it's just binary encoded.

defer

2 jaar geledendiscuss

They are huge because android has hundreds of smallish makefiles but the generated ninja file is a single flat file.

The advantage in android is that the different build systems will generate ninja, so they can interoperate.

defer

2 jaar geledendiscuss

This is hilarious to me:

  Android, which uses it for some large component of the system that I've never quite understood

Ninja is really a huge part of AOSP, the build system initially used makefiles. Things got complex really fast with a custom declarative build system (soong) and a failed/aborted migration to bazel. Google developed kati (https://github.com/google/kati) which converts Makefiles to ninja build files (or should I say file), which really is huge:

  λ wc -l out/build-qssi.ninja    
    3035442 out/build-qssi.ninja

Going from makefiles/soong to ninja is painful, it takes several minutes even in a modern machine but it simply flies once ninja picks it up.

defer

2 jaar geledendiscuss

JVM does garbage collection, this can stop all threads at safepoints while GC occurs.

Those stops can be enough to ruin your low latency requirements in the high percentiles. A common strategy is to divide workloads between jvms so that you meet the requirement.

defer

3 jaar geledendiscuss

You can generate binder wrappers from aidl, that would work. This is fairly common when doing platform work (for those like me who work on the operating system rather than on apps).

However, this would be a terrible idea because usually the android api is stable at the Java wrappers (I.e. ActivityManager), not at the aidl level, which would make this very fragile for app development across a multitude of devices and platform versions.

defer

3 jaar geledendiscuss

I also want to know this, but in reverse.

I build older android (the OS) versions inside docker containers because they have dependencies on older glibc versions.

This is a memory-heavy multi-threaded process and the OOM killer will kill build threads, making my build fail. However, there is plenty of available (but not free) memory in the docker host, but apparently not available in the container. If I drop caches on the host periodically, the build generally succeeds.

comments