KR102371988B1

KR102371988B1 - Aosp 기반에서 내부 어플리케이션 간 통신의 최적화 방법

Info

Publication number: KR102371988B1
Application number: KR1020150122284A
Authority: KR
Inventors: 문경기
Original assignee: 현대오토에버 주식회사
Priority date: 2015-08-31
Filing date: 2015-08-31
Publication date: 2022-03-11
Also published as: KR20170026846A

Abstract

본 발명은 AOSP(Android Open Source Project) 기반에서 내부 어플리케이션 간 통신의 최적화 방법에 관한 것으로서, 더욱 상세하게는 안드로이드 기반의 OS(Operating System) 상에서 서로 다른 어플리케이션 간의 통신이 필요한 경우에 UDS(Unix Domain Socket)를 기반으로 하는 File Descriptor(이하 FD)를 생성 후, 통신이 필요한 다른 어플리케이션에게 생성된 FD 배열 중에서 특정 FD 정보를 상기 UDS를 통해 전달하고, 상기 FD를 복사하는 dup(Duplication)함수를 활용하여 UDS 기반의 양방향 통신을 가능하게 하는 AOSP 기반에서 내부 어플리케이션 간 통신의 최적화 방법에 관한 것이다.

Description

AOSP 기반에서 내부 어플리케이션 간 통신의 최적화 방법{Optimization of internal communication between applications in the Android Open Source Project based}

일반적으로 안드로이드는 Java 어플리케이션으로 개발하기 때문에 다른 어플리케이션과 통신을 하려면 Java가 인식할 수 있는 형태로 변환이 된 후 데이터 전송, 수신이 되어야 한다. 그러므로 Java 어플리케이션으로 개발이 된다 하더라도 네이티브(Native) 간에 직접 통신하는 방법을 사용하는 구조로 개발하는 데는 한계가 있다.

이는 PDK(Platform Development Kit)을 통해 안드로이드(AOSP)가 포팅이 완료된 이후 개발자가 개발하여 설치하는 네이티브 기반의 일반 어플리케이션은 안드로이드의 권한 문제로 인해 framework class에서 제공하는 네이티브 서비스를 사용하는데 제약이 존재한다.

또한, POSIX(Portable Operating System Interface)에서 제공되는 Shared Memory를 사용하는 방식은 어플리케이션 개발 시 코드의 복잡도가 높아지고 동기화의 관리의 어려움이 있다.

또한, 일반적인 Pipe는 Linux Kernel에서도 제공되는 IPC(Inter-process Communication)이지만, 단방향을 원칙으로 하기 때문에 다른 어플리케이션에서 응답을 받는 트랜잭션이 필요한 경우를 고려하면 효율적이지 않다.

이에 FIFO(First In, First Out)는 양방향을 지원하는 a named pipe이긴 하나 다른 어플리케이션 간 통신 시, 다른 프로세스와 사용할 때 사용되는 메커니즘이 파일 기반으로 통신을 하는 것이 특징으로서, 이러한 파일 기반의 통신 기법이기 때문에 해당 파일이 생성되는 경로가 쓰기를 할 수 있는 권한이 있어야 하고 보안에 취약한 약점이 있다. 그러므로 다양한 모바일 기기에 포팅할 수 있는 어플리케이션을 고려하면 파일로 생성되는 경로를 갖는 FIFO로는 쓰기할 수 있는 권한이 있는지 여부를 파악 관리하기에는 현실적으로 어려움이 있다.

도 1은 종래의 기술에 다른 AIDL을 통한 통신 방식을 보여주는 개념도이고, 도시와 같이 종래의 AIDL을 통한 통신 방식은 AIDL의 중간에 Binder Driver라는 드라이버를 통해 통신을 하게 되는데, 상기 Binder Driver는 Third Party 개발업체가 직접적으로 접근할 수 없음으로 인하여 Proxy Class와 Stub Class를 별도로 정의하여 이 부분을 통해 다른 프로세스와 통신을 할 수 밖에 없는 구조로 되어 있다.

이러한 AIDL을 통한 통신 방식의 문제점으로는 AIDL은 단방향이고, AIDL을 통해 개발하게 되면 Java에서 인식하는 데이터 타입으로 변환하는 작업이 필요하다.

그러므로 AIDL, Messenger, Intent과 같은 Java 기반의 통신 방법은 C/C++에서 사용되는 구조체를 다른 어플리케이션에게 전달하는 과정이 복잡하고 개발이 된다 하더라도 유지보수 및 품질 확보가 어려운 문제점이 있다.

상술한 문제점을 개선하기 위한 종래의 기술로서는 대한민국 공개특허공보 10-2012-0067865호에 공유 메모리 채널 다중화 방법 및 그 장치가 공지되어 있다.

그러나 상기 종래의 기술은 공유 메모리의 채널을 다중화 함으로써, 잠금(lock) 기능에 의해 특정 시간 동안 특정 프로세스가 공유 메모리를 독점함으로써 발생하는 문제를 해결하는 것으로, 단순히 복수의 프로세스들이 공유 메모리에 동시 접속하여 데이터를 억세스할 수 있도록 하는 것이다.

결론적으로 보안이 취약한 기존 FIFO방식을 보안하고, 파일 통신 가반의 Pipe, FIFO의 관리 한계점을 보안할 수 있으며 AOSP에서 제공되는 AIDL, Messenger, Intent, Native Service 보다 빠르고 안정적으로 다른 어플리케이션과 통신을 가능하게 해주는 기술이 요구되어진다.

상기와 같은 종래 기술의 문제점을 해결하기 위하여 안출된 본 발명은 UDS 기반의 a named pipe형태로 구현한 FD 통하여 파일 통신 기반의 FIFO의 관리 한계점 및 보안이 취약한 기존 FIFO 방식을 보완할 수 있으며 AOSP에서 제공되는 AIDL 보다 빠르고 안정적으로 다른 어플리케이션과 통신을 가능하게 해주는 목적이 있다.

또한, 본 발명은 UDS를 통한 양방향 통신 방식으로 Native 간에 직접 통신하는 방법을 사용하는 구조이므로 중간 중간에 거쳐야 하는 계층들을 생략 가능하여 FD를 통하여 네이티브 단에서 직접적인 통신을 제공하는 목적이 있다.

또한, 본 발명은 메모리 기반의 통신 방법이 가능하기 때문에 기존 내부 어플리케이션간 통신 기법에 있어서 종래기술의 한계점을 극복 가능하게 하는 것에 다른 목적이 있다.

본 발명의 상기 목적을 달성하기 위하여 AOSP를 기반으로 하는 서로 다른 어플리케이션의 통신 방법에 있어서, 제1어플리케이션과 제2어플리케이션을 실행하는 제1단계, 상기 제1어플리케이션과 상기 제2어플리케이션의 리소스를 초기화하는 제2단계, 상기 제1어플리케이션에서 UDS(Unix Domain Socket) 기반의 SocketPair 함수를 호출하여 a named pipe 방식으로 인덱스 0과 인덱스 1의 FD(File Descriptor)배열을 생성하는 제3단계, 상기 제3단계에서 생성된 FD 배열에서 상기 FD 배열의 인덱스 0번째의 FD를 대상으로 읽기 전용 FD[0]과 쓰기 전용 FD[0]을 생성하는 제4단계, 상기 제2어플리케이션에서 제1어플리케이션에 UDS 정보를 요청하는 제5단계, 상기 제5단계의 UDS의 요청에 따라 상기 제1어플리케이션은 상기 인덱스 1의 FD를 UDS의 응답으로 송신하는 제6단계 및 상기 제6단계의 UDS의 응답에 따라 상기 제2어플리케이션에서 인덱스 1번째의 FD를 대상으로 읽기 전용 FD[1]과 쓰기 전용 FD[1]을 생성하는 제7단계를 통하여 AOSP 기반에서 서로 다른 어플리케이션 간에 UDS 기반으로 양방향 통신을 수행하게 하는 것을 통하여 달성되어진다.

따라서 본 발명의 AOSP 기반에서 내부 어플리케이션 간 통신의 최적화 방법은 AOSP 기반에서 Unix Domain Socket(이하UDS)를 a named pipe형태로 구현한 본 발명을 통해 보안이 취약한 기존 FIFO방식을 보안하고, 파일 통신 기반의 Pipe, FIFO의 관리 한계점을 보안할 수 있는 효과가 있다.

또한, 본 발명은 AOSP에서 제공되는 AIDL, Messenger, Intent, Native Service 보다 빠르고 안정적으로 다른 어플리케이션과 통신을 가능하게 해주는 효과가 있다.

또한, 본 발명은 Java 어플리케이션으로 개발이 된다 하더라도 Native 간에 직접 통신하는 방법을 사용하는 구조로 개발할 수 있다.

도 1은 종래의 기술에 다른 AIDL을 통한 통신 방식을 보여주는 개념도이고,
도 2는 본 발명에 따른 AOSP 기반에서 내부 어플리케이션 간 통신의 최적화 방법의 흐름을 나타내는 흐름도이고,
도 3은 본 발명의 일실시예에 따른 UDS를 통하여 생성되어진 FD 배열을 나타내는 예시도,
도 4는 본 발명의 일실시예에 따른 AOSP 기반에서 음성인식과 내비게이션간의 어플리케이션 간 통신 방법의 적용 개념도,
도 5는 본 발명의 일실시예에 따른 UDS를 통한 통신 방식을 보여주는 개념도이다.

본 명세서 및 청구범위에 사용된 용어나 단어는 통상적이거나 사전적인 의미로 한정해서 해석되어서는 아니 되며, 발명자는 그 자신의 발명을 가장 최선의 방법으로 설명하기 위해 용어의 개념을 적절하게 정의할 수 있다는 원칙에 입각하여 본 발명의 기술적 사상에 부합하는 의미와 개념으로 해석되어야만 한다.

따라서 본 명세서에 기재된 실시예와 도면에 도시된 구성은 본 발명의 가장 바람직한 일 실시예에 불과할 뿐이고 본 발명의 기술적 사상을 모두 대변하는 것은 아니므로, 본 출원시점에 있어서 이들을 대체할 수 있는 다양한 균등물과 변형예들이 있을 수 있음을 이해하여야 한다.

이하 첨부된 도면을 참조하여 본 발명의 바람직한 실시예를 상세히 설명하기로 한다.

도 2는 본 발명에 따른 AOSP 기반에서 내부 어플리케이션 간 통신의 최적화 방법의 흐름을 나타내는 흐름도이다.

도시와 같이 본 발명은 AOSP를 기반으로 하는 서로 다른 어플리케이션의 통신 방법에 있어서, 서로 다른 어플리케이션을 실행하는 제1단계(S100), 상기 서로 다른 어플리케이션의 리소스를 초기화하는 제2단계(S200), 제1어플리케이션에서 FD(File Descriptor)배열을 생성하는 제3단계(S300), 상기 FD 배열에서 인덱스 0번째의 FD를 대상으로 읽기 전용 FD[0]과 쓰기 전용 FD[0]을 생성하는 제4단계(S400), 상기 제2어플리케이션에서 UDS 정보를 요청하는 제5단계(S500), 상기 제1어플리케이션이 상기 인덱스 1의 FD를 상기 제2어플리케이션에 전달하는 제6단계(S600) 및 상기 제2어플리케이션이 인덱스 1번째의 FD를 대상으로 읽기 전용 FD[1]과 쓰기 전용 FD[1]을 생성하는 제7단계(S600)를 통하여 AOSP 기반에서 서로 다른 어플리케이션 간에 UDS 기반의 양방향 통신을 수행하게 된다.

상기 제1단계(S100)는 사용자가 펌웨어(HW)상에서 어플리케이션을 실행하는 단계로, 상기 어플리케이션이란 안드로이드 프레임워크(Android Framework) 상에서 존재하는 서로 다른 프로세스를 의미한다.

본 발명에서는 UDS 함수를 호출하여 FD 배열을 생성하고 이를 다른 프로세스에게 전달하는 역할을 하는 프로세스를 제1어플리케이션, UDS를 요청하고 상기 FD를 수신하여 상기 제1어플리케이션과 통신하는 프로세스를 제2어플리케이션으로 정의한다.

이후 상기 제2단계(S200)에서는 상기 제1어플리케이션과 상기 제2어플리케이션의 리소스를 초기화한다.

상기 제3단계(S300)는 상기 제1어플리케이션에서 BSD, POSIX.1-2001에서 제정한 UDS(Unix Domain Socket) 기반의 SocketPair 함수를 호출하여 a named pipe 방식으로 인덱스 0과 인덱스 1의 FD(File Descriptor)배열을 생성하는 단계이다.

상기 FD는 정수형으로 int fd[2]로 정의된다.

도 3은 본 발명에 따른 UDS를 통하여 생성되어진 FD 배열을 나타내는 예시도로서, 도시와 같은 인덱스를 갖는 FD 배열을 생성하고 사용하게 되는 것이다.

여기서 상기 인덱스 0의 FD는 상기 제1어플리케이션이 상기 제2어플리케이션과의 통신을 위한 것이고, 상기 인덱스 1의 FD는 상기 제2어플리케이션이 상기 제1어플리케이션과의 통신을 위해 사용하기 위한 FD이다.

상기 제4단계(S400)는 상기 제3단계(S300)에서 생성된 FD 배열에서 상기 FD 배열의 인덱스 0번째의 FD를 대상으로 읽기 전용 FD[0]과 쓰기 전용 FD[0]을 생성하는 단계로서, 상기 읽기 전용 FD[0]는 상기 제2어플리케이션이 데이터를 보내고 있는지 감지하는 FD이고, 상기 쓰기 전용 FD[0]는 상기 제2어플리케이션으로 데이터를 보내기 위하여 사용하는 FD인 것을 특징으로 한다.

상기 인덱스 0번째의 FD를 대상으로 읽기 전용 FD[0]과 쓰기 전용 FD[0]는 dup(fd[0])함수를 이용한다.

또한, 상기 제5단계(S500)는 상기 제2어플리케이션에서 제1어플리케이션에 UDS 정보를 요청하는 단계이다.

상기 제6단계(S600)는 상기 제1어플리케이션에서 상기 인덱스 1의 FD를 UDS의 응답으로 송신하는 단계이다.

이때, 상기 제2어플리케이션에서의 UDS 정보 요청에 따라 상기 제1어플리케이션은 상기 인덱스 1의 FD를 상기 제2어플리케이션에 전달하기 위하여 AIDL(Android Interface Definition Language)의 정의 및 RPC(Remote Procedure Call) 통신을 위한 스터브(stub) 코드를 정의하여야 한다.

서버가 클라이언트에게 데이터를 요청할 때 클라이언트는 전달하고자 하는 데이터와 메시지를 받을 스레드를 식별하기 위하여 해당 소켓 을 ID 그리고 해당 데이터의 크기, 타입, 그리고 플래그 등의 메시지를 생성하고 이러한 메시지를 전송하게 된다. 이때, 상기 AIDL의 컴파일러에 의하여 상기 요소들이 생성이 된다. 이때 이러한 메시지를 전송하기 위하여 사용하는 것이 AIDL(Android Interface Definition Language)이다.

또한, 상기 스터브 코드란 내부 통신을 위해 메세지를 만들고 서비스를 요청하는 코드들이 상기 AIDL 컴파일러에 의해서 자동적으로 생성이 되는 코드를 의미한다.

상기 제7단계(S700)는 상기 제6단계(S600)의 UDS의 응답에 따라 상기 제2어플리케이션에서 인덱스 1번째의 FD를 대상으로 읽기 전용 FD[1]과 쓰기 전용 FD[1]을 생성하는 단계이다.

이때도 상기 제7단계(S700)의 읽기 전용 FD[1]은 상기 제1어플리케이션이 데이터를 보내고 있는지 감지하는 FD이고, 쓰기 전용 FD[1]은 상기 제1어플리케이션으로 데이터를 보내기 위하여 사용하는 FD 임을 알 수 있다.

도 4는 본 발명의 일실시예에 따른 AOSP 기반에서 음성인식과 내비게이션간의 어플리케이션 간 통신 방법의 적용 개념도이다.

도시에서는 본 발명의 제1어플리케이션을 음성인식 어플리케이션으로 제2어플리케이션을 내비게이션 어플리케이션으로 정의한다.

그러므로 상기 음성인식 어플리케이션에서 사용자가 인식한 정보를 내비게이션 어플리케이션으로 전달하기 위해 UDS를 기반으로 통신하기 위해 진행되는 Flow를 시간적인 순서에 따라 설명하면 다음과 같다.

먼저 펌웨어(HW)에서는 상기 음성인식 어플리케이션을 실행하게 된다(1). 실행되는 음성인식 어플리케이션에서는 리소스들의 초기화를 진행(2)하게 되는데, 이 과정이 끝나면 상기 음성인식은 SocketPair를 호출하여 UDS에 대한 FD 배열을 생성(3)한다. 여기서 SocketPair은 BSD, POSIX,1-2001에서 제정한 표준API로 UDS를 생성하는 기능을 제공한다.

상술한 과정이 끝나면 음성인식 어플리케이션은 다른 프로세스와 통신하기 위해 FD[0]에 대해 FD 복사 함수인 dup를 사용하여 file descriptor(이하 fd)를 생성하게 된다(4). 이 때 생성된 fd는 총 2개를 생성하는데, 다른 어플리케이션과 통신 시 데이터를 송신/수신하는 목적으로 각각을 생성하는 것이다.

이후 펌웨어에서는 내비게이션 어플리케이션을 실행한다(5). 이때 실행되는 내비게이션은 초기화 과정(6)이 끝나면 음성인식에게 UDS를 요청하는 과정(7)을 진행하게 된다.

상기 음성인식 어플리케이션에서는 내비게이션 어플리케이션에게 상기 (3)단계에서 생성한 FD[1]을 전달하게 된다(8).

그리고 내비게이션 어플리케이션은 전달받은 FD[1]을 통해 음성인식과 통신을 위한 송신/수신하는 목적으로 각각에 대한 FD를 생성한다(9).

이후 UDS를 기반으로 하는 FD를 이용하여 상기 음성인식과 내비게이션 어플리케이션간 통신이 이루어지게 되는 것이다.

도 5는 본 발명의 일실시예에 따른 UDS를 통한 통신 방식을 보여주는 개념도이다.

도시와 같이 본 발명은 AOSP 기반 위에서 서로 다른 어플리케이션끼리 데이터를 주고받는 통신 시에 양방향의 UDS를 기반으로 하는 FD의 생성과 이를 활용한 통신 방법에 의하여 종래의 기술에서 발생하는 중간 과정에서 발생하는 계층들을 생략할 수 있어서 네이티브단에서 서로 다른 어플리케이션간의 직접적인 통신을 이루는 진보적인 기술임을 알 수 있다.

본 발명은 이상에서 살펴본 바와 같이 바람직한 실시예를 들어 도시하고 설명하였으나, 상기한 실시예에 한정되지 아니하며 본 발명의 정신을 벗어나지 않는 범위 내에서 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변경과 수정이 가능할 것이다.

Claims

AOSP를 기반으로 하는 서로 다른 어플리케이션의 통신 방법에 있어서,
제1어플리케이션과 제2어플리케이션을 실행하는 제1단계,
상기 제1어플리케이션과 상기 제2어플리케이션의 리소스를 초기화하는 제2단계,
상기 제1어플리케이션에서 UDS(Unix Domain Socket) 기반의 SocketPair 함수를 호출하여 a named pipe 방식으로 인덱스 0과 인덱스 1의 FD(File Descriptor)배열을 생성하는 제3단계,
상기 제3단계에서 생성된 FD 배열에서 상기 제1어플리케이션이 상기 FD 배열의 인덱스 0번째의 FD를 대상으로 읽기 전용 FD[0]과 쓰기 전용 FD[0]을 생성하는 제4단계,
상기 제2어플리케이션에서 제1어플리케이션에 UDS 정보를 요청하는 제5단계,
상기 제5단계의 UDS의 요청에 따라 상기 제1어플리케이션은 상기 인덱스 1의 FD를 UDS의 응답으로 송신하는 제6단계, 및
상기 제6단계의 UDS의 응답에 따라 상기 제2어플리케이션에서 인덱스 1번째의 FD를 대상으로 읽기 전용 FD[1]과 쓰기 전용 FD[1]을 생성하는 제7단계를 포함하고,
상기 제7단계를 통하여 AOSP 기반에서 서로 다른 어플리케이션 간에 UDS 기반으로 양방향 통신을 수행하게 하고,
상기 제4단계에서, 상기 읽기 전용 FD[0]는 상기 제2어플리케이션이 상기 제1어플리케이션으로 데이터를 보내고 있는지 감지하는 FD이고, 상기 쓰기 전용 FD[0]는 상기 제1어플리케이션이 상기 제2어플리케이션으로 데이터를 보내기 위하여 사용하는 FD이고,
상기 제7단계에서, 상기 읽기 전용 FD[1]은 상기 제1어플리케이션이 상기 제2어플리케이션으로 데이터를 보내고 있는지 감지하는 FD이고, 상기 쓰기 전용 FD[1]은 상기 제2어플리케이션이 상기 제1어플리케이션으로 데이터를 보내기 위하여 사용하는 FD인 것을 특징으로 하는 AOSP 기반에서 내부 어플리케이션 간 통신의 최적화 방법.
제1 항에 있어서,
상기 제3단계에서 상기 인덱스 0의 FD는 상기 제1어플리케이션이 상기 제2어플리케이션과의 통신을 위한 것이고, 상기 인덱스 1의 FD는 상기 제2어플리케이션이 상기 제1어플리케이션과의 통신을 위해 사용하기 위한 FD인 것을 특징으로 하는 AOSP 기반에서 내부 어플리케이션 간 통신의 최적화 방법.
제1 항에 있어서,
상기 제5단계에서 상기 제2어플리케이션에서 UDS 정보의 요청에 따라 상기 제1어플리케이션은 상기 인덱스 1의 FD를 상기 제2어플리케이션에 전달하기 위하여 AIDL(Android Interface Definition Language)의 정의 및 RPC(Remote Procedure Call) 통신을 위한 스터브(stub) 코드를 정의하는 것을 특징으로 하는 AOSP 기반에서 내부 어플리케이션 간 통신의 최적화 방법.
삭제
삭제