Ting 이네 Software 이야기

/libcore/luni/src/main/java/java/util/jar/JarVerifier.java

여기 source를 확인해 보면,

+ '.RSA', '.DSA', '.EC' 로 끝나는 file을 찾고, 같은 이름의 '.SF' 파일을 찾는다.(Android의 경우는, 'CERT.RSA' 와 'CERT.SF' 파일)

    : '.RSA', '.DSA', '.EC' : Certification File.

    : '.SF' : Signature File

    : Signature file을 certification file을 통해서 먼저 verification한다.

+ .SF 파일의 각 file entry에 대해서 '-Digest' 값을 읽어 들인다.

<< PackageParser >>

'Signing Verifier'에서 읽어들인 "file entry:<HASH>" 값 mapping table을 이용해서, zip file안에 있는 file들에 대해 hash를 검사한다.

    : System APK에 대해서는 Manifest의 hash만 검사 (trusted app.) 그렇지 않은 경우 모든 file - 'META-INF/' directory제외 - 에 대해서 검사.

일반 적으로...

exit code = 128 + (signal number)

ex.

exit code가 139(128  + 11)라면, 11번 signal이 뭔지 알아야 하고 "kill -l"로 확인할 수 있다.

보통의 경우 11번은 SIGSEGV  이다. 즉, segmentation fault로 죽었다는 말...

* '##' macro operator (improved)

<token> ## <token>

: The ## operator takes two separate tokens and paste them together to form a single token.

즉:

#define test(x) aa ## _x

#define test(x) aa##_x

위의 두가지 모두 결과는 'aa_x' 로 같다.

('##' 사용시 중간에 공백은 token delimiter 의 역할을 하게 된다.)

이미 많이 알려진 topic이지만.. 정리차원에서...

* 표준적인 방법은 'startForeground()' API를 통하는 방법이다.

그렇지만, 'startForeground()' 를 이용할 경우에는 반드시 'Notification()'을 띄워야 한다.

* 만약 Notification없이 죽지 않는 Service를 만들때, 그 service를 platform key로 signing할 수 있다면(즉 platform app인 경우)

<android:persistent='true' />를 이용할 수 있다.

이는 '<application', '<service', '<activity' 에 각각 적용 가능하다.

다만, Persistent App의 경우 항상 memory에 상주한다. (Kill 로 죽이더라도 곧바로 재시작한다.)

/libcore/luni/src/main/java/java/util/jar/JarVerifier.java

Here is steps for verifying package with it's signature at META-INF in Android system.

- Find files ends with '.RSA', '.DSA' or '.EC'(Certification file) and then find '.SF' file(Signature File) that has same basename.

  (In case of Android, 'CERT.RSA' and 'CERT.SF' file)

- Verifying Signature File by using Certification file => Signature File is verified.

- Read '-Digest' values from CERT.SF file. => Valid hash value for files are read.

- Then, when parsing package(Apk), all file entries except for files in 'META-INF' directory, are scanned and compared with corresponding hash value in CERT.SF.

Interesting point is, in Android, verification is processed based on file entries in APK.

That is, removing some entries from APK doesn't make any problem in terms of signature verification. :)

* When 'variable expansion' at Command Section, is processed at GNUMake
---------------------------------------------------------------------

In GNUMake source code, command line section of each Target seems to be expanded at 'new_job()' function.
In detail, 'for-loop part' under '/* Expand the command lines and store the results in LINES.  */' comment.

And then, first command line is fetched at 'job_next_command()' function.
Then, when 'job slot(in case of using mutlple job)' is available, this command line that expansion is done, is executed on newly created child process.

new_job
    - expand command line variables (line-by-line)
    - waiting  until job slot is available.
    - job is executed.. 

Note that all variables in command section, are expanded before processing first command line.
Note that, variables in pre-requisites and dependencies are expanded before expanding command line section.

So, following gnumake code is dangerous.

out/target-file: <...>
    ./generate-target-file.sh $@
    ./postprocess.sh $(shell readlink -e $@)
    
[ Issue ]
"$(shell ...) function" part is expanded before "./generate-target-file.sh" is executed.
So, af the first build, 'out/target-file' doesn't exist, "readlink -e $@" return empty string. And this may lead to unexpected result.

--- should be modified like below
    
out/target-file: <...>
    ./generate-target-file.sh $@
    ./postprocess.sh $$(readlink -e $@)