Why is NDK so hobbled?

[J Decker]

I understand a lot of limitations that are imposed on NDK; but forcing non use of wide character support?  That means even if I didn't get a 0 from reading the key event, I couldn't do useful things with the text....

I just need 1 wide character function... vsnwprintf() but then I read that it doesn't behave sanely anyway (doesn't provide a way to measure the buffer size); and if you have a "%s" does that mean character or wide input?  I think somewhere it's %S for unicode and %s is still character, so format strings have to be parametric; which they do for 64/32 bit support but I diverge.

There is no place to write files... 'and we don't intend to add one'...  which means one has to craft a vfs through java ....  so any solution you have is flimsy at best... and sometimes I can create files and sometimes I can't... I think if I pass the full path sometimes I can't write to files... but I can read them (some platform)

what's the hate for providing a stable platform like windows always has been that supports binary distributions?  There's not a whole lot of processors in the world... and I don't think that 20 new ones (really new, not just extended) will appear in the in the next 100 years.

The current state of getting key text would appear that even android can't get the key text; but I went to another application and proved that wrong... so why is it documented for me to use a way that isn't the right way anyway?  Oh; maybe it is, maybe it's exactly the same, but the keymap that's been loaded is hobbled?  ( something like the display size being a lie when not selecting a SDK version; which I can't imagine would have made sense in any context )

I saw a library ... something... that provides some of the library functions; is the C runtime linked statically?  CrystaX  https://www.crystax.net/en/android/ndk

And Gestures... why isn't there a simple source to take some gestures and compute things like 'swiped left' ... I understand that ideally one would want to consider a whole glyph... which is then a lot of data to consider.... 

Maybe just working out some definitions; like what's the difference between putting your finger to press a button and to do a swipe gesture? I guess inputs come in reasonbly quick... so if you want 3 single touches in the same place then start as a 'click' sort of event maybe it's the other way around... but then there's tolerances of how much motion is still 'here'...

I saw a gesturedetector.h something, but it led to nowhere useful... http://stackoverflow.com/questions/15161857/gesturedetector-inside-nativeactivity

and none of this will change.. it's a requirement to be bug compatible with the past... 

I know internally there's freetype and sqlite; why can't we use those versions instead of floating 2M of code that everyone already has?

- Letters written, never meaning to send.... 

[silly...@gmail.com]

On Wednesday, April 16, 2014 7:01:14 PM UTC-5, J Decker wrote:

[snip]

This is the reason that I do not write any Android applications. I took one look at the NDK description and knew better than to waste my precious time trying to remove restrictions that never should have existed in the first place.

I am waiting for a smartphone that runs Standard Linux so that I can write a standard C++ application for it.

[Nalin Savara]

Hi J Decker (aka Silly...@gmail.com),

(1) What are links to some of your apps and what specifically have you not been able to do ?

Maybe the group can help-- disadvantage of other "Full Linux" mobiles is that their installed base is nowhere comparable to Android-- 50 million+ Galaxy S4 phones sold; NOR is their hardware comparable to latest and greatest Android devices (Note3 has 3 GB of RAM!!!)

About Complete Linuxes on Mobile:

 

(2) Such a "smartphone that runs standard linux" already exists-- in the form of Nokia N9 (running Meego) and Sailfish's phones running Meego and which use QT.

Google for "Sailfish Meego QT"-- and you will find it.

Tizen also intends to build on the same Meego codebase-- but in this case with a mostly HTML5 centric face to user.

(3) Blackberry 10 is 100% POSIX compliant-- more than any smartphone platform till now.

And they are good--- I could actually run vi ; and even JDK on the Nokia N900-- and N9 and N950 are 2 steps ahead even of the N900!!! And Sailfish... is far, far ahead even of those....

Hope this helps...  

Regards,

Nalin

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at http://groups.google.com/group/android-ndk.
For more options, visit https://groups.google.com/d/optout.

[J Decker]

(1) What are links to some of your apps and what specifically have you not been able to do ?

Maybe the group can help-- disadvantage of other "Full Linux" mobiles is that their installed base is nowhere comparable to Android-- 50 million+ Galaxy S4 phones sold; NOR is their hardware comparable to latest and greatest Android devices (Note3 has 3 GB of RAM!!!)

Links to apps; they're under development, I have a link to the platform... https://code.google.com/p/c-system-abstraction-component-gui/

I can be more concise.

1) unicode input from the keyboard without implementing my own keyboard

2) swnprintf; wchar.h without sarcastic comments....

3) a place to write files

items a-f such as the builtin libraries that are hidden ; I dunno it's really a self extending application and is it's own shared core so... that's not really a deal; but I guess there's no shared packages (extensions and multiple packages are really just as separate as any other, though they overlap themselves.

 

About Complete Linuxes on Mobile:

I liked WebOS (kinda) but that died too; it has an insignificant market share... 

[silly...@gmail.com]

On Tuesday, April 22, 2014 4:09:25 AM UTC-5, n.s wrote:

(1) What are links to some of your apps and what specifically have you not been able to do ?

The fact that you are asking me this question is the crux of the problem. :) What I want to do should be my business. [My tone is not rude when I say this. I really appreciate your help.]

For example, suppose that I have 1,000,000 clients. If I decide to write an application that does dangerous things to the hard disk of my clients' computers, I do not have to call Microsoft. The decision of what to do to the computers is between me and my client.

This is the problem with Android: even though the customer owns the phone, the decision of what should be done with the phone is not between me and that customer. It is between me, Google, and the customer. There should be an OS where it is, again, between me and the customer.

 

Maybe the group can help-- disadvantage of other "Full Linux" mobiles is that their installed base is nowhere comparable to Android-- 50 million+ Galaxy S4 phones sold; NOR is their hardware comparable to latest and greatest Android devices (Note3 has 3 GB of RAM!!!)

This is true of course. However , the reason is not because Android is so much better than the alternative. The reason is that there has not been no alternative. Also, there is quite a bit of vendor lock-in in the market. Everyone knows that there are certain US telephone companies who will not sell phones that are not locked down. That is one of the reason that You do not see "Full Linux" devices in the US - the phone companies refuse to sell them because they are afraid that someone will figure out a way to bypass the cell towers and just use the phones. Google does not interfere with this model because having a phone locked-down with Android actually benefits Google (advertising, search snooping, App Store).

At some point, however, this will change. Sailfish, or some other company, will provide a "Full Linux" phone, developers will be free from the Java straight-jacket, and there will be a snow-ball effect. Sailfish is trying, but as I said, the phone companies in USA refuse to sell the phones. 

About Complete Linuxes on Mobile:

 

(2) Such a "smartphone that runs standard linux" already exists-- in the form of Nokia N9 (running Meego) and Sailfish's phones running Meego and which use QT.

Google for "Sailfish Meego QT"-- and you will find it.

Tizen also intends to build on the same Meego codebase-- but in this case with a mostly HTML5 centric face to user.

(3) Blackberry 10 is 100% POSIX compliant-- more than any smartphone platform till now.

And they are good--- I could actually run vi ; and even JDK on the Nokia N900-- and N9 and N950 are 2 steps ahead even of the N900!!! And Sailfish... is far, far ahead even of those....

I guess we will have to wait for Sailfish to become widely available.

-Silly Stack 

[Hak Matsuda]

Hi J Decker,

For the issues that you pointed out, 

>1) unicode input from the keyboard without implementing my own keyboard

Would you give some more detail? Which part is broken specifically?

>2) swnprintf; wchar.h without sarcastic comments....

In libC++ in NDK r9d, whar.h and swprintf work for me. It doesn't have a locale support yet but %s, %S that you mentioned work.

Could you try if that meet your requirement?

>3) a place to write files

With correct manifest privilege settings, you can read/write with standard APIs. Please refer, 

http://stackoverflow.com/questions/11294487/android-writing-saving-files-from-native-code-only

thanks,

hak

--

[Nalin Savara]

Hi J-Decker (Silly...@gmail.com),

To add to Hak Matsuda's already cool answer; answering your doubts/comments below:-

(1) Native Unicode

(2) Read and write files (using only fread/fwrite ; and fprintf/fscanf ; and also the c++ io funcs)

(3) Cross platform graphics API.

--->>> I used Android-QT and later cocos2d-x ---  both are c++ frameworks-- and for my first 1 year+ of Android development-- I didnt even learn the basics of Android Java UI etc-- and got by ok.

Infact; I even won Samsung's S-Pen App Development contest in 2012 organized by Samsung USA and AngelHack--- with a app that used only Android QT (which at the time was not as mature as it is now).

So, I think you need to dig deeper and look into your own heart about what you wanna do....

Regards,

Nalin

--

[J Decker]

On Wed, Apr 23, 2014 at 10:05 AM, 'Hak Matsuda <hak...@google.com>' via android-ndk <andro...@googlegroups.com> wrote:

Hi J Decker,

For the issues that you pointed out, 

>1) unicode input from the keyboard without implementing my own keyboard

Would you give some more detail? Which part is broken specifically?

http://stackoverflow.com/questions/21124051/receive-complete-android-unicode-input-in-c-c

any non ascii character comes back as 0, either from  AKeyEvent_getKeyChar(event); or from diving into java and getting the character from the java libraries with the keyevent passed back and built in-full.

 

>2) swnprintf; wchar.h without sarcastic comments....

In libC++ in NDK r9d, whar.h and swprintf work for me. It doesn't have a locale support yet but %s, %S that you mentioned work.

Could you try if that meet your requirement?

http://stackoverflow.com/questions/5630255/does-android-not-really-have-wchar-t

https://code.google.com/p/android/issues/detail?id=20567

seems I wasn't including wchar.h where I thought; and I was only using r9

which does contain the comment 

----

/* IMPORTANT: Any code that relies on wide character support is essentially

 *            non-portable and/or broken. the only reason this header exist

 *            is because I'm really a nice guy. However, I'm not nice enough

 *            to provide you with a real implementation. instead wchar_t == char

 *            and all wc functions are stubs to their "normal" equivalent...

 */

-----

so... I to assume assume that since this comment is gone, all libc.so on all devices also magically updated to not be stub functions?

 

>3) a place to write files

With correct manifest privilege settings, you can read/write with standard APIs. Please refer, 

http://stackoverflow.com/questions/11294487/android-writing-saving-files-from-native-code-only

Yes, I know that's what the suggestion is; but that place does not behave the same on all platforms.  On one, it failed to make a file  './files/tmp/.shared.procreg '

and all I did was change ./files/tmp/.shared to ./files/tmp.shared  and it worked... it had previously worked on the 3 or 4 other devices I tried.

Although I was able to write other directories and other files in other directories, and there's no difference in how I created it; or even the thread that created the files that failed.

[J Decker]

On the topic of wchar.h working...

this bit of code should be a self contained sort of example

declare a wchar buffer, fill it with known data (this case characters, yes they are not wide) 

then use swprintf into the buffer

then examine the resulting buffer as binary and character data.

-------

{

wchar_t buf[32];

strcpy( (char*)buf, "abcdefghijklmn" );

swprintf( buf, 32, L"%s", L"some_name" );

{

char tmpmsg[256];

int chars;

int ofs;

ofs = snprintf( tmpmsg, 256, "binary(w):" );

for( chars = 0; chars < 32; chars++ )

ofs += snprintf( tmpmsg + ofs, 256 - ofs, "%02x ", ((char*)buf)[chars] );

__android_log_print( ANDROID_LOG_INFO, "org.d3x0r.sack.xxxx", tmpmsg );

ofs = snprintf( tmpmsg, 256, "in the beginning(w):" );

for( chars = 0; chars < 32; chars++ )

ofs += snprintf( tmpmsg + ofs, 256 - ofs, "%c", (buf)[chars] );

__android_log_print( ANDROID_LOG_INFO, "org.d3x0r.sack.xxxx", tmpmsg );

}

}

 

-------

resulting output

I/org.d3x0r.sack.xxxx(29629): in the beginning(w):61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 00 00 30 80 0f 40 00 00 00 00 04 20 0f 40 03 00 00 00 

I/org.d3x0r.sack.xxxx(29629): in the beginning(w):aeim0

notice the buffer contains the initial 'abcdef' data and not anything die character

[Hak Matsuda]

Hi J Decker,

Thanks for providing comments & sample code.

1) Unicode keyboard input, I will take a look later.

2) Regarding swprintf(),

By changing swprintf() either

      swprintf( buf, 32, L"%s", "some_name" );

or

      swprintf( buf, 32, L"%S", L"some_name" );

I'm seeing a correct output as below.

>I/com.sample.teapot( 3774): in the beginning(w):some_name?P?P(?t`P?$?@?

I'm using libC++ with r9d, to use libC++, in Applicatoin.mk, you need to specify:

APP_STL := c++_static

Does that work for you?

3) It looks like a bug in a specific device's implementation and need to be covered by CTS.

I suppose there would be an area that need to be improved in terms of CTS test coverage, especially in NDK area.

thanks!

hak

[J Decker]

2) Regarding swprintf(),

By changing swprintf() either

      swprintf( buf, 32, L"%s", "some_name" );

or

      swprintf( buf, 32, L"%S", L"some_name" );

neither %s or %S worked for me or %ls  

I had changed the format to %08x instead and the buffer was still unchanged.

(samsung galaxy s3)

I started at a slightly later point i use wcstombs and mbstowcs  which appear to be more like a character copy... my first buffer was garbled, and I finally tracked it back to swprintf which was the first error.

 

I'm seeing a correct output as below.

>I/com.sample.teapot( 3774): in the beginning(w):some_name?P?P(?t`P?$?@?

I'm using libC++ with r9d, to use libC++, in Applicatoin.mk, you need to specify:

APP_STL := c++_static

I'm not linking any c++ libraries to this library.... and no STL... does that also change a flag to link to libc.a somehow?  

Here I'm out of scope since I'm using cmake... maybe there's something amiss in my toolchain file

 

http://www.softpedia.com/progChangelog/Android-NDK-Changelog-131993.html (r9d)

Fixed libc.so so it does not export atexit() and __do_handler. These symbols are exported for ARM builds by the system version of the C library to support legacy native libraries. NDK-generated should never reference them directly. Instead, each shared library or executable should embed its own version of these symbols, provided by crtbegin_*.o. If your project is linked with the -nostdlib -Wl,--no-undefined options, you must provide your own __dso_handle because crtbegin_so.o is not linked in this case. 

(android-14)  hiding libc.so so there is only a libc.a results in mulitple defintion of 'atexit' in libc.a previously in crtbegin_so.o; which I think I need... while searching noticed a patch note that may apply; same link error in r9 

the command line is something like.... (ie, these are the only libraries I specify)

gcc ...  -lstdc++ -lgnustl_static -shared -lm   -o libdoughnut.so ....(objects)

looks like libc.a can only be used as a 'static executable' 

https://android.googlesource.com/platform/development/+/master/ndk/platforms/README.CRT.TXT

Does that work for you?

thanks!

    " 

[J Decker]

Decided to work on this again.  Apparently NDK doesn't store the getCharacters from the key event.

https://github.com/android/platform_frameworks_base/blob/master/core/jni/android_view_KeyEvent.cpp

Never references mCharacters.  So the key string just isn't in the event given to NDK applications.

You can add 'implements KeyEvent.Callback to your native activity 

public class @activity@ extends NativeActivity implements KeyEvent.Callback  {

}

And implement 

  public boolean onKeyMultiple (int keyCode, int count, KeyEvent event)

  {  /* get unicode data from event.getCharacters() */ }

and forward that into the application.

I haven't tested it yet; but I assume this will work for old platforms.

[J Decker]

...and it doesn't work on old platforms.
Not sure when it was changed, but same package on platform-14 does not
get any of the events. which will make using both methods
interchangably more difficult.