KR20100101933A - 기능별로 모듈화된 구조로 이루어진 모바일 플랫폼이 탑재된 이동통신단말, 그 모바일 플랫폼의 동작 방법 및 대기화면 어플리케이션 관리 방법 - Google Patents

기능별로 모듈화된 구조로 이루어진 모바일 플랫폼이 탑재된 이동통신단말, 그 모바일 플랫폼의 동작 방법 및 대기화면 어플리케이션 관리 방법 Download PDF

Info

Publication number
KR20100101933A
KR20100101933A KR1020090020379A KR20090020379A KR20100101933A KR 20100101933 A KR20100101933 A KR 20100101933A KR 1020090020379 A KR1020090020379 A KR 1020090020379A KR 20090020379 A KR20090020379 A KR 20090020379A KR 20100101933 A KR20100101933 A KR 20100101933A
Authority
KR
South Korea
Prior art keywords
module
application
mobile platform
idle screen
function
Prior art date
Application number
KR1020090020379A
Other languages
English (en)
Other versions
KR101083090B1 (ko
Inventor
차경찬
Original Assignee
주식회사 케이티
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 케이티 filed Critical 주식회사 케이티
Priority to KR1020090020379A priority Critical patent/KR101083090B1/ko
Publication of KR20100101933A publication Critical patent/KR20100101933A/ko
Application granted granted Critical
Publication of KR101083090B1 publication Critical patent/KR101083090B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Stored Programmes (AREA)
  • Telephone Function (AREA)

Abstract

본 발명은, 기능별로 모듈화된 구조로 이루어진 모바일 플랫폼이 탑재된 이동통신단말, 그 모바일 플랫폼의 동작 방법 및 대기화면 어플리케이션 관리 방법에 관한 것이다.
본 발명에 따르면, 모바일 플랫폼은 모바일 플랫폼을 구현하는데 필수적인 기능들을 포함하는 커널 계층 모듈, 이동통신 단말에서 어플리케이션을 실행하기 위한 응용 프로그래밍 인터페이스 함수를 관리하는 응용 프로그래밍 인터페이스 계층 모듈 및 응용 프로그래밍 인터페이스 함수가 구현하는 기능을 수행하는 시스템 계층 모듈로 계층화되고, 모바일 플랫폼을 구성하는 단위 기능을 독립된 플랫폼 코드 바이너리 형태의 개별 모듈로 구현한 구조로 이루어진다.
따라서, 모바일 플랫폼에 정적으로 탑재되는 모듈 범위를 최소화하여 단말 바이너리 교체없이 모바일 플랫폼의 기능 업데이트가 용이하다.
Figure P1020090020379
모바일 플랫폼, 커널 계층, 응용 프로그래밍 인터페이스(API) 계층, 시스템 계층, 대기화면

Description

기능별로 모듈화된 구조로 이루어진 모바일 플랫폼이 탑재된 이동통신단말, 그 모바일 플랫폼의 동작 방법 및 대기화면 어플리케이션 관리 방법{Mobile terminal with mobile platform comprising structure of functional modularization, method for driving the mobile platform and managing idle application}
본 발명은, 기능별로 모듈화된 구조로 이루어진 모바일 플랫폼이 탑재된 이동통신단말, 그 모바일 플랫폼의 동작 방법 및 대기화면 어플리케이션 관리 방법에 관한 것이다.
최근 이동통신 단말기의 성능향상 및 고객의 다양한 컨버전스 니즈(Needs)에 따라 기능 폰(Feature Phone) 및 스마트폰에서 'General Purpose OS(Operating System)'의 탑재가 시도되고 있어 모바일 플랫폼도 그에 따른 변화가 요구되고 있다.
이러한 고객의 다양한 필요성에 부합하는 특화된 단말의 등장은 모든 기능을 탑재한 거대한 모바일 플랫폼의 탑재가 부담으로 작용하게 한다. 따라서, 단말 특성에 따라 필요한 기능만을 조합한 경량화된 모바일 플랫폼이 필요하다.
이동통신 단말의 성능 향상과 더불어 Windows Mobile, Embedded Linux와 같은 범용 OS 탑재 단말이 늘고 있다. 이러한 추세는 다양한 범용 OS위에 모바일 플랫폼을 쉽게 포팅할 수 있도록 플랫폼의 구조적 개선을 요구한다.
도 1은 종래의 모바일 플랫폼 구조이고, 도 2는 종래 모바일 플랫폼의 바이너리 구조를 나타낸다.
도 1에 따르면, 종래 모바일 플랫폼은 롬 바이너리(ROM Binary)(11), EFS 바이너리(13), APP 1, 2, 3(15), APM(Application Performance Management) 모듈(17), 다운로더(Downloader)(19), KIKA(21), Native system software(23) 및 커널(25) 및 HAL(Hardware Adaptation Layer)(27)로 구성된다.
이때, 도 2에 보인 바와 같이, Native system software(23) 및 커널(25)은 하나의 바이너리 플랫폼 코드를 사용하고, 이 바이너리 플랫폼 코드는 이동통신 단말의 바이너리 코드를 링크한다. 즉 플랫폼 코드가 단말 바이너리에 정적(static)으로 링크되어 단말 부팅 시 플랫폼 코드가 메모리에 로딩되는 구조이다.
도 3a는 종래 모바일 플랫폼의 패키지 종류를 나타내고, 도 3b는 패키지 상호 관계를 나타낸다.
도 3a에 따르면, 종래의 모바일 플랫폼은 모듈들이 패키지 단위로 구분되어 있다. 최상위 패키지는 CP(Contens Provider)가 제공하는 패키지(29)로서 wec 패키지(31), java 패키지(33), org 패키지(35)가 존재하고, 내부 구현되는 패키지(37)로서 com 패키지(39), ams 패키지(41), javax 패키지(43)가 있다.
그러나 도 3b에 보인 것처럼, 패키지들(31, 33, 35, 39, 41, 43) 간의 상호 관계가 상하 관계를 분별하기 어렵고 수평적으로도 복잡하게 얽혀있어 동적으로 기능 단위의 모듈을 추가, 수정, 삭제하기 어려운 구조이다.
또한, 종래 모바일 플랫폼의 커널(kernel)은 커널의 모든 기능이 오브젝트(object)로 구성되어 하나의 바이너리로 링크되는 구조이다. 즉 종래 모바일 플랫폼의 커널은 모든 기능이 하나의 바이너리로 구성되도록 되어있는 것이다. 여기에는 'Target O/S'에 따라 코드가 달라져야 하는 부분들도 함께 빌드되어 바이너리에 포함된다. 그리고 H/W 의존성(Dependency)이 있는 모듈 및 그래픽 모듈도 모두 커널에 포함되어 상호간 함수 호출이 직접 이루어진다.
따라서, 이러한 커널 구조의 모바일 플랫폼은 기능간 구분이 모호하고, 하위 레이어 참조 코드가 존재하며, 타겟에 맞는 커널 재빌드가 필요한 문제점이 있다.
이상과 같이, 과거 이동통신 단말의 저사양 문제로 종래의 모바일 플랫폼은 단말 제조사 바이너리에 링크되는 구조로 설계된다. 따라서, 모바일 플랫폼의 일부 기능을 개선 또는 추가하기 위해서 모바일 플랫폼 전체 빌드, 제조사 배포, 단말제조사 바이너리 링크 등의 여러 단계를 거처야만 하는 시간적/비용적 문제가 발생한다. 즉 이동통신 단말 출시 후 기능 단위 업데이트 및 기능 추가가 사실상 힘든 상황인 것이다.
이러한 모바일 플랫폼의 구조적 문제는 다양한 3rd Part 솔루션 업체 또는 개인이 플랫폼 기능 확장에 사실상 참여를 어렵게 만들었다. 이는 최근 심화된 모바일 플랫폼 부문 경쟁에서 도태될 수 있음을 의미한다.
한편, 종래 모바일 플랫폼의 대기화면 모듈은 APM(Application Performance Management) 코드에 의존적이어서 모듈화 개념이 부족하다. 즉, 대기화면 모듈의 기능 추가나 변경이 이루어질 경우 APM에 큰 영향을 주는 부분이 많다. 반대로 APM의 기능 추가나 변경이 이루어질 경우에도 대기화면 모듈에 영향을 주는 부분이 많다.
또한, 종래 모바일 플랫폼의 대기화면 어플리케이션 설정, 해제 및 관리 처리가 모두 APM의 Idle 패키지에서 처리된다. 따라서 대기화면 서비스를 지원하지 않는 단말에 플랫폼 라이브러리를 배포할 때 관련 기능이 탑재된 상태로 바이너리가 제공 되어 APM의 수정으로 인해 대기화면 서비스에 영향을 미치는 현상이 다수 발생한다.
게다가 대기화면 어플리케이션은 모바일 플랫폼에서 제공하는 'IdleJlet'을 상속 받아야만 서비스가 가능하다. 즉 'MA', 'MTA' 두 가지에 대해서만 대기화면 서비스를 제공함으로 새로운 버전의 모바일 플랫폼에서 제공되고 있는 'MIDAS', 'Popup 플러스' 형태의 대기화면 서비스를 지원하기 위해서는 모바일 플랫폼에서 또는 'OEM(Original Equipment manufacturer'에서 별도의 처리가 제공되어야만 서비스가 가능하다. 따라서 대기화면 서비스가 추가 될 경우 모바일 플랫폼 수정 사항이 발생하고 추가적으로 OEM 수정사항이 발생하게 된다.
본 발명이 이루고자 하는 기술적 과제는, 모바일 플랫폼에 정적으로 탑재되 는 모듈 범위를 최소화하여 단말 바이너리 교체없이 모바일 플랫폼의 기능 업데이트하기 용이하도록 기능 별로 모듈화된 구조로 이루어진 기능별로 모듈화된 구조로 이루어진 모바일 플랫폼이 탑재된 이동통신단말, 그 모바일 플랫폼의 동작 방법 및 대기화면 어플리케이션 관리 방법을 제공하는 것이다.
본 발명의 한 특징에 따르면, 모바일 플랫폼이 탑재된 이동통신 단말이 제공된다. 이동통신 단말은, 메모리에 상주하여 상기 모바일 플랫폼의 프로세스를 제어하는 기능들을 포함하는 커널 계층 모듈; 상기 이동통신 단말에서 어플리케이션을 실행하기 위한 응용 프로그래밍 인터페이스 함수를 관리하는 응용 프로그래밍 인터페이스 계층 모듈; 및 상기 커널 계층 모듈 및 상기 응용 프로그래밍 인터페이스 계층 모듈 사이에 위치하고, 상기 응용 프로그래밍 인터페이스 함수가 구현하는 기능을 수행하는 시스템 계층 모듈을 포함하고, 상기 커널 계층 모듈, 상기 응용 프로그램 인터페이스 계층 모듈 및 상기 시스템 계층 모듈은 각각의 기능이 독립된 플랫폼 코드 바이너리 형태의 개별 모듈로 구현되는 것을 특징으로 한다.
본 발명의 다른 특징에 따르면, 모바일 플랫폼의 동작 방법이 제공된다. 동작 방법은, 이동통신 단말에 탑재되어 어플리케이션의 실행 환경을 제공하는 모바일 플랫폼의 동작 방법에 있어서, 상기 이동통신 단말이 부팅되면 커널 계층 모듈이 모바일 플랫폼 동작에 필요한 기본 모듈들을 로딩하여 모바일 플랫폼을 초기화하고, 어플리케이션 수행 관리 모듈을 구동시키는 단계; 상기 어플리케이션 수행 관리 모듈의 제어하에 실행된 어플리케이션이 응용 프로그래밍 인터페이스 계층 모 듈이 제공하는 해당되는 응용 프로그래밍 인터페이스 및 상기 응용 프로그래밍 인터페이스를 구현하는 시스템 계층 모듈을 호출하는 단계; 및 상기 시스템 계층 모듈이 상기 커널 계층 모듈에게 하드웨어 적응 계층 인터페이스 호출을 요청하여 상기 실행된 어플리케이션이 제공하는 기능을 구현하는 단계를 포함하고, 상기 모바일 플랫폼은 메모리에 상주하여 상기 모바일 플랫폼의 프로세스를 제어하는 상기 커널 계층 모듈, 상기 이동통신 단말에서 어플리케이션을 실행하기 위한 응용 프로그래밍 인터페이스 함수를 관리하는 응용 프로그래밍 인터페이스 계층 모듈 및 상기 커널 계층 모듈 및 상기 응용 프로그래밍 인터페이스 계층 모듈 사이에 위치하여 상기 응용 프로그래밍 인터페이스 함수가 구현하는 기능을 수행하는 시스템 계층 모듈로 계층화되고, 상기 커널 계층 모듈, 상기 응용 프로그램 인터페이스 계층 모듈 및 상기 시스템 계층 모듈은 각각의 기능이 독립된 플랫폼 코드 바이너리 형태의 개별 모듈로 구현된 구조로 이루어지는 것을 특징으로 한다.
본 발명의 또 다른 특징에 따르면, 이동통신 단말의 대기화면 어플리케이션 관리 방법이 제공된다. 대기화면 어플리케이션 관리 방법은, 대기화면에 설정된 대기화면 어플리케이션이 포어그라운드(foreground) 팝업이 되는 경우, 액티브즐렛(activeJlet)-여기서 액티브즐렛(activeJlet)은 화면 점유를 위해 필요한 설정 파라미터로서 액티브즐렛(activeJlet)으로 설정된 어플리케이션은 화면을 점유하게 됨-을 어플리케이션 수행 관리 모듈로 변경하고 팝업 매니저를 종료시키는 단계; 상기 대기화면 어플리케이션을 포어그라운드로 설정하고 액티브즐렛(activeJlet)을 대기화면 어플리케이션으로 변경하는 단계; 및 변경된 상기 대기화면 어플리케이션 이 활성화되면, 대기화면 어플리케이션의 프레임 버퍼를 플러시하여 상기 프레임 버퍼로 화면 갱신이 이루어지게 하는 단계를 포함한다.
본 발명의 또 다른 특징에 따르면, 이동통신 단말의 대기화면 어플리케이션 관리 방법이 제공된다. 대기화면 어플리케이션 관리 방법은, 실행 요청된 어플리케이션이 모바일 플랫폼에 정의된 어플리케이션이 아닌 경우, 확장 실행형 컨텐츠로 구동 가능한지 여부를 판단하는 단계; 및 확장 실행형 컨텐츠로 구동 가능한 경우로 판단되면, 커널 계층 모듈에게 요청하여 해당되는 확장 실행형 컨텐츠 핸들러-여기서 확장 실행형 컨텐츠 핸들러는 상기 모바일 플랫폼에 정의된 어플리케이션 형태임-를 구동하여 상기 실행 요청된 어플리케이션이 확장 실행형 컨텐츠 형태로 실행되도록 하는 단계를 포함한다.
본 발명에 의하면, 단말의 종류, 하드웨어 특성에 따라 선별적으로 선택된 모듈들로 구성된 모바일 플랫폼을 단말에 탑재할 수 있다.
또한, 모바일 플랫폼에 새로운 기능의 추가, 변경, 삭제가 용이하여 단말 출시 이후, 모바일 플랫폼 기능 개선, 통신 사업자의 신규 서비스 제공 목적으로 새로운 기능 모듈을 추가, 변경할 수 있다.
또한, 모바일 플랫폼이 프로파일(profile) 기능을 제공하여 프로파일 단위로 패키징해서 모바일 플랫폼이 배포되므로, 단말 사양 별로 선별적으로 기능 탑재가 이루어진다.
또한, 종래에 모바일 플랫폼의 APM에 종속적인 기능으로 구현되던 대기화면 기능을 대기화면 제어 모듈로 분리함으로써 대기화면 서비스를 지원하지 않는 단말에서는 대기화면 제어 모듈을 탑재하지 않도록 하여 경량화된 모바일 플랫폼을 제공할 수 있다.
아래에서는 첨부한 도면을 참고로 하여 본 발명의 실시예에 대하여 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나 본 발명은 여러 가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시예에 한정되지 않는다. 그리고 도면에서 본 발명을 명확하게 설명하기 위해서 설명과 관계없는 부분은 생략하였으며, 명세서 전체를 통하여 유사한 부분에 대해서는 유사한 도면 부호를 붙였다.
명세서 전체에서, 어떤 부분이 어떤 구성요소를 "포함"한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성요소를 더 포함할 수 있는 것을 의미한다. 또한, 명세서에 기재된 "…부", "…기", "모듈" 등의 용어는 적어도 하나의 기능이나 동작을 처리하는 단위를 의미하며, 이는 하드웨어나 소프트웨어 또는 하드웨어 및 소프트웨어의 결합으로 구현될 수 있다.
본 명세서에서 모바일 플랫폼은 이동통신 단말에 탑재되어 모바일 표준 플랫폼 규격에 따라 작성된 응용프로그램을 실행시킬 수 있는 단말의 실행 환경(Runtime Execution Environment)을 의미한다. 모바일 플랫폼은 응용프로그램 관리와 API(Application Programing Interface) 관리 기능을 포함한다.
본 발명의 실시예에 따르면, 모바일 플랫폼은 기능 단위로 세분화되어 기능 별로 모듈화된 구조로 이루어진다.
이하, 도면을 참조로 하여 본 발명의 실시예에 따른 기능별로 모듈화된 구조로 이루어진 모바일 플랫폼이 탑재된 이동통신단말, 그 모바일 플랫폼의 동작 방법 및 대기화면 어플리케이션 관리 방법에 대해 설명한다.
이때, 제1 실시예에서는 기능 별로 모듈화된 모바일 플랫폼의 구조를 설명한다. 제2 실시예에서는 모바일 플랫폼의 모듈 중에서 커널 모듈의 세부 구조를 설명한다. 제3 실시예에서는 모바일 플랫폼의 모듈 중에서 종래에 APM(Application Performance Management) 모듈에 종속된 하나의 기능 형태로 구현되던 대기화면 점유 기능을 하나의 독립적인 모듈로 구현한 대기화면 제어 모듈에 대해 설명한다.
<제1 실시예>
도 4는 본 발명의 제1 실시예에 따른 모바일 플랫폼의 기능 별로 모듈화된 구조를 나타낸 개념도이다.
도 4에 보인 바와 같이, 모바일 플랫폼은 기능별로 모듈화된 구조로 이루어진다. 이때, 기능별로 모듈화된 구조는 수평적 모듈화와 수직적 모듈화로 이루어진다.
수평적 모듈화는 모바일 플랫폼에 대한 단위 기능을 정의하고 단위 기능을 모듈화하여 구현하는 것이다. 이렇게 하면, 단말의 종류, 하드웨어 특성에 따라 선별적으로 선택된 모듈들로 구성된 모바일 플랫폼을 단말에 탑재할 수 있다. 또한, 모바일 플랫폼에 새로운 기능의 추가, 변경, 삭제가 용이하다. 따라서, 단말 출시 이후, 모바일 플랫폼 기능 개선, 통신 사업자의 신규 서비스 제공 목적으로 새로운 기능 모듈을 추가, 변경할 수 있다.
수직적 모듈화는 프로세스, 메모리 및 이벤트 등을 관리하는 커널 계층(Kernel Layer)(101), 네트워크, IO(InputOutput), 미디어 등 플랫폼의 중추적 기능을 담당하며 API 기능을 수행하는 시스템 계층(System Layer)(103) 및 어플리케이션이 사용하는 API의 표준을 담당하는 API 계층(Layer)(105)으로 계층화된 것이다. 이때, 각 계층은 복수의 단위 기능을 포함하고, 각각의 단위 기능은 하나의 모듈(107)로 구현된다.
여기서, 모듈(107)은 모바일 플랫폼을 구성하는 각 기능별로 분류된 독립된 플랫폼 코드 바이너리라 정의한다. 따라서, 종래에 플랫폼 코드가 단말 바이너리에 정적(static)으로 링크되던 것과 달리 본 발명의 실시예에 따른 모바일 플랫폼은 각 모듈에 따른 단말 탑재 바이너리를 선별적으로 선택할 수 있는 구조로 이루어진다.
모바일 플랫폼을 기능 단위로 세분화하여 동적 라이브러리로 구성할 수 없는 기능을 분류하고 이를 모듈(107)로 구현한다. 즉 정적으로 탑재되는 모듈 범위를 최소화하여 단말 바이너리 교체없이 모바일 플랫폼의 일부 기능을 업데이트할 수 있게 한다.
각 모듈(107)은 모듈 출력(export) 인터페이스 및 모듈 입력(import) 인터페이스를 제공한다. 즉 모듈(107)은 다른 모듈이나 어플리케이션에서 사용할 수 있도록 모듈(107)에서 제공하는 함수를 출력하는 모듈 출력(export) 인터페이스를 제공 한다. 또한, 모듈(107)은 다른 모듈의 인터페이스를 사용할 경우 다른 모듈로부터 함수를 입력받을 모듈 입력(import) 인터페이스를 제공한다.
또한, C, JAVA 인터페이스를 모두 지원하는 모바일 플랫폼의 기능은 하나의 모듈(107)로 구성하여 API 계층(300)으로 분류한다. 즉 같은 기능을 수행하며 C와 JAVA 인터페이스를 제공하는 소스들을 한 곳으로 모아 하나의 라이브러리(library로 생성될 수 있게 한다.
이와 같이 구현된 모듈(107)은 다음과 같은 특징들을 가진다.
먼저, JAVA로 구현된 기능을 모듈화하기 위해서는 모듈화하고자 하는 기능들을 계층화하여 상호 참조할 수 있는 범위에 제한을 둔다. 즉 상위 모듈의 함수 참조는 가능하되, 하위 또는 동등 모듈의 함수 참조는 제거하거나 보완한다.
여기서, 하위 또는 동등 모듈의 함수 참조가 있는 경우 참조 부분을 클래스 내부 함수로 구현한다.
만약, 내부 함수로의 구현이 어려운 경우에는 참조 받는 클래스를 인터페이스로 만들고 빌드(build)를 위해 엠티(empty) 클래스를 제공한다. 여기서, 인터페이스는 입력 또는 출력 인터페이스이다. 즉 상위 계층에 속하는 모듈이 하위 계층에 속하는 모듈에 디펜던시가 있는 경우, 상위 계층에 속하는 모듈에서 하위 계층에 속하는 모듈의 함수 참조가 가능하도록 하위 계층에 속하는 모듈의 클래스를 인터페이스 클래스(Interface class)로 구현 할 수 있다. 인터페이스 클래스만 있는 'classes.zip'을 생성하는 것이다.
이와 같이, 구현체(implementation)와 인터페이스를 분리함으로써 디펜던 시(dependency)가 있는 모듈의 컴파일이 가능하도록 지원한다. 실제 구현은 구현체에서 이루어지되 인터페이스 클래스를 이용하여 라이브러리 모듈을 컴파일하는 것이다. 예를 들어, 인터페이스 클래스인 'wec.extdm.*'과 실제 구현되는 'wec.extdm.*'으로 구분하고, 실제 구현은 'wec.extdm.*'에서 이루어지고 'wec.extdm.*'는 플랫폼 라이브러리 모듈을 컴파일하기 위해서만 사용하는 것이다. 또한, C 모듈의 함수를 외부에 제공하기 위해서는 각 함수의 포인트들을 멤버로 갖는 구조체를 만들어 그 구조체의 포인트를 외부에서 획득할 수 있도록 출력 헤더 파일(export header file)을 제공한다.
한편, 모바일 플랫폼은 단말 사양 별로 선별적으로 기능 탑재가 이루어지도록 프로파일(profile) 기능을 제공한다. 따라서, 프로파일 단위로 패키징해서 모바일 플랫폼이 배포된다. 이때, 최소 프로파일은 한국무선인터넷 표준화 포럼(KWISF: Korea Wireless Internet Standardization Forum) 표준 규격을 준수한다.
도 5는 본 발명의 실시예에 따른 모바일 플랫폼의 프로파일 기능을 나타낸다.
도 5에 따르면, 모바일 플랫폼을 구성하는 각 기능들(201, 203, 205, 207, 209, 211)을 조합하여 프로파일을 정의한다.
예를 들어, 프로파일 A(213)는 File 기능(205), Display 기능(207), Network 기능(209) 등으로 구성된다. 또한, 프로파일 B(215)는 LBS 기능(201), ADX 기능(203), File 기능(205), Display 기능(207), Network 기능(209) 등으로 구성된다. 또한, 프로파일 C(217)는 File 기능(205), Display 기능(207), Network 기 능(209), Popup 기능(211) 등으로 구성된다.
<프로파일 정의 실시예>
이때, 모바일 플랫폼의 프로파일은 다음과 같은 분류 기준에 따라 정의될 수 있다. 일실시예에 따르면, 6 가지의 프로파일이 정의된다. 프로파일 1은 KWISF 표준 기능을 만족하고 A 통신 사업자의 서비스가 가능하기 위한 기본 모듈들이 탑재하며, 표 1과 같이 구성될 수 있다.
모듈 설명
App 어플리케이션 관리
App base 어플리케이션 base class
memory 공유 메모리
cldc Java 표준 API
lcdui 화면 제어
ui component UI component class
graphic_api Graphic API
graphic 그래픽 엔진
hwprofile 하드웨어 프로파일
dom xml parser
database 데이터 베이스
network 네트워크
Media 매체 처리기 기능 지원
storage File 시스템 관련 기능
Font 폰트 지원
handset 단말 기능
App managing Application Managing
oem OEM S/W 제어
utility 유틸리티
MIDP Java 표준 API
또한, 프로파일 2는 특정 어플리케이션 서비스를 위한 모듈들을 탑재하며 다음 표 2와 같이 구성될 수 있다.
모듈 설명
pims 주소록
theme 테마
drm DRM 관련 기능 지원을 위한 모듈
idle 대기화면 어플리케이션 관리
또한, 프로파일 3은 단말 디바이스를 통한 A 통신 사업자 서비스를 가능하게 하기 위한 모듈들이 탑재하며, 표 3과 같이 구성될 수 있다.
모듈 설명
gio Generic I/O 기능 지원을 위한 모듈
kmerce KMerce 기능 지원을 위한 모듈
gps GPS 기능 지원을 위한 모듈
또한, 프로파일 4는 단말 LCD(Liquid Crystal Display)에 특화된 서비스를 위한 모듈들이 탑재하며, 표 4와 같이 구성될 수 있다.
모듈 설명
swip 문자열 입력기 지원을 위한 모듈
oempad OEM PAD 기능 지원을 위한 모듈
또한, 프로파일 5는 3D, 플러그인(PlugIn), DMB(Digital multimedia Broadcasting) 서비스를 위한 모듈들이 탑재하며, 표 5와 같이 구성될 수 있다.
모듈 설명
adx ADX 기능 지원을 위한 모듈
opengl OpenGL ES 기능을 제공하기 위한 모듈
또한, 프로파일 6은 기타 A 통신 사업자 서비스를 위한 모듈들이 탑재하며, 표 6과 같이 구성될 수 있다.
모듈 설명
ga Generic Architecture 기능 지원을 위한 모듈
fmem 내부 추가 Flash 메모리 지원을 위한 모듈
bio 단말의 지문 인식 장치 지원을 위한 모듈
eif External Interface 기능 지원을 위한 모듈
위 표들에서 왼쪽 항목은 모듈 이름을 나타내고, 오른쪽 항목은 각 모듈의 기능에 관한 설명이다.
이제, 도 6을 참조하여 이상 설명한 기능 별로 구조화되고 프로파일 분류 기준에 따라 프로파일 형태로 제공되는 모바일 플랫폼의 구성에 대해 설명한다.
도 6은 본 발명의 실시예에 따른 모바일 플랫폼의 구성도이다.
도 6에 보인 바와 같이, 이동통신 단말에 탑재되는 모바일 플랫폼은 EFS 바이너리(Embeded File System Binaries)(301), ROM 바이너리(303), APM(Application Performance Management) 모듈(305), API(Application Programming Interface) 계층 모듈(311), 시스템 계층 모듈(323), 커널 계층 모듈(331) 및 OEM(Original Equipment Manufacturer) 계층 모듈(341)을 포함한다.
모바일 플랫폼 위에서 동작하는 응용 프로그램 파일들은 EFS 바이너리(301) 및 롬 바이너리(ROM Binary)(303)에 포함된다.
EFS 바이너리(Embeded File System Binaries)(301)는 사용자 접근이 용이한 코드 영역으로서, 이동통신 단말에 기본적인 어플리케이션 프로그램을 저장한다. 단문메시지, 사진, 벨소리, 게임 등 사용자 접근이 용이한 코드 영역이다. 이동통신 단말기에서 다양한 서비스를 제공하기 위해서는, 이동통신단말기에 기본적인 어플리케이션 프로그램을 저장한다. 또한, 사전에 사업자와 개발자등 협의에 의해 설정되는 사이즈를 가지는 영역으로 파일 시스템 형식을 취하는 메모리의 한 영역이다.
ROM 바이너리(303)는 이동통신 단말의 동작에 핵심적인 기능을 담당하는 운영체제(OS) 및 필수 어플리케이션(Application)들이 저장되는 사용자 접근이 제한되는 코드(Code) 영역이다. OEM 계층 모듈(341)의 플랫폼 액티베이터(Activator)(345)는 ROM 바이너리(303)에 정적으로 링크된다.
어플리케이션 수행 관리(Application Performance Management, 이하 'APM'으로 통칭함) 모듈(305)은 어플리케이션 1, 2(307, 309)의 다운로드, 등록, 저장, 삭제 등을 제어하고 관련 API 및 컴포넌트들의 추가, 갱신을 제어한다. 어플리케이션 1, 2(307, 309)은 이메일, 위치 기반, 게임들, 캐릭터 벨, 비디오 스트리밍, MMS(Multimedia Message Service) 등의 모바일 플랫폼 기반위에서 동작하는 다양한 서비스 어플리케이션들이다.
API(Application Programming Interface) 계층 모듈(311)은 어플리케이션 1, 2(307, 309)의 실행을 위한 API 함수를 포함하며, 각각의 모듈들을 포함한다. 각각의 모듈은 Display 모듈(313), Network 모듈(315), Handset 모듈(317), Termres 모듈(319) 및 File 모듈(321) 등을 포함할 수 있다.
이때, API 계층 모듈(311)은 어플리케이션 1, 2(307, 309)이 운영체제에 특정 처리를 위해 호출할 수 있는 함수의 집합으로서, 핸드셋 하드웨어를 제어하는 API 및 어플리케이션 1, 2(307, 309)에서 실질적으로 사용되는 API 들을 포함한다.
시스템 계층 모듈(323)은 CDMA 망에서는 Rex OS를 지칭하는 것으로 간단한 단말기 운영체제 기능과 통신 기능 및 각종 디바이스 드라이버가 포함된다. 네트워크, IO(Input/Output), 미디어 등 모바일 플랫폼의 중추적 기능을 담당하며 API 기능을 수행하는 시스템 모듈(325) 및 File 모듈(327)을 포함한다. 여기서, 시스템 모듈(325)은 모바일 플랫폼이 제공하는 HAL(Hardware Adaptation Layer) API(329)를 관리한다.
커널 계층 모듈(331)은 모바일 플랫폼의 전체 실행 과정에서 가장 핵심적인 연산이 이루어지는 부분으로서, 메모리에 상주하여 프로세스, 메모리를 관리하고 이동통신 단말기의 장치들을 제어하고 입출력을 처리한다.
커널 계층 모듈(331)은 모바일 플랫폼에서 기본이 되는 필수 기능들을 각각 모듈로 구현하여 하나의 독립된 계층으로 구성한다. 커널 계층 모듈(331)은 예를 들어, Memory Manager, Thread Manager, Timer, Class Loader 등과 같은 기본 기능들을 제공한다.
커널 계층 모듈(331)은 커널 모듈(333) 및 모듈 매니저(337)를 포함한다. 이때, 커널 모듈(333)은 모바일 플랫폼이 제공하는 HAL API(335)를 관리하며, 후술할 도 7의 각 모듈 중 하나를 지칭할 수 있다.
또한, 모듈 매니저(337)는 모바일 플랫폼을 구성하는 각 기능별 모듈의 로드(load), 언로드(unload) 등 라이프 사이클(life cycle)을 관리하는 모바일 플랫폼 커널 모듈이다. 모듈 매니저(337)는 HAL 인터페이스(339)를 포함한다. HAL 인터페이스(339)는 모바일 플랫폼과 OEM이 정적(static)으로 링크되지 않는 구조에서 모바일 플랫폼이 OEM이 제공하는 HAL API를 호출할 수 있도록 하기 위한 메모리 상의 자료 구조를 의미한다.
OEM(Original Equipment Manufacturer) 계층 모듈(341)은 플랫폼 이식에 있어서 하드웨어 독립성을 지원할 수 있도록 하는 추상화 계층인 핸드셋 적용 계층(HAL) 모듈(343) 및 플랫폼 액티베이터(Activator)(345)를 포함한다.
여기서, HAL 모듈(343)은 모바일 플랫폼의 하드웨어 독립성을 유지하기 위한 추상화 계층으로, 상위 계층들이 HAL 모듈(343) 위에서 시스템 계층 모듈(323)과 무관하게 동작하도록 지원한다. HAL은 단말기 제조사를 위한 API를 정의한 것으로 단말기 제조사마다 서로 다른 기기들을 지원하기 위해 HAL이라고 하는 추상화 계층을 도입한다. 그리고 이 HAL이 단말기에 포팅되면 바로 모바일 플랫폼 실행 엔진을 탑재할 수 있다. 즉 데스크탑 윈도우즈 환경에서는 HAL을 WIN 32에 맞게 포팅하면 에뮬레이터가 바로 되는 것이다.
또한, 플랫폼 액티베이터(345)는 이동통신 단말에 탑재되는 WIPI(Wireless Internet Platform for Interoperability) 실행 바이너리이다. 플랫폼 액티베이터(345)는 운영체제(OS, Oriented System)와의 이벤트 교류 및 모바일 플랫폼이 제공하는 HAL이 위치하는 곳이며 OS가 제공하는 바이너리 포맷으로 구성된다. 또한, 모듈 매니저(337)를 로딩하는 역할을 수행한다. 그리고 커널 계층 모듈(331)과 통신하기 위한 HAL 인터페이스(347)를 제공한다.
이와 같이 구성된 모바일 플랫폼의 동작에 대해 설명한다. 모바일 플랫폼의 동작은 단말 부팅시 플랫폼 구동 흐름과, 어플리케이션 API 호출 흐름/HAL 호출 흐름, OEM에서 플랫폼 제공 HAL API 호출 흐름으로 이루어진다. 이때, 아래 반괄호 순번은 도면에 표시된 순번과 일치하며, 도면에서는 각 모듈 간의 통신을 순번이 매겨진 화살표로 나타낸다.
1) 이동통신 단말의 부팅시 OEM 계층 모듈(341)이 플랫폼 액티베이터(345)에게 모바일 플랫폼의 구동을 요청한다.
2) 플랫폼 액티베이터(345)는 모듈 매니저(337)를 로딩하고 HAL 인터페이스(347) 포인터를 전달한다.
3) 로딩된 모듈 매니저(337)는 OEM이 제공하는 HAL 인터페이스(347) 포인터를 통해 필요한 기본 HAL API를 검색(look up) 한다.
4) 모듈 매니저(337)는 모바일 플랫폼 동작에 필요한 기본 모듈들을 로딩하고 모바일 플랫폼을 초기화한다.
5) 모듈 매니저(337)는 APM 모듈(305)을 구동시켜 단말 부팅 작업을 완료한다.
6) 어플리케이션 2(309)이 구동되고 어플리케이션 2(309)는 모바일 플랫폼이 제공하는 API를 호출한다. 예를 들어, File API가 호출된다.
7) 이때, 해당되는 API 기능이 작동하는 시스템 계층 모듈(323)의 기능 모듈이 호출된다. 예를 들어, File 모듈(321)이 호출된다. 만약, 시스템 계층 모듈(323)의 기능 모듈이 로딩되어 있지 않은 경우 모듈 매니저(337)가 기능 모듈을 로딩한다.
8) 시스템 계층 모듈(323)의 File 모듈(321)은 모듈 매니저(337)에게 HAL API 호출을 요청한다.
9) 모듈 매니저(337)는 3)에서 검색한 HAL API를 호출한다.
10) OEM 계층 모듈(341)의 플랫폼 액티베이터(345)는 모바일 플랫폼과의 연동 기능 수행을 위해 모바일 플랫폼이 제공하는 HAL API를 호출한다. 모바일 플랫폼이 제공하는 HAL API Wrapper를 플랫폼 액티베이터(345)가 구현한다.
11) 플랫폼 액티베이터(345)는 모듈 매니저(337)를 통해 플랫폼 제공 HAL API를 호출하여 기능을 수행한다.
이제, 모바일 플랫폼을 구성하는 모듈 중 커널 계층 모듈(331)의 세부적인 구조에 대해 살펴보기로 한다.
<제2 실시예>
표 7은 모바일 플랫폼 커널의 기능을 나타낸다. 아래 표에서 왼쪽 항목은 세부적으로 분류된 모바일 플랫폼의 커널 기능을 나타내고, 오른쪽 항목은 각각의 기능이 수행하는 동작에 관한 설명이다.
기능 설명
Monitor Manager 쓰레드 동기화나 Mutex 객체를 관리하는 기능. 클래스 로딩 과정이 동시에 발생할 수 있는 critical section 구간에서 Mutex 생성 및 소멸을 관리하고 쓰레드 간 동기화를 지원하기 위해 사용된다.
Timer Manager 플랫폼에서 생성하는 timer 정보 및 Timer life cycle을 관리한다. Timer는 Thread 및 Monitor 등에서 참조하여 사용된다.
Thread Manager 어플리케이션 로딩을 위해 필요한 Main Thread 관리, 어플리케이션에서 생성하는 Thread 정보의 관리 및 Thread life cycle을 관리한다.
Class Loader 플랫폼 Java 시스템 클래스 및 Java로 구성되는 어플리케이션의 클래스 정보를 관리하고 어플리케이션에서 사용하게 되는 클래스의 loading, resolving, initializing 작업을 수행한다.
Heap Manager 플랫폼이 생성하는 메모리를 관리한다. 구동되는 어플리케이션을 위한 어플리케이션 메모리의 할당, 해제를 관리하고 구성된 메모리 내에서 발생하는 garbage collection, object space, permanent space 등을 관리한다.
Event Handler 플랫폼에서 어플리케이션 간 발생하는 이벤트, 플랫폼과 어플리케이션 간 발생하는 이벤트, 플랫폼과 OEM간 발생하는 이벤트 정보를 관리하고 이벤트를 처리하는 역할을 수행한다.
Module Manager 플랫폼에서 정의하는 모듈 규격에 의해 등록되는 Native 모듈 정보를 관리하고 모듈의 life cycle을 관리한다.
Jar Handler Java archive 파일의 파싱을 통한 어플리케이션 바이너리 정보 획득, jar 압축 해제 등 어플리케이션 실행과 관련한 Jar 파일을 관리한다.
AOTC Manager COD를 통해 빌드된 어플리케이션이 로드되어 호출하는 각종 함수들을 관리한다. 어플리케이션 OpCode를 수행하는데 있어 요구되는 플랫폼 클래스 획득, 메소드 호출, 필드 획득 등의 작업을 수행하고 이를 위한 Java Stack 관리, VM OpCode 기능 수행 등의 작업을 처리한다.
Exception Handler Java 어플리케이션에서 발생하는 Exception을 관리한다.
Resource Manager 어플리케이션에서 제어하는 파일 리소스에 대한 정보를 관리한다.
App Loader 어플리케이션 바이너리를 분석하여 어플리케이션 구동을 위한 시작 함수를 구성함으로써 어플리케이션을 로딩하는 역할을 수행한다. 또한 어플리케이션의 구동 정보를 관리하고 구동되는 어플리케이션의 life cycle을 관리한다.
Graphic Engine 점, 선, 다각형 등의 도형 연산, 이미지 디코딩 그리고 LCD 출력을 담당하는 Graphic 관련 기능을 담당한다. (Native Layer로 변경 예정)
이와 같이 구성된 모바일 플랫폼 커널을 각 기능들의 구조적 특징을 모듈화할 수 있는 단위로 정의 및 분류하여 도 7에 보인 바와 같이, 크게 네 개의 모듈로 구성한다.
도 7은 본 발명의 실시예에 따른 커널 계층 모듈의 구조를 나타낸다.
도 7에 보인 바와 같이, 커널 계층 모듈(331)은 코어 모듈(349), 쓰레드 모듈(351), 모듈 매니저(337) 및 타겟 모듈(353)을 포함한다.
코어 모듈(349)은 모바일 플랫폼 고유의 기능을 수행한다. 코어 모듈(349)은 표 7의 기능 중에서 AOTC Manager, Monitor Manager, Timer Manager, Class Loader, Heap Manager, Event Handler, Exception Handler, Resource Manager, App Loader를 포함한다.
쓰레드 모듈(351)은 이동통신 단말에 탑재되는 운영체제(O/S)가 지원하는 쓰레드(Thread)를 활용하기 위해 지정된다. 쓰레드 모듈(351)은 표 7의 기능 중에서 Thread Manager를 포함한다.
모듈 매니저(337)는 모듈화된 플랫폼 커널 및 하위 레이어의 모듈을 관리하며, 이동통신 단말에 설치된 모바일 플랫폼의 모듈 정보를 관리하고 로딩되는 모듈의 라이프 사이클을 관리한다. 모듈 매니저(337)는 표 7의 기능 중에서 Module Manager를 포함한다.
타겟 모듈(353)은 이동통신 단말의 CPU(Central Processing Unit)에 따라 코드를 달리해야 하는 커널 기능을 만족시키기 위해 지정된다. 즉 코어 모듈(349)을 구성하는 모듈 중 단말 하드웨어(H/W)에 따라 구성을 달리해야 하는 코드 정보를 포함한다. 표 7의 기능 중에서 App Loader, AOTC Manager 일부분이 타겟 모듈(353)로 구성된다.
타겟 모듈(353)은 'MContext.c' 함수, 'MDepAppLoad.c' 함수 및 'MSmartAot.c(s)' 함수를 포함한다.
여기서, 'MContext.c' 함수는 Thread 간 문맥 전환(context switching), 어플리케이션 Java 코드에서 호출하는 Native 코드 호출 및 이를 위한 Java Stack과 C Stack 간 변환 기능을 담당한다. 'MDepAppLoad.c' 함수는 어플리케이션 바이너리의 entry를 찾아 바이너리를 메모리에 로딩하는 기능을 수행한다. 'MSmartAot.c(s)' 함수는 어플리케이션 혹은 플랫폼 Java 코드에서 호출하는 Native 코드 호출을 한다. 그리고 이를 위한 Java Stack과 C Stack 간 변환 기능을 담당하며 Java VM 규격에 명시되어 있는 invokeVirtual, invokeSpecial, invokeInterface 등의 함수 호출 기능을 담당한다. 타겟 모듈(353)에서 지원하는 어셈블리(assembly) 양식에 맞게 구현되어 있다.
이때, 커널 계층 모듈(331)의 각 모듈(349, 351, 337, 353) 간에는 상호 디펜던시(Dependency)가 없어야 한다. 상호 디펜던시가 존재하는 경우는 다음 네가지가 있다.
1. 쓰레드 모듈(351)에 존재하는 함수, 전역 변수를 코어 모듈(349)에서 사용하는 경우
2. 쓰레드 모듈(351)에 존재하는 함수, 전역 변수를 타겟 모듈(353)에서 사용하는 경우
3. 코어 모듈(349)에 존재하는 함수, 전역 변수를 쓰레드 모듈(351)에서 사용하는 경우
4. 코어 모듈(349)에 존재하는 함수, 전역 변수를 타겟 모듈(353)에서 사용하는 경우
위의 네가지 경우, 함수 및 전역 변수를 각 모듈에서 인터페이스(<<interface>>)로 분리한다.
구체적으로, 상호 디펜던시를 제거하기 위해 각 모듈(349, 351, 337, 353)에 존재하는 C 전역 변수를 인터페이스(<<interface>>)화한다. 즉 쓰레드 모듈(351)에서 정의하고 선언하는 전역 변수 및 코어 모듈(349)의 각 기능에서 정의하고 선언하는 전역 변수를 각 모듈(349, 351, 337, 353)이 제공하는 인터페이스 규격으로 변경한다. 그리고 인터페이스 목록을 포함하는 헤더를 타 모듈에게 제공한다.
또한, 상호 디펜던시를 제거하기 위해 모듈 함수를 인터페이스화한다. 즉 쓰레드 모듈(351)에서 정의하고 선언하는 함수, 코어 모듈(349)의 각 기능에서 정의하고 선언하는 함수들을 각 모듈(349, 351, 337, 353)이 제공하는 인터페이스 규격으로 변경한다. 그리고 인터페이스 목록을 포함하는 헤더를 타 모듈에게 제공한다. 이때, 모듈이 제공하는 인터페이스 규격은 커널 계층 모듈(331)뿐만 아니라 시스템 계층 모듈(323)에서도 사용할 수 있다.
각 모듈(349, 351, 337, 353) 간에 출력(export) 인터페이스를 통해 함수 호출이 이루어진다. 각 모듈(349, 351, 337, 353)에서 각각 사용하는 다른 모듈의 자원에 대해 파악하여 각 모듈에 포함되는 기능을 분류한다. 그리고 분류된 기능에서 출력할 함수 및 변수를 분류하여 인터페이스(<<interface>>)로 제공한다.
표 8과 표 9는 각각 코어 모듈(349) 및 쓰레드 모듈(351)이 제공하는 인터페이스 목록을 나타낸다.
모듈 인터페이스 설명
Class Loader getOutOfMemoryErrorObj OutOfMemoryError 예외를 처리한다.
getJavaClass Java Object 를 반환한다.
sysLoadClass Java Object 를 반환한다. (시스템 클래스)
App Loader MV_programExec 어플리케이션을 실행한다.
MV_appDLLLoad DLL 로딩한다.
MV_programStop 어플리케이션을 종료한다.
MV_prgGetResource Jar에 포함되어 있는 어플리케이션 리소스를 반환한다.
MV_prgFindJarEntry Jar 파일에 포함되어 있는 entry 의 시작점을 반환한다.
MV_prgGetAccessLevel 보안 레벨을 체크한다.
MV_prgIsPlugin 어플리케이션이 플러그인인지의 여부를 반환한다.
MV_prgGetCurProgramID 현재 active한 메인 쓰레드를 소유한 프로그램 아이디를 반환한다.
MV_prgGetParentProgramID 특정 프로그램의 부모 프로그램을 반환한다.
MV_prgGetProgramType 특정 프로그램의 어플리케이션 type을 반환한다.
MV_prgGetProgramName 특정 프로그램의 이름을 반환한다.
MV_prgIsValidProgramID 특정 프로그램이 유효한 프로그램인지를 반환한다.
MV_prgGetAppManagerID APM의 프로그램 아이디를 반환한다.
MV_prgIsBackground 특정 프로그램이 background 어플리케이션인지의 여부를 반환한다.
MV_prgGetcurPrgFreeIdx Program Pool의 비어있는 Pool 인덱스를 반환한다.
MV_prgGetProgramCount 구동되어 있는 프로그램의 개수를 반환한다.
MV_prgGetProgram 구동되어 있는 특정 프로그램 구조체를 반환한다.
MN_prgGetAppID 특정 어플리케이션의 아이디를 반환한다.
MNI_registerAppContextCallBack WIPI C 어플리케이션이 등록하는 callback 함수를 등록한다.
Timer MNI_defTimer Timer를 정의한다.
MNI_setTimer Timer를 설정한다.
MNI_unsetTimer Timer를 소멸한다.
Event Handler MNI_registerEventHandler 이벤트를 처리하는 Handler를 등록한다.
MNI_registerLongEventHandler 시스템 Long 이벤트를 처리하는 Handler를 등록한다.
MN_putEvent 전달할 이벤트 정보를 이벤트 큐에 넣는다.
MN_postEvent 이벤트를 전달한다.
MN_postEventAtQTop 이벤트 큐의 Top에 있는 이벤트를 전달한다.
MN_postEvent5 이벤트를 전달한다. (데이터 전달 가능)
Resource Manager allocResDescriptor 리소스 Descriptor를 할당한다.
freeResDescriptor 할당한 리소스 Descriptor를 해제한다.
dirAccessCheck 디렉토리 접근 권한 여부를 반환한다.
isDrmResource DRM 리소스 여부를 반환한다.
moduleAccessCheck 보안 레벨을 체크한다.
Util MN_LIST_CREATE Linked list를 생성한다.
MN_LIST_DESTROY Linked list를 종료시킨다.
MN_LIST_GCMARK Linked list를 garbage collection에서 제외한다.
Heap Manager


 MNI_newObjectWithDefaultHeap Default heap에 메모리를 할당한다.
MNI_newArrayObjectWithDefaultHeap Default heap에 메모리를 할당한다. (배열)
인터페이스 설명
mvm_threadActiveCount 생성된 쓰레드 중 resume 상태의 쓰레드 개수
currentThread 현재 활동 중인 쓰레드
vmEvent 처리해야 할 이벤트가 존재하는지의 여부
mvm_aliveList 생성된 쓰레드의 집합체
gthread_create 쓰레드를 생성하는 인터페이스
gthread_yield 쓰레드를 잠시 suspend 시켜 다른 쓰레드가 작동하도록 하는 인터페이스
gthread_sleep 특정 시간 동안 쓰레드를 suspend 시키는 인터페이스
gthread_suspend 쓰레드를 suspend 시키는 인터페이스
gthread_suspendTimeout 쓰레드를 특정 시간 동안 suspend 시키는 인터페이스
gthread_resume 쓰레드를 resume 시키는 인터페이스
gthread_resumeToSchedule 쓰레드를 resume 시키는 인터페이스
gthread_setPriority 쓰레드의 우선 순위를 설정하는 인터페이스
gthread_exit 쓰레드를 destroy 시키는 인터페이스
gthread_isWakeupTimeout 쓰레드가 일정 시간이 지난 후 깨어나도록 설정되어 있는지의 여부를 반환하는 인터페이스
gthread_setAlarm 쓰레드가 일정 시간이 지난 후에 깨어나도록 Timer를 설정하는 인터페이스
gthread_unsetAlarm gthread_setAlarm에 의해 설정된 Timer를 해제하는 인터페이스
vmEventProcessing 처리해야 할 이벤트가 있는지 체크하고 이벤트를 처리하는 인터페이스
또한, 타겟 모듈(353)에 포함될 커널 계층 모듈(331)의 기능을 분류하여 각 기능에서 출력할 함수 및 변수를 분류하여 인터페이스(<<interface>>)로 제공한다. 타겟 모듈(353)에 포함되어 있는 어셈블리 코드를 인터페이스(<<interface>>)로 분리한다.
이때, 하드웨어 디펜던시(Hardware dependency)가 있는 모바일 플랫폼 기능들을 논리적인 하나의 모듈 즉 타겟 모듈(353)로 구성한다. 여기서, 하드웨어 디펜던시가 있는 즉 H/W 의존적인 코드가 있는 모바일 플랫폼 기능은 다음과 같다.
1. Java VM 규격에 명시된 'invokevirtual', 'invokespecial', 'invokeinterface' 등의 메소드 호출을 C 코드로 처리함에 있어 다양한 유형의 함수 프로토 타입을 지원하기 위한 코어 인터페이스
2. Java VM 규격에 명시된 'Java Stack Frame'의 기능
3. AOTC 결과물인 머신 코드 형태의 어플리케이션 로더
이러한 모바일 플랫폼 기능들을 단말의 칩셋(chipset) 별로 구분하여 관리하여 이동통신 단말의 종류에 따라 원하는 모듈로 대체 가능하도록 한다.
또한, 상호 디펜던시를 제거하기 위해 모듈 내부 함수를 은닉화한다. 즉 정형화된 모듈화를 위해 각 모듈(349, 351, 337, 353) 내부적으로 사용하는 함수, 변수들의 은닉화를 진행한다. 따라서 타 모듈에서 'extern'을 통한 내부 변수, 내부 함수의 참조가 이루어지지 않도록 한다. 이때, 'extern'은 다른 파일에서 선언된 전역 변수에 대해 링크(link)시키는 기능을 수행한다.
한편, 커널 계층 모듈(331)에서 하위 시스템 계층 모듈(323)의 함수, 전역 변수를 호출하여 사용하는 디펜던시가 존재한다. 디펜던시가 존재하는 항목 및 디펜던시를 제거하기 위한 구성은 다음과 같다.
1. 시스템 계층 모듈(323)에 존재하는 'printk' 함수를 사용하는 경우: 커널 계층 모듈(331)의 대다수 모듈은 시스템 계층 모듈(323)에 포함되어 있는 로그 출력 함수인 'printk' 함수를 호출한다. 따라서, 'printk' 함수를 포함하는 'MNPrintk.c'를 커널 계층 모듈(331)에 포함시킨다.
2. 하드웨어 프로파일 모듈을 사용하는 경우: 모바일 플랫폼 자체가 물리적인 바이너리로 구분되어 모듈을 구성하는 구조이기 때문에 하드웨어 프로파일(Hardware Profile)에 지정되는 'ext Modules DTD(Data Type Definition)'는 더 이상 사용하지 않는다. 따라서 커널 계층 모듈(331)의 모듈 매니저(337)에서는 하드웨어 프로파일 기능 함수를 호출하지 않도록 변경한다.
3. 'Exception' 처리 모듈을 사용하는 경우: 현재 커널 계층 모듈(331)에서 호출하는 'Java Exception' 처리 함수가 시스템 계층 모듈(323)의 코드로 구성되어 있다. 'Java Exception' 처리 함수의 코드에서 'softCPU_athrow' 함수는 Excepiton Handler 기능(표 7)에 존재하며 'vmEventCheckForExit' 함수는 AOTC Manager 기능(표 7)에 존재한다. 따라서 'Java Exception' 처리 함수를 코어 모듈(349)의 'Exception Handler' 기능에 추가하고 커널 계층 모듈(331)에서는 추가된 함수를 호출하도록 변경한다.
4. 'DRM File' 처리 모듈을 사용하는 경우: 'DRM File' 처리를 위한 함수의 포인터를 커널 계층 모듈(331)에 전달하여 사용하도록 수정한다.
5. 플랫폼 환경 설정 파일 처리 모듈을 사용하는 경우: 플랫폼 환경 설정 파일 처리를 위한 함수의 포인터를 커널 계층 모듈(331)에 전달하여 사용하도록 수정한다.
또한, 커널 계층 모듈(331)에 포함되어 있는 그래픽(Graphic) 엔진 코드를 분리하여 그래픽 모듈 형태로 시스템 계층 모듈(323)에 포함시킨다. 이때, 종래에 플랫폼 구동 시점에 수행하였던, 그래픽 엔진의 초기화 처리는 그래픽 모듈이 로딩 되는 시점에 초기화를 진행한다.
따라서, 그래픽 엔진에서 참조하는 커널 기능의 함수, 전역 변수 등을 커널 계층 모듈(331)에서 출력 인터페이스로 구성한다. 그리고 그래픽 엔진에서는 구성된 인터페이스를 입력(import)하여 사용할 수 있도록 변경한다.
아래 표 10은 그래픽 엔진에서 사용하는 커널 인터페이스 함수 목록이다. 표10에 언급된 커널 함수들은 표 8의 코어 모듈에 인터페이스로 정의되어 있으므로, 사용법은 표 8에 포함된 내용과 동일하다.
그래픽 엔진 모듈 사용하는 Kernel 함수
MGImages.c MNI_newArrayObject
MGPolyUtl.c MV_pAlloc
MGraphic.c MV_hpCallocPermSpaceWithPrg
MV_utilGetAvailableUserContextID
MV_utilAllocUserContext
MV_prgSetDispContextID
MNI_defTimer
MV_utilFindUserContext
MNI_unsetTimer
MV_utilFreeUserContext
MDcdBMP.c
MDcdGIF.c
MDcdJPEG.c
MDcdNBMP.c
MDcdSIS.c
MDcdWBMP.c		 MNI_getPSpaceBase
MNI_setRewindPSpace
MV_pCalloc
MDcdPNG.c MNI_gcMarkObject
MNI_newArrayObject
MNI_getPSpaceBase
MNI_setRewindPSpace
MV_pCalloc
또한, 그래픽 모듈이 제공하는 기능은 기능적으로 분류하여, 별도의 인터페이스 이름을 부여하여 모바일 플랫폼의 다른 모듈에서 사용이 가능하도록 인터페이스들을 출력한다. 이러한 인터페이스들의 목록은 아래 표 11과 같다.
모듈(기능) 명 기능 내용 인터페이스 이름
Image Processing 이미지 디코딩, 알파값 처리 등의 이미지 processing을 처리한다. wipi_grpimages
Drawing Engine Line, rect, polygon 등의 Drawing에 관련된 처리를 수행한다. wipi_grpdraw
LCD Frame Buffer 처리 Engine WIPI frame buffer에 drawing하기 위한 기능을 수행한다. wipi_fblcd
WIPI-C Graphic 기능 MC_grpSetContext 등의 WIPI-C Graphic API에 대한 기능을 제공한다. WIPIC_graphicInterface
WIPI-C UI Control 기능 WIPI C UI Control 기능을 제공한다. WIPIC_uicInterface
WIPI-C Input Method 기능 WIPI C input method와 관련된 기능을 제공한다. WIPIC_imInterface
기타 Graphic
정보 조회 기능		 WIPI runtime에서 관리되는 graphic 정보들에 대한 조회 기능을 제공한다. mgraphic
또한, 그래픽 엔진의 일부인 'SIS 디코더'는 모바일 플랫폼 외부에 존재하는 솔루션이다. 'SIS 디코더'는 종래에는 ADS(Alternate Data Stream)로 컴파일된 라이브러리가 단말 바이너리에 정적으로 링크되는 구조로 이루어진다.
그런데 모바일 플랫폼에서 SIS 이미지 디코딩을 위해 'SIS 디코더'에서 제공하는 함수를 직접 호출하는 그래픽 엔진이 모듈화됨에 따라 'SIS 디코더' 역시 인터페이스를 두 가지 실시예로 구현할 수 있다.
하나의 실시예에 따르면, 'SIS 디코더'를 HAL 인터페이스로 제공하도록 변경한다. 즉 'SIS 디코더'는 HAL 모듈에 정적으로 링크하고, 'SIS 디코더'에서 제공하는 API는 HAL 인터페이스로 제공한다. 그리고 이 HAL 인터페이스를 그래픽 모듈에서 사용하도록 한다.
다른 실시예에 따르면, 'SIS 디코더'를 모바일 플랫폼의 모듈로서 구현한다. 이런 경우, 그래픽 모듈에서 'SIS 디코더'에 대한 인터페이스를 획득하여 그래픽 모듈이 SIS 이미지에 대한 디코딩이 가능하도록 한다. 'SIS 디코더'가 모듈로 제공되기 위해서 'SIS 디코더'는 WIPI API로 구현되어 ADS가 아닌 WIPI 컴파일러(Compiler, GCC)로 컴파일 되도록 한다. 그리고 제공하는 기능들을 모듈 인터페이스로 출력한다.
한편, 이동통신 단말은 대기화면 기능을 제공한다. 대기화면은 통화가 걸려오지 않는 동안에 디스플레이 장치에 전원이 공급되는 시점에는 항상 보여지는 화면이다. 본 발명의 제3 실시예에 따르면, 종래에 모바일 플랫폼의 APM 모듈(305)에 종속적인 기능으로 구현되던 대기화면 기능을 별개의 모듈로서 구현한다. 이와 같이, 대기화면 기능을 대기화면 제어 모듈로 분리함으로써 대기화면 서비스를 지원하지 않는 단말에서는 대기화면 제어 모듈을 탑재하지 않도록 하여 경량화된 모바일 플랫폼을 제공할 수 있다.
이하, 도 8 내지 도 15를 참조하여 대기화면 제어 모듈에 대해 설명한다.
<제3 실시예>
먼저, 도 8은 본 발명의 실시예에 따른 대기화면 제어 모듈의 구성을 나타낸다.
여기서, 대기화면 제어 모듈(355)은 대기화면 점유 기능을 관리하는 모듈로서, 모바일 플랫폼을 구성하는 하나의 모듈이다. 모바일 플랫폼은 대기화면 제어 모듈(355)을 통하여 대기화면 서비스를 구현한다.
도 8에 따르면, 대기화면 제어 모듈(355)은 매니저 모듈(357), 대기화면 관리 모듈(359), 모듈 인터페이스부(361) 및 플랫폼 인터페이스부(363)를 포함한다.
매니저 모듈(357)은 APM 모듈(305)과 대기화면 관리 모듈(359)간의 중간 매개체 역할을 하는 모듈로서, 대기화면 관리 모듈(359)의 동작을 제어한다.
매니저 모듈(357)은 APM 모듈(305)에게 요청받은 대기화면 어플리케이션 처리에 필요한 정보를 대기화면 관리 모듈(359)에게 요청하여 획득한다. 이와 같이 획득한 대기화면 어플리케이션 관련 정보를 매니저 모듈(357)이 APM 모듈(305) 및 시스템 어플리케이션과 같은 모바일 플랫폼의 다른 모듈에게 제공한다. 또한, 매니저 모듈(357)은 MTA(MIME Type Handler) 서비스를 관리한다.
대기화면 관리 모듈(359)은 대기화면 어플리케이션에 관한 제반 기능을 담당한다. 매니저 모듈(357)을 통해 요청되는 대기화면 설정 및/또는 해제, 이동통신 단말에 설치된 대기화면 어플리케이션 관리, 구동중인 대기화면 어플리케이션 관리, 멀티 팝업 관리 및 자동 스케줄링 등을 관리한다.
모듈 인터페이스부(361) 및 플랫폼 인터페이스부(363)는 매니저 모듈(357)과 대기화면 관리 모듈(359)간의 통신 인터페이스를 제공한다.
모듈 인터페이스부(361)는 대기화면 점유 기능을 제공하기 위해 대기화면 제어 모듈이 모바일 플랫폼에게 제공하는 규격을 만족한다. 매니저 모듈(357)이 대기화면 어플리케이션 처리를 위해 대기화면 어플리케이션의 상태 정보를 비롯한 대기화면 어플리케이션 관련 정보를 대기화면 관리 모듈(359)로부터 획득하기 위한 인터페이스이다. 즉 매니저 모듈(357)은 모듈 인터페이스부(361)를 호출하여 대기화면 관리 모듈(359)에게 대기화면 어플리케이션 관련 정보를 요청하여 획득한다.
모듈 인터페이스부(361)는 매니저 모듈(357)의 정보 요청 기능, 예를 들어 대기화면 설정 및/또는 해제, 대기화면 어플리케이션의 상태 정보 조회, 플랫폼 상태 정보 조회, 대기화면 설정 등을 포함하는 대기화면 어플리케이션 관련 정보 요청 기능을 인터페이스로 구현한다.
플랫폼 인터페이스부(363)는 대기화면 점유 기능을 제공하기 위해 모바일 플랫폼이 대기화면 제어 모듈(355)에게 제공하는 규격을 만족한다. 대기화면 관리 모듈(359)이 대기화면 어플리케이션 관리를 위해 모바일 플랫폼의 상태와 같은 다양한 모바일 플랫폼 정보를 획득하기 위한 인터페이스이다. 즉 대기화면 관리 모듈(359)이 대기화면 어플리케이션 관리를 위해 모바일 플랫폼과 연동하기 위한 인터페이스를 제공한다.
플랫폼 인터페이스부(363)는 대기화면 관리 모듈(359)이 플랫폼 상태 등의 정보 조회 또는 매니저 모듈(357)에 의해 요청받은 대기화면 설정 결과 등을 전달하기 위한 모바일 플랫폼에서 제공하는 인터페이스를 구현한다.
이때, 플랫폼 인터페이스부(363)는 'PopupScheduleInfo' 유틸리티를 제공하여 대기화면 관리 모듈(359)의 자동 스케줄링 관리 기능을 구현한다. 따라서, 대기화면 관리 모듈(359)은 대기화면 어플리케이션의 자동 스케줄링 설정 및/또는 해제시 'PopupShceduleInfo' 유틸리티를 통해 자동 스케줄링을 관리한다.
또한, 플랫폼 인터페이스부(363)는 구동된 대기화면 어플리케이션 관리를 위해 'PopupInfo' 유틸리티를 제공한다. 따라서, 대기화면 관리 모듈(359)은 대기화면 설정 시 'PopupInfo' 유틸리티를 통하여 구동 중인 대기화면 어플리케이션을 관리할 수 있다. 즉 대기화면 관리 모듈(359)은 대기화면 어플리케이션이 설정될 때마다 'PopupInfo class'를 생성하여 구동중인 대기화면 어플리케이션을 관리한다.
이러한 대기화면 제어 모듈(355)의 동작은 다음과 같이 이루어진다.
매니저 모듈(357)은 APM 모듈(305)이 대기화면 어플리케이션 처리를 요청하면 모듈 인터페이스부(361)를 호출한다. 매니저 모듈(357)은 모듈 인터페이스부(361)를 통해 대기화면 관리 모듈(359)에게 대기화면 어플리케이션 처리에 필요한 대기화면 어플리케이션 관련 정보를 요청하여 획득하고, 이를 APM 모듈(305)에게 제공한다. 대기화면 관리 모듈(359)은 플랫폼 인터페이스부(363)를 호출하여 매니저 모듈(357)에 의해 요청받은 대기화면 어플리케이션 처리에 필요한 모바일 플랫폼 정보를 획득한다. 대기화면 관리 모듈(359)은 대기화면 어플리케이션 처리 결과를 플랫폼 인터페이스부(363)를 통해 매니저 모듈(357)에게 제공한다.
다음, 도 9는 종래의 대기화면 어플리케이션 속성과 본 발명의 실시예에 따른 대기화면 어플리케이션 속성을 비교 설명하기 도면이다.
여기서, 도 9(a)는 종래의 대기화면 어플리케이션의 속성을 나타내고, 도 9(b)는 본 발명의 실시예에 따른 대기화면 어플리케이션의 속성을 나타낸다.
도 9(a)에 따르면, 종래의 대기화면 어플리케이션의 베이스 클래스인 'IdleJlet'은 일반 'Jlet'이 아닌 'PluginJlet'을 상속받는다. 또한, 'PluginJlet'은 일반 'Jlet'을 상속받는다. 즉 'IdleJlet'은 'Jlet'을 상속받은 'PluginJlet'을 상속받는 것이다. 이와 같이, 종래의 대기화면 어플리케이션은 'IdleJlet' 형태로 APM 모듈의 자(child)어플리케이션으로 작동한다. 따라서, 팝업과 일반 어플리케이션이 분리되어 플랫폼에서의 일관된 스케줄링이 이루어지지 않는다.
도 9(b)에 따르면, 본 발명의 실시예에 따른 대기화면 어플리케이션의 베이스 클래스인 'IdleJlet'은 일반 'Jlet'을 직접 상속받는다. 또한, 'IdleJlet'을 추가 확장하여 기존 'PluginJlet'의 속성을 포함하도록 한다. 즉 'IdleJlet'은 일반 'Jlet'의 속성뿐만 아니라 'PluginJlet' 속성도 가질 수 있도록 변경하여 하위 호환성이 보장되도록 한다.
이렇게 하면, 대기화면 어플리케이션은 더 이상 APM 모듈의 자식 어플리케이션으로 동작하지 않는다. 즉 대기화면 어플리케이션이 일반 어플리케이션과 같은 독립적인 어플리케이션 형태로 구동되므로, 플랫폼에서의 일관된 스케줄링이 가능하다. 또한, 'IdleJlet'이 가져야 하는 'PluginJlet' 고유의 속성을 그대로 유지한 상태로 대기 화면에 설정할 수 있다.
도 10은 종래 대기화면 어플리케이션의 스케줄링 관리와 본 발명의 실시예에 따른 대기화면 어플리케이션의 스케줄링 관리를 비교 설명하기 도면이다.
여기서, 도 10(a)는 종래 대기화면 어플리케이션의 스케줄링을 나타내고 도 10(b)는 본 발명의 실시예에 따른 대기화면 어플리케이션의 스케줄링 관리를 나타낸다. 이때, 도 10(a) 와 도 10(b)는 'Jlet' 형태의 일반 어플리케이션이 두 개(APP1, APP2) 구동되어 있고, 'IdleJlet' 형태의 대기화면 어플리케이션이 두 개(PopUp1, PopUp2) 구동되어 있다.
도 10(a)에 따르면, 일반 'Jlet' 형태의 어플리케이션의 경우 'Jlet' 생성시 APM 모듈에서 유지하고 있는 'AppScheduler'에 'Program Object Pools'를 생성한다. 즉 추후 WIPI 어플리케이션(MG) 및 OEM 어플리케이션(OEM Idle) 간의 스케쥴링에 포함되어 처리되도록 한다.
이때, 대기화면 어플리케이션의 경우 'Jlet' 생성시 'AppScheduler'에 추가되는 것이 아니라 부모 어플리케이션의 'Jlet'에서 관리하는 'Plets' 벡터(여기서, 'Plets'는 'PluginJlet'을 관리하는 배열임)에 추가되어 별도로 관리된다. 또한, 'IdleJlet'에서는 'PluginJlet'에서 상속받은 멤버변수 'parentsJlet'을 통해 APM 모듈의 'Jlet'을 가리키게 된다. 해당 처리의 구분은 APM 모듈에서 대기화면 어플리케이션 구동시 전달하는 파라미터중 'Plugin' 속성을 주게 됨으로 구분이 가능하다.
이와 같이, 대기화면 어플리케이션은 APM 모듈에서 관리하는 일반 어플리케이션 스케줄링에서 제외되고 'IdleJlet' 형태로 APM 모듈의 자식 어플리케이션으로 동작한다. 추후 대기화면 어플리케이션 처리 필요시 APM 모듈에서 직접 처리한다.
또한, 대기화면 해제 요청이 APM 모듈에게 올 경우 APM 모듈은 설정된 대기화면 어플리케이션을 종료한다. 그리고 그에 대한 'Child Stop'이 APM 모듈로 전달 되면 APM 모듈은 해당 어플리케이션이 스케쥴러에 존재 하지 않고 'Plugin' 속성임으로 APM 모듈의 자식 어플리케이션 배열에서 제거한다. 정상적으로 제거가 된 후 APM 모듈은 스케쥴링상 가장 우선순위에 있는 어플리케이션을 재시작(Resume)한다. 즉 종래의 대기화면 어플리케이션은 'Plugin' 속성을 통해 일반 어플리케이션과 구분이 되어 처리 방식을 일반 'Jlet' 형태의 어플리케이션과 다르게 처리한다.
또한, 팝업 어플리케이션이 대기화면에 설정된 경우에 OEM 어플리케이션 또는 브라우저를 통해 대기화면 설정이 요청된 경우 APM 모듈이 대기화면에 설정된 팝업 어플리케이션을 해제하여 해당 팝업이 모두 정상적으로 종료 된 이후에 대기화면을 설정한다.
도 10(b)에 따르면, 본 발명의 실시예에 따른 대기화면 어플리케이션은 'AppScheduler'에 추가되지 않고, 대기화면 관리 모듈에서 관리한다. 즉 도 10(a)에 보인 것처럼 APM 모듈의 'Jlet'의 Plets 배열에 추가 하지 않는다.
대기화면 어플리케이션이 일반 'Jlet' 형태로 대기화면 설정이 가능하다. 그러므로 대기화면 어플리케이션의 스케줄링은 APM 모듈에서의 일반 어플리케이션 스케쥴링에는 영향 없이 대기화면 어플리케이션 제어가 가능하도록 구성된다. 대기화면 어플리케이션은 WIPI 어플리케이션 또는 OEM 어플리케이션의 종료시 재시작(resume) 되는 경우는 존재하지 않으므로, APM 모듈에서 관리 하는 스케쥴링에서는 제외된다. 즉 APM 모듈의 'AppScheduler'에 추가되지 않는 것이다.
또한, APM 모듈의 스케쥴링상에서 대기화면이 처리되어야 하는 시점 예를 들어 'OEM Idle' 진입시 매니저 모듈은 대기화면 설정 상태를 대기화면 관리 모듈을 통해 조회한 후 처리해야 할 액션을 대기화면 관리 모듈에게 요청한다.
또한, APM 모듈은 대기화면 해제 처리후 바로 APM 모듈의 스케쥴링상 재시작 시킬 어플리케이션을 찾아 처리한다. 이는 'Child Stop' 이벤트 수신시 APM 모듈의 자식 어플리케이션 배열에서 제거하는 처리가 필요한 종래 구성과 차별된다. 또한, APM 모듈은 정상적으로 해제 되었음을 대기화면 관리 모듈에게 알려 대기화면 관리 모듈에서 대기화면 어플리케이션 관리를 할 수 있도록 한다.
또한, 매니저 모듈은 OEM으로부터 대기화면 설정 요청시 이미 대기화면에 설정된 팝업 어플리케이션이 존재하는지를 대기화면 관리 모듈에게 조회한다. 이후 대기화면이 설정이 된 경우 대기관리 모듈에게 대기화면 해제를 요청하고 정상적으로 해제가 된 이후에 APM 모듈이 대기화면 설정하도록 한다.
또한, 대기화면이 설정된 상태에서 팝업 매니저 또는 OEM에서 팝업 어플리케이션의 대기화면 설정을 요청하는 경우 매니저 모듈은 먼저 대기화면 설정 처리를 해제한 후 대기화면 관리 모듈에게 대기화면 설정을 요청하도록 한다.
도 11은 본 발명의 실시예에 따른 MG_Program 구조체의 구조를 나타낸다.
도 11에 따르면, APM 모듈의 MG_Program 구조체는 'Plugin' 속성은 그대로 제공한다. 여기서, 어플리케이션 구동시 모바일 플랫폼은 'MG_Rrogram 구조체에서 비어있는 요소를 하나씩 할당하여 각 어플리케이션의 특성에 맞는 값들을 설정한다.
또한, MG_Program 구조체에 'isIdleApp' 속성을 추가하여 대기화면 어플리케이션인 경우만 'True'로 설정하도록 한다. 따라서, 모바일 플랫폼 내부적으로 'Plugin' 속성과 또 다른 구분이 가능하게 한다.
또한, 대기화면 어플리케이션 구동시 'Plugin' 속성에 추가적으로 'Idle' 속성을 추가하여 'Plugin' 이면서 대기화면 어플리케이션인 경우를 구분 할 수 있다.
도 12는 종래의 대기화면 어플리케이션 화면 처리와 본 발명의 실시예에 따른 대기화면 어플리케이션 화면 처리를 비교 설명하기 도면이다. 여기서, 도 12(a)는 종래의 대기화면 어플리케이션의 플러시(flush) 메커니즘을 나타내고 도 12(b)는 본 발명의 실시예에 따른 대기화면 어플리케이션의 플러시 메커니즘을 나타낸다.
도 12(a)에 따르면, 대기화면 어플리케이션(popup)의 화면 처리는 부모(parent) 어플리케이션인 APM 모듈이 액디브즐렛('ActiveJlet')인 경우에만 이루어진다. 즉. 대기화면 어플리케이션의 'Frame Buffer'를 모바일 플랫폼의 'Default Frame Buffer'에 복사한다. 그리고 모바일 플랫폼은 'HAL Component'을 통해 'Default Frame Buffer'에 대해 화면 갱신을 요청한다.
여기서, 'ActiveJlet'은 플랫폼 내부에서 한 개의 'Jlet'만 'ActiveJlet' 이 될 수 있으며 모바일 플랫폼 내에서 존재하는 시스템 어플리케이션 및 일반 상용 어플리케이션들이 모두 'ActiveJlet' 이 될 수 있다. 어플리케이션이 'ActiveJlet' 이 되는 경우 해당 'ActiveJlet'은 화면을 모두 점유한다. 즉 자신의 'FrameBuffer'를 그대로 화면에 플러시 할 수 있다. 이때, 대기화면 어플리케이션이 화면 갱신을 시도하는 시점에 부모 어플리케이션이 'ActiveJlet' 이어야 한다. 즉 APM 모듈(APM 모듈이 대기화면 어플리케이션의 부모 어플리케이션임)이 'ActiveJlet' 이어야 한다. 만약 부모 어플리케이션이 'ActiveJlet' 이 아니면 화면 갱신은 이루어지지 않는다.
도 12(b)에 따르면, 대기화면 어플리케이션은 일반 'Jlet' 속성을 가지므로 대기화면 어플리케이션의 화면 처리 방식은 일반 'Jlet' 형태와 동일하게 대기화면 어플리케이션의 'Frame Buffer'를 그대로 출력한다. 즉 종래에 대기화면 어플리케이션의 'Frame Buffer'를 모바일 플랫폼의 'Default Frame Buffer'에 복사하는 과정이 없다. 이와 같이, 대기화면 어플리케이션의 'FrameBuffer'를 직접 플러시하여 화면처리 과정의 단순화 및 속도를 빠르게 한다.
대기화면 어플리케이션이 활성화될 경우 해당 대기화면 어플리케이션을 'ActiveJlet' 으로 변경하여 화면 갱신이 이루어질 경우 'Plugin' 속성을 가지고 있더라도 'ActiveJlet' 이 자기 자신인 경우는 일반 'Jlet'의 화면 갱신과 마찬가지로 어플리케이션의 'Frame Buffer'를 바로 'Flush HAL'을 통해 갱신할 수 있도록 한다.
팝업 매니저를 통해 대기화면에 설정된 특정 대기화면 어플리케이션이 포어그라운드(foreground) 팝업이 되는 경우, 매니저 모듈은 'ActiveJlet'을 APM 모듈로 변경한다. 그리고 팝업 매니저를 종료시킨다. 팝업 매니저가 정상적으로 종료되면 매니저 모듈은 대기화면 관리 모듈에게 대기화면 어플리케이션을 포어그라운드로 설정 요청한다. 그리고 정상적으로 설정이 된 경우 'ActiveJlet'을 대기화면 어플리케이션으로 변경한다. 이럴 경우, 'ActiveJlet'으로 설정된 APM 모듈은 멈춤(pause)처리되고 포어그라운드 팝업이 재시작되며 활성화된다.
또한, 대기화면 어플리케이션이 활성화되어 'ActiveJlet'이 된 상태에서 OEM으로부터 취소키가 전달되면, 대기화면 어플리케이션은 'IdleJlet'의 'setMAState' 파라미터를 통해 대기화면 상태를 비활성화로 변경한다. 그리고 매니저 모듈은 'ActiveJlet'을 APM 모듈로 변경한다. 단, 'ActiveJlet'으로 변경할 어플리케이션은 APM 모듈의 스케쥴링에 따라 최상위 어플리케이션으로 변경한다. 도 13을 참조하여 이러한 대기화면 어플리케이션의 플러시 과정을 설명한다.
도 13은 본 발명의 실시예에 따른 대기화면 어플리케이션의 플러시 과정을 나타낸 순서도이다. 즉 대기화면 관리 모듈의 대기화면 플러시(flush) 과정을 나타낸다.
도 13에 따르면, 대기화면 관리 모듈은 플러시할(S101) 어플리케이션의 속성이 'Plugin' 인지를 판단한다(S103). 이때, 'Plugin' 인 경우로 판단되면 플러시할 어플리케이션의 속성이 'IdleJlet' 인지를 판단한다(S105). 이때, 'IdleJlet' 이 아닌 경우로 판단되면 부모 어플리케이션(parents)이 'ActiveJlet' 인지를 판단한다(S107).
이때, 'ActiveJlet'이 아닌 경우 절차를 종료한다. 그러나 'ActiveJlet' 인 경우로 판단되면, 'btrans'가 'true'인지를 판단한다(S109). 이때, 'true' 인 경우로 판단되면, 부모 어플리케이션의 'Frame Buffer'의 투명을 'Default Frame Buffer'에 복사한다(S111). 그리고 플러시할 어플리케이션의 'Frame Buffer'를 'Default Frame Buffer'에 복사(S113)하고 'Default Frame Buffer'를 플러시한다(S115). 그러면, OEM 모듈은 'Default Frame Buffer'로 화면 갱신을 한다(S117).
한편, S105 단계에서 플러시할 어플리케이션의 속성이 'IdleJlet' 로 판단된 경우, 플러시할 어플리케이션이 'ActiveJlet' 이거나 또는 부모 어플리케이션이 'ActiveJlet' 인지를 판단한다(S119). 이때, 플러시할 어플리케이션 또는 부모 어플리케이션이 'ActiveJlet' 인 경우로 판단되면, 플러시할 어플리케이션의 'Frame Buffer'를 플러시한다(S121). 그러면, OEM 모듈은 플러시할 어플리케이션의 'Frame Buffer'로 화면 갱신을 한다(S123).
이때, 플러시할 어플리케이션 및 부모 어플리케이션이 'ActiveJlet'이 아닌 경우는 플러시 절차를 종료하여 화면 갱신을 하지 않는다.
또한, S103 단계에서 플러시할 어플리케이션의 속성이 'Plugin' 로 판단된 경우, 플러시할 어플리케이션이 'ActiveJlet' 인지를 판단한다(S125). 이때, 'ActiveJlet' 로 판단되면, 플러시할 어플리케이션의 자식 어플리케이션(ChildApp)이 존재하는지를 판단한다(S127). 이때, 자식 어플리케이션이 존재하는 경우로 판단되면, 플러시할 어플리케이션의 'Frame Buffer'를 'Default Frame Buffer'에 복사한다(S129). 그리고 플러시할 어플리케이션의 자식 어플리케이션의 'Frame Buffer'를 'Default Frame Buffer'에 복사한다(S131). 그리고 S115 단계로 돌아가 그 이후의 단계를 수행한다.
이때, S127 단계에서 플러시할 어플리케이션의 자식 어플리케이션이 존재하지 않는 경우로 판단되면, 플러시할 어플리케이션의 'Frame Buffer'를 플러시(S133)하고 OEM 모듈은 플러시할 어플리케이션의 'Frame Buffer'로 화면 갱신을 한다(S135).
다음, 도 14는 종래의 대기화면 어플리케이션의 키(key) 이벤트 구조와 본 발명의 실시예에 따른 대기화면 어플리케이션의 키(key) 이벤트(event) 구조를 비교 설명하기 도면이다. 즉 도 14(a)는 종래의 대기화면 어플리케이션의 키 이벤트 구조를 나타내고 도 14(b)는 본 발명의 실시예에 따른 대기화면 어플리케이션의 키 이벤트 구조를 나타낸다. 모바일 플랫폼에서의 키 처리는 'ActiveJlet'에게 전달되는 것이 원칙이다.
도 14(a)에 보인 바와 같이, 종래에는 OEM 모듈에서 키 이벤트가 전달되면 모바일 플랫폼의 이벤트디스패쳐(EventDispatcher)에서 현재 'ActiveJlet'의 이벤트 큐(EventQueue)에 키 이벤트를 적재한다. 그리고 대기화면 어플리케이션의 부모 어플리케이션인 APM 모듈을 통하여 해당되는 대기화면 어플리케이션에게 키 이벤트가 전달되도록 한다. 즉 대기화면 어플리케이션이 활성화된 경우 'ActiveJlet'은 대기화면 어플리케이션의 부모 어플리케이션인 APM 모듈이 'ActiveJlet'이 되고 해당 키 이벤트를 APM 모듈이 받아 대기화면 어플리케이션에게 전달 하도록 한다.
도 14(b)에 따르면, 본 발명의 실시예에 따른 대기화면 어플리케이션은 자신이 'ActiveJlet' 되므로, 직접 키 이벤트를 전달받는다. 이벤트디스패쳐는 OEM 모듈에서 키 이벤트가 전달되면 해당하는 대기화면 어플리케이션에게 직접 키 이벤트를 전달한다.
즉 대기화면에 설정된 어플리케이션이 활성화될 경우 'ActiveJlet'은 대기화면 어플리케이션이고 이후 키 이벤트는 APM 모듈에서 그랩(Grab)한 Key(종료 Key)를 제외하고는 모든 키가 직접 대기화면 어플리케이션에게 전달된다.
또한, 대기화면 어플리케이션이 현재 단말의 Idle에 설정이 되어 있는 경우 즉 해당 대기화면 어플리케이션이 비활성화 되어 있을 경우 즉 APM 모듈이 'ActiveJlet'이 되는 경우에는 종래와 같이 키 이벤트를 APM 모듈이 받아 전달한다.
한편, 본 발명의 실시예에서는 모바일 플랫폼에서 제공하는 대기화면 외에 대기화면 서비스를 추가할 수 있도록 확장 실행 컨텐츠를 이용하여 대기화면 서비스를 제공한다. 확장 실행 컨텐츠의 경우 'Jlet'을 상속받아 처리되는 것이 일반적이나, 본 발명의 실시예에서는 확장 실행 컨텐츠가 'IdleJlet'을 상속받게 한다.
도 15는 본 발명의 실시예에 따른 대기화면 어플리케이션 구동 방법을 나타낸 순서도이다.
도 15에 보인 바와 같이, 대기화면 관리 모듈은 어플리케이션 식별자(appID)가 WIPI 어플리케이션인지 즉 모바일 플랫폼에 기본 정의된 어플리케이션인지를 판단(S201)한다. 이때, WIPI 어플리케이션인 경우로 판단되면, 실행 파라미터를 설정(S203)하여 실행 심볼을 조회(S205)한 후, 커널 모듈에게 요청(kernel.execute)하여 어플리케이션이 실행되도록 한다(S207).
한편, S201 단계에서 WIPI 어플리케이션이 아닌 경우로 판단되면 어플리케이션 식별자의 핸들러를 조회하여 핸들러 식별자를 확인한다(S209). 즉 확장 실행 컨텐츠로 구동 가능한지를 확인한다. 구동 가능한 경우로 확인되면, 실행 파라미터를 설정(S211)하여 실행 심볼을 조회(S213)한 후, 커널 모듈에게 요청하여 대기화면 설정을 요청한 컨텐츠의 핸들러가 구동되도록 한다(S215). 확장 실행 컨텐츠용 대기화면 어플리케이션 구동시 해당 컨텐츠를 실행할 핸들러는 'IdleJlet'을 상속받은 WIPI 어플리케이션으로 기존 확장 실행 컨텐츠의 기능에 대기화면 속성이 추가된다.
또한, 확장 실행 컨텐츠용 대기화면 어플리케이션의 경우는 스케쥴링 등의 처리가 모두 대기화면 어플리케이션과 같은 방식으로 처리되도록 한다.
이상에서 설명한 본 발명의 실시예는 장치 및 방법을 통해서만 구현이 되는 것은 아니며, 본 발명의 실시예의 구성에 대응하는 기능을 실현하는 프로그램 또는 그 프로그램이 기록된 기록 매체를 통해 구현될 수도 있으며, 이러한 구현은 앞서 설명한 실시예의 기재로부터 본 발명이 속하는 기술분야의 전문가라면 쉽게 구현할 수 있는 것이다.
이상에서 본 발명의 실시예에 대하여 상세하게 설명하였지만 본 발명의 권리범위는 이에 한정되는 것은 아니고 다음의 청구범위에서 정의하고 있는 본 발명의 기본 개념을 이용한 당업자의 여러 변형 및 개량 형태 또한 본 발명의 권리범위에 속하는 것이다.
도 1은 종래의 모바일 플랫폼 구조를 나타낸다.
도 2는 종래 모바일 플랫폼의 바이너리 구조를 나타낸다.
도 3a는 종래 모바일 플랫폼의 패키지 종류를 나타내고, 도 3b는 패키지 상호 관계를 나타낸다.
도 4는 본 발명의 실시예에 따른 모바일 플랫폼의 기능 별로 모듈화된 구조를 나타낸 개념도이다.
도 5는 본 발명의 실시예에 따른 모바일 플랫폼의 프로파일 기능을 나타낸다.
도 6은 본 발명의 실시예에 따른 모바일 플랫폼의 구성도이다.
도 7은 본 발명의 실시예에 따른 커널 계층 모듈의 구조를 나타낸다.
도 8은 본 발명의 실시예에 따른 대기화면 제어 모듈의 구성을 나타낸다.
도 9a는 종래의 대기화면 어플리케이션 속성을 나타내고, 도 9b는 본 발명의 실시예에 따른 대기화면 어플리케이션 속성을 나타낸다.
도 10a는 종래 대기화면 어플리케이션의 스케줄링 관리를 나타내고, 도 10b는 본 발명의 실시예에 따른 대기화면 어플리케이션의 스케줄링 관리를 나타낸다.
도 11은 본 발명의 실시예에 따른 MG_Program 구조체의 구조를 나타낸다.
도 12a는 종래의 대기화면 어플리케이션 화면 처리를 나타내고, 도 12b는 본 발명의 실시예에 따른 대기화면 어플리케이션 화면 처리를 나타낸다.
도 13은 본 발명의 실시예에 따른 대기화면 어플리케이션의 플러시 과정을 나타낸 순서도이다.
도 14a는 종래의 대기화면 어플리케이션의 키(key) 이벤트 구조이고 도 14는 본 발명의 실시예에 따른 대기화면 어플리케이션의 키(key) 이벤트(event) 구조이다.
도 15는 본 발명의 실시예에 따른 대기화면 어플리케이션 구동 방법을 나타낸 순서도이다.

Claims (23)

  1. 모바일 플랫폼이 탑재된 이동통신 단말에 있어서,
    메모리에 상주하여 상기 모바일 플랫폼의 프로세스를 제어하는 기능들을 포함하는 커널 계층 모듈;
    상기 이동통신 단말에서 어플리케이션을 실행하기 위한 응용 프로그래밍 인터페이스 함수를 관리하는 응용 프로그래밍 인터페이스 계층 모듈; 및
    상기 커널 계층 모듈 및 상기 응용 프로그래밍 인터페이스 계층 모듈 사이에 위치하고, 상기 응용 프로그래밍 인터페이스 함수가 구현하는 기능을 수행하는 시스템 계층 모듈을 포함하고,
    상기 커널 계층 모듈, 상기 응용 프로그램 인터페이스 계층 모듈 및 상기 시스템 계층 모듈은 각각의 기능이 독립된 플랫폼 코드 바이너리 형태의 개별 모듈로 구현되는 것을 특징으로 하는 모바일 플랫폼이 탑재된 이동통신 단말.
  2. 제1항에 있어서,
    상기 독립된 플랫폼 코드 바이너리 형태의 개별 모듈은,
    하나의 동적인 라이브러리로 구성되지 않는 기능들로 상기 모바일 플랫폼을 세분화하고, 세분화된 기능들을 상기 개별 모듈로서 구현하는 것을 특징으로 하는 모바일 플랫폼이 탑재된 이동통신 단말.
  3. 제1항에 있어서,
    상기 독립된 플랫폼 코드 바이너리 형태의 개별 모듈은,
    서로 다른 모듈 간에 상대 모듈이 제공하는 기능을 참조하기 위한 인터페이스를 제공하고, 상기 인터페이스는 상대 모듈이 자신이 제공하는 기능을 사용할 수 있도록 자신이 제공하는 함수를 출력하기 위한 모듈 출력 인터페이스 및 상대 모듈이 제공하는 기능을 사용하기 위해 상기 상대 모듈이 제공하는 함수를 입력받기 위한 모듈 입력 인터페이스를 포함하는 것을 특징으로 하는 모바일 플랫폼이 탑재된 이동통신 단말.
  4. 제1항에 있어서,
    상기 독립된 플랫폼 코드 바이너리 형태의 개별 모듈은,
    하위 또는 동등 모듈의 함수 참조가 있는 경우 참조 부분을 클래스 내부 함수로 구현하거나 또는 참조 받는 클래스를 입력 또는 출력 인터페이스로 형성하여 실제 기능을 구현하는 구현체와 입력 또는 출력 인터페이스를 분리하고 입력 또는 출력 인터페이스 클래스들로만 구성된 파일을 형성하여 라이브러리 모듈을 컴파일하고 실제 구현은 상기 구현체를 통해 실행하여 하위 계층 또는 동등 계층에 속하는 모듈 간에는 함수 참조가 제한되는 것을 특징으로 하는 모바일 플랫폼이 탑재된 이동통신 단말.
  5. 제1항에 있어서,
    상기 독립된 플랫폼 코드 바이너리 형태의 개별 모듈을 기 정의된 기준에 따라 분류하여, 분류된 복수의 상기 개별 모듈들로 구성된 프로파일 단위로 패키징되어 단말 사양 별로 선별적 기능 탑재가 가능한 모바일 플랫폼이 탑재된 이동통신 단말.
  6. 제1항 내지 제5항 중 어느 한 항에 있어서,
    상기 커널 계층 모듈은,
    모바일 플랫폼 고유의 기능을 수행하는 수행하는 코어 모듈;
    운영체제가 지원하는 쓰레드(Thread)를 활용하기 위해 지정된 쓰레드 모듈;
    상기 독립된 플랫폼 코드 바이너리 형태의 개별 모듈 각각의 모듈 정보를 관리하고 로딩되는 상기 개별 모듈의 라이프 사이클을 관리하는 모듈 매니저; 및
    하드웨어에 따라 구성이 달라지는 코드 정보를 포함하는 타겟 모듈
    을 포함하는 모바일 플랫폼이 탑재된 이동통신 단말.
  7. 제6항에 있어서,
    상기 코어 모듈, 상기 쓰레드 모듈, 상기 모듈 매니저 및 상기 타겟 모듈 중 어하나의 모듈은,
    각 모듈이 제공하는 전역 변수 및 함수를 인터페이스로 구현하고 구현된 인터페이스 목록을 포함하는 헤더 정보를 상대 모듈에게 제공하고, 각 모듈 내부 함수를 은닉화하여 모듈 간의 상호 참조를 제한하는 것을 특징으로 하는 모바일 플랫 폼이 탑재된 이동통신 단말.
  8. 제6항에 있어서,
    상기 코어 모듈, 상기 쓰레드 모듈, 상기 모듈 매니저 및 상기 타겟 모듈 중 어느 하나의 모듈은,
    상기 시스템 계층 모듈에 포함되어 있는 함수를 내부 함수로 구현하고, 하드웨어 프로파일에 지정된 기능 함수의 호출하지 않도록 설정하며, DRM(Digital Rights Management) 파일 처리 및 플랫폼 환경 설정 파일 처리를 위한 함수의 포인터를 전달받아 사용하여 상기 시스템 계층 모듈의 함수, 전역 변수를 호출하여 사용하는 디펜던시를 제거하는 것을 특징으로 하는 모바일 플랫폼이 탑재된 이동통신 단말.
  9. 제6항에 있어서,
    상기 시스템 계층 모듈은,
    상기 커널 계층 모듈에 포함되어 있는 그래픽 엔진 코드가 분리되어 상기 독립된 플랫폼 코드 바이너리 형태의 개별 모듈로 구현된 그래픽 모듈을 포함하고,
    상기 그래픽 모듈이 제공하는 기능을 분류하여 다른 모듈에서 사용 가능한 인터페이스로 구현하고, 상기 그래픽 모듈에서 참조하는 커널 기능의 함수, 전역 변수를 상기 커널 계층 모듈에서 출력 인터페이스로 구현하는 것을 특징으로 하는 모바일 플랫폼이 탑재된 이동통신 단말.
  10. 제9항에 있어서,
    상기 그래픽 모듈은,
    HAL(Hardware Abstraction Layer) 인터페이스로 구현된 시스 디코더의 응용 프로그래밍 인터페이스를 사용하는 것을 특징으로 하는 모바일 플랫폼이 탑재된 이동통신 단말.
  11. 제6항에 있어서,
    상기 커널 계층 모듈, 상기 응용 프로그램 인터페이스 계층 모듈 및 상기 시스템 계층 모듈 중 어느 하나의 모듈은,
    상기 독립된 플랫폼 코드 바이너리 형태의 개별 모듈로 구현된 대기화면 점유 기능을 관리하는 대기화면 제어 모듈을 포함하고,
    상기 대기화면 제어 모듈은,
    대기화면 설정, 해제, 설치된 대기화면 어플리케이션의 관리, 구동중인 대기화면 관리, 팝업 관리 및 대기화면 어플리케이션의 자동 스케줄링을 포함하는 대기화면 어플리케이션에 관한 제어 및 관리를 수행하는 대기화면 관리 모듈;
    대기화면 설정이 필요한 시점에 상기 대기화면 관리 모듈에게 대기화면 어플리케이션 처리를 요청하는 매니저 모듈;
    상기 매니저 모듈이 상기 대기화면 어플리케이션 처리를 위해 요청하는 인터페이스를 제공하는 모듈 인터페이스부; 및
    상기 대기화면 관리 모듈이 대기화면 어플리케이션 처리를 위해 모바일 플랫폼 정보를 획득하고 상기 매니저 모듈이 요청한 대기화면 어플리케이션 처리 결과를 제공하기 위한 인터페이스를 제공하는 플랫폼 인터페이스부
    를 포함하는 모바일 플랫폼이 탑재된 이동통신 단말.
  12. 제11항에 있어서,
    상기 대기화면 어플리케이션은,
    상기 대기화면 어플리케이션의 베이스 클래스('IdleJlet')가 일반 어플리케이션의 속성('Jlet')을 직접 상속받아 독립된 어플리케이션 형태로 구현된 것을 특징으로 하는 모바일 플랫폼이 탑재된 이동통신 단말.
  13. 제12항에 있어서,
    상기 대기화면 관리 모듈은,
    상기 대기화면 어플리케이션이 활성화되는 경우, 상기 대기화면 어플리케이션을 'ActiveJlet'으로 변경하여 상기 대기화면 어플리케이션의 프레임 버퍼를 그대로 플러시하는 것을 특징으로 하는 모바일 플랫폼이 탑재된 이동통신 단말.
  14. 제13항에 있어서,
    상기 대기화면 어플리케이션은,
    'ActiveJlet'으로 설정되어 키 이벤트를 직접 전달받는 구조로 이루어지는 것을 특징으로 하는 모바일 플랫폼이 탑재된 이동통신 단말.
  15. 제14항에 있어서,
    상기 대기화면 관리 모듈은,
    확장 실행 컨텐츠 핸들러와 연동하여 모바일 플랫폼에서 제공하는 대기화면 어플리케이션 외에 추가된 대기화면 어플리케이션을 관리하는 것을 특징으로 하는 모바일 플랫폼이 탑재된 이동통신 단말.
  16. 이동통신 단말에 탑재되어 어플리케이션의 실행 환경을 제공하는 모바일 플랫폼의 동작 방법에 있어서,
    상기 이동통신 단말이 부팅되면 커널 계층 모듈이 모바일 플랫폼 동작에 필요한 기본 모듈들을 로딩하여 모바일 플랫폼을 초기화하고, 어플리케이션 수행 관리 모듈을 구동시키는 단계;
    상기 어플리케이션 수행 관리 모듈의 제어하에 실행된 어플리케이션이 응용 프로그래밍 인터페이스 계층 모듈이 제공하는 해당되는 응용 프로그래밍 인터페이스 및 상기 응용 프로그래밍 인터페이스를 구현하는 시스템 계층 모듈을 호출하는 단계; 및
    상기 시스템 계층 모듈이 상기 커널 계층 모듈에게 하드웨어 적응 계층 인터페이스 호출을 요청하여 상기 실행된 어플리케이션이 제공하는 기능을 구현하는 단계를 포함하고,
    상기 모바일 플랫폼은 메모리에 상주하여 상기 모바일 플랫폼의 프로세스를 제어하는 상기 커널 계층 모듈, 상기 이동통신 단말에서 어플리케이션을 실행하기 위한 응용 프로그래밍 인터페이스 함수를 관리하는 응용 프로그래밍 인터페이스 계층 모듈 및 상기 커널 계층 모듈 및 상기 응용 프로그래밍 인터페이스 계층 모듈 사이에 위치하여 상기 응용 프로그래밍 인터페이스 함수가 구현하는 기능을 수행하는 시스템 계층 모듈로 계층화되고, 상기 커널 계층 모듈, 상기 응용 프로그램 인터페이스 계층 모듈 및 상기 시스템 계층 모듈은 각각의 기능이 독립된 플랫폼 코드 바이너리 형태의 개별 모듈로 구현된 구조로 이루어지는 것을 특징으로 하는 모바일 플랫폼의 동작 방법.
  17. 제16항에서,
    상기 구동시키는 단계는,
    상기 이동통신 단말이 부팅되는 경우, 상기 모바일 플랫폼의 오이엠(OEM) 계층 모듈이 상기 커널 계층 모듈의 모듈 매니저-여기서 모듈 매니저는 상기 개별 모듈들의 모듈 정보 및 라이프 사이클을 관리하는 모듈임-를 로딩하여 HAL 인터페이스 포인터를 전달하는 단계;
    상기 모듈 매니저가 상기 HAL 인터페이스 포인터를 통해 필요한 HAL 응용 프로그램 인터페이스를 검색하는 단계; 및
    상기 모듈 매니저가 상기 모바일 플랫폼 동작에 필요한 기본 모듈들을 로딩하고 모바일 플랫폼을 초기화하고, 상기 어플리케이션 수행 관리 모듈을 구동시켜 단말 부팅 작업을 완료하는 단계
    를 포함하는 모바일 플랫폼의 동작 방법.
  18. 제17항에서,
    상기 호출하는 단계는,
    상기 실행된 어플리케이션이 해당 기능을 구현하기 위한 응용 프로그래밍 인터페이스를 호출하는 단계; 및
    상기 시스템 계층 모듈이 상기 실행된 어플리케이션이 호출한 응용 프로그래밍 인터페이스를 구현하는 기능 모듈을 로딩하는 단계
    를 포함하는 모바일 플랫폼의 동작 방법.
  19. 제18항에 있어서,
    상기 구현하는 단계는,
    상기 모듈 매니저가 상기 호출한 응용 프로그래밍 인터페이스를 구현하는 기능 모듈의 로딩 여부를 판단하는 단계;
    상기 호출한 응용 프로그래밍 인터페이스를 구현하는 기능 모듈이 로딩되지 않은 경우, 상기 모듈 매니저가 상기 기능 모듈을 로딩하는 단계;
    로딩된 상기 기능 모듈이 상기 모듈 매니저에게 하드웨어 적응 계층 인터페이스 호출을 요청하는 단계; 및
    상기 모듈 매니저가 상기 오이엠 계층 모듈에게 상기 하드웨어 적응 계층 인 터페이스를 호출하여 상기 실행된 어플리케이션이 제공하는 기능을 구현하는 단계
    를 포함하는 모바일 플랫폼의 동작 방법.
  20. 이동통신 단말의 대기화면 어플리케이션 관리 방법에 있어서,
    대기화면에 설정된 대기화면 어플리케이션이 포어그라운드(foreground) 팝업이 되는 경우, 액티브즐렛(activeJlet)-여기서 액티브즐렛(activeJlet)은 화면 점유를 위해 필요한 설정 파라미터로서 액티브즐렛(activeJlet)으로 설정된 어플리케이션은 화면을 점유하게 됨-을 어플리케이션 수행 관리 모듈로 변경하고 팝업 매니저를 종료시키는 단계;
    상기 대기화면 어플리케이션을 포어그라운드로 설정하고 액티브즐렛(activeJlet)을 대기화면 어플리케이션으로 변경하는 단계; 및
    변경된 상기 대기화면 어플리케이션이 활성화되면, 대기화면 어플리케이션의 프레임 버퍼를 플러시하여 상기 프레임 버퍼로 화면 갱신이 이루어지게 하는 단계
    를 포함하는 대기화면 어플리케이션 관리 방법.
  21. 제20항에 있어서,
    상기 화면 갱신이 이루어지게 하는 단계 이후,
    대기화면 취소키가 수신되는 경우, 상기 대기화면 어플리케이션의 상태를 비활성화로 변경하고, 상기 액티브즐렛(activeJlet)을 상기 어플리케이션 수행 관리 모듈로 변경하는 단계
    를 더 포함하는 대기화면 어플리케이션 관리 방법.
  22. 이동통신 단말의 대기화면 어플리케이션 관리 방법에 있어서,
    실행 요청된 어플리케이션이 모바일 플랫폼에 정의된 어플리케이션이 아닌 경우, 확장 실행형 컨텐츠로 구동 가능한지 여부를 판단하는 단계; 및
    확장 실행형 컨텐츠로 구동 가능한 경우로 판단되면, 커널 계층 모듈에게 요청하여 해당되는 확장 실행형 컨텐츠 핸들러-여기서 확장 실행형 컨텐츠 핸들러는 상기 모바일 플랫폼에 정의된 어플리케이션 형태임-를 구동하여 상기 실행 요청된 어플리케이션이 확장 실행형 컨텐츠 형태로 실행되도록 하는 단계
    를 포함하는 대기화면 어플리케이션 관리 방법.
  23. 제22항에 있어서,
    상기 판단하는 단계는,
    상기 실행 요청된 어플리케이션 상기 모바일 플랫폼에 정의된 어플리케이션인지를 판단하는 단계;
    상기 모바일 플랫폼에 정의된 어플리케이션인 경우, 상기 커널 계층 모듈에게 요청하여 상기 실행 요청된 어플리케이션를 실행하는 단계; 및
    상기 모바일 플랫폼에 정의된 어플리케이션이 아닌 경우, 상기 실행 요청된 어플리케이션의 식별자의 핸들러를 조회하여 확장 실행형 컨텐츠로 구동 가능한지 여부를 판단하는 단계
    를 포함하는 대기화면 어플리케이션 관리 방법.
KR1020090020379A 2009-03-10 2009-03-10 기능별로 모듈화된 구조로 이루어진 모바일 플랫폼이 탑재된 이동통신단말, 그 모바일 플랫폼의 동작 방법 및 대기화면 어플리케이션 관리 방법 KR101083090B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020090020379A KR101083090B1 (ko) 2009-03-10 2009-03-10 기능별로 모듈화된 구조로 이루어진 모바일 플랫폼이 탑재된 이동통신단말, 그 모바일 플랫폼의 동작 방법 및 대기화면 어플리케이션 관리 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020090020379A KR101083090B1 (ko) 2009-03-10 2009-03-10 기능별로 모듈화된 구조로 이루어진 모바일 플랫폼이 탑재된 이동통신단말, 그 모바일 플랫폼의 동작 방법 및 대기화면 어플리케이션 관리 방법

Publications (2)

Publication Number Publication Date
KR20100101933A true KR20100101933A (ko) 2010-09-20
KR101083090B1 KR101083090B1 (ko) 2011-11-16

Family

ID=43007244

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020090020379A KR101083090B1 (ko) 2009-03-10 2009-03-10 기능별로 모듈화된 구조로 이루어진 모바일 플랫폼이 탑재된 이동통신단말, 그 모바일 플랫폼의 동작 방법 및 대기화면 어플리케이션 관리 방법

Country Status (1)

Country Link
KR (1) KR101083090B1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014176243A1 (en) * 2013-04-23 2014-10-30 Clearblade, Inc. System and method for creating a development and operational platform for mobile applications
KR101632152B1 (ko) * 2015-08-11 2016-06-21 숭실대학교산학협력단 모바일 플랫폼 동적 분석 방지 장치 및 그 방법

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100683061B1 (ko) 2005-10-27 2007-02-15 주식회사 케이티프리텔 모바일 플랫폼의 수정없이 신규 모바일 기능을 추가하는 방법, 이를 적용한 모바일 장치 및 컴퓨터로 판독가능한 기록매체

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014176243A1 (en) * 2013-04-23 2014-10-30 Clearblade, Inc. System and method for creating a development and operational platform for mobile applications
US9038015B1 (en) 2013-04-23 2015-05-19 Clearblade, Inc. System and method for creating a development and operational platform for mobile applications
US9274763B2 (en) 2013-04-23 2016-03-01 Clearblade, Inc. System and method for creating a development and operational platform for mobile applications
US9934003B2 (en) 2013-04-23 2018-04-03 Clearblade, Inc. System and method for creating a development and operational platform for mobile applications
KR101632152B1 (ko) * 2015-08-11 2016-06-21 숭실대학교산학협력단 모바일 플랫폼 동적 분석 방지 장치 및 그 방법

Also Published As

Publication number Publication date
KR101083090B1 (ko) 2011-11-16

Similar Documents

Publication Publication Date Title
US20030074487A1 (en) Dynamic operating system
US6349408B1 (en) Techniques for implementing a framework for extensible applications
US6915511B2 (en) Dynamic class reloading mechanism
US8060856B2 (en) Native objects accessible by platform neutral API
CA2768752C (en) Terminal device of non-android platform for executing android applications, and computer readable recording medium for storing program of executing android applications on non-android platform
US8490070B2 (en) Unified mobile platform
US7814472B2 (en) System and method for shared code-sourcing in a Java Virtual Machine environment
US8739147B2 (en) Class isolation to minimize memory usage in a device
US20070257715A1 (en) System and method for abstract configuration
US20040268301A1 (en) Adding new compiler methods to an integrated development environment
WO2012119139A2 (en) Application compatibility with library operating systems
US20090249311A1 (en) Sharing a native module of compiled code using an abstraction module of interpreted code in a virtual machine environment
US8201189B2 (en) System and method for filtering components
US7293267B1 (en) System and method for performing speculative initialization of application models for a cloned runtime system process
US8838750B2 (en) System and method for system information centralization
EP1290554B1 (fr) Systeme informatique modulaire et procede associe
US7219341B2 (en) Code analysis for selective runtime data processing
CN111857765A (zh) 用于药物设计系统的插件系统及其生成方法和更新方法
CN112363728B (zh) 一种支持持续集成构建的跨平台编译方法及系统
KR101083090B1 (ko) 기능별로 모듈화된 구조로 이루어진 모바일 플랫폼이 탑재된 이동통신단말, 그 모바일 플랫폼의 동작 방법 및 대기화면 어플리케이션 관리 방법
Polakovic et al. Building reconfigurable component-based OS with THINK
WO2021129853A1 (zh) 移动服务升级方法、装置和终端
KR20100052494A (ko) Ｓｉｐ 및 ｓｄｐ 프로토콜을 고객화하는 사용자 동시 실행 루틴 인터페이스
CN117472462A (zh) 插件运行方法、装置、桌面操作系统、电子设备
KR101058932B1 (ko) 플랫폼 액티베이터를 포함하는 모바일 플랫폼이 탑재된 이동통신단말 및 그 동작 방법

Legal Events

Date Code Title Description
A201 Request for examination
N231 Notification of change of applicant
E902 Notification of reason for refusal
E90F Notification of reason for final refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20171101

Year of fee payment: 7

FPAY Annual fee payment

Payment date: 20181031

Year of fee payment: 8