im trying to compare these two dll files but i dont reall know how to
I use this app.
http://www.ultraedit.com/index.php?name=Content&pid=34
I also recommend the free (!) WinDiff, on which I've elaborated in depth at http://discussion.brighthand.com/showthread.php?t=215073
hmm i like the ultraedit but it makes the dlls look all wierd. maybe its supposed to be like that.
my problem is that the dll bta2dp.dll from tornado makes the a2dp work. and the bta2dp.dll from treo 750v does allow it to work.
i feel this file is necessary but i dont know the differances
I presume that's a typo because as I read it, both dll's allow your application to work?
I don't understand the problem, if you have have one that works then isn't that the solution? I don't get what you're trying to achieve. DLL's are composed of functions which are dynamically linked to at runtime from the application code. If the parameters passed from the application to the function in the DLL differ from one version to another, or the return information is different then that's the reason why one works and the other doesn't.
Unless you have the programming skill to debug the procedure as it is entered and subsequently change it then there's nothing that you're going to be able to do other than compare version numbers of the files but since you have already found one that works, what's the issue?
David.
(Now I've noticed you try to compare binary files - windiff is only usable for comparing textual ones. Sorry.)
As everyone who has been trying the new ROM (or even looking at the screen captures) knows, the UI has been changed significantly. Since most of the providers don't plan on making 6.5 backwards compatible, this isn't a major problem for most users. We aren't most users: So THANK YOU to our chefs.
Anyway, there are a number of UI changes. Some I've figured out, some I have questions on. I'd love to keep a running list, if that makes sense. I'm also happy to move this post elsewhere or acknowledge someone else's work. (I did search.)
So, here is my list thus far. I'm happy to have links to additional information on any of these topics.
Touch. The touch-based actions feel much better. (I get the impression from reading XDA and other forums that AT&T limited access to some of these touch actions. With the "cooked" rom's, this goes away.) The faster I slide my finger, the faster the scrolling in long pages or lists of contacts. It's not perfect, as I sometimes find myself intending to scroll and getting a click instead. (This is not different from before.) On the browser (and other apps?), flick-scrolling gives you any angle, rather than strickly up/down or left/right. I would like a tutorial for all the touch actions, though.
Home page. This is quite variable. The default seems to be CHome, which has large text/graphic bars for each element on CHome. I like that each gives underlying status when they are the selected bar, and then you can go into them further of course: email, friends, weather, etc. Many of the CHome apps have a scrolling functionality that give you additional access without having to open the underlying application. CHome is modifiable with a special editor, called CHome Editor and located in various locations, depending on the build. This lets you set which bars show up on the list and where they are located. (It would be nice if this linked to the Today settings editor and visa versa.) As usual, there are many home page options, and one more graphical option is Manila2D / TouchFLO2D (possibly a standard option). It also takes some getting used to.
Start list. Rather than a simple list, this is now the hexagonal grid of icons. I've seen a number of people say this is a direct response to the iPhone icon / application list. While it may be easier to view, I don't like the UI and lack of flexibility here. I keep forgetting where things like the Photo Album are. My current ROM has three different places to find "settings" type of tools, and there is no way (that I can see) to move things between groupings and explicitly set what icons I want where.
Internet Explorer has a much better experience - mostly. It operates full screen, and a double-tap will zoom into a readable area. (I think it actually zooms into an underlying html section, which I find comforting.) I don't understand why IE seems to shut down when I have only OK'd out to the home screen (not closed it). Big question: on a web page with a data entry field, why won't the text entry area scroll with my typing? Other question: Should I use a different browser?
FYI: The keyboard map for function keys is different than the default for the AT&T Tilt. This can be fixed by following this thread: http://forum.xda-developers.com/showthread.php?t=334911
Camera: The camera has never been anything to write home about, but it seems to have gotten worse. I see a thread on the main section for the Kaiser that talks about a new camera app that looks a lot like the one that comes with WM6.5 (http://forum.xda-developers.com/showthread.php?t=355587). Question: Is there any chance to improve the the options and operation of the camera?
Feedback welcomed.
Jack Vinson
Phone: 8925 / Kaiser
Current setup:
SPL: 3.29
ROM: RPC_Elite_V9 WWE
Radio: 1.59.46.12
Protocol: 25.89.30.08H
While working on a ROM (for the hero), I have recently tried to do some theming by small changes (i.e. color changes) to the drawables in the framework-res.apk.
It appears the both for me, and the fellow that is helping me (floomat), these 9-patch files are giving a headache. We prefer editing them in some normal app (i.e. photoshop) but this seems to mess up the 9-patch "code".
I have written a very small program to apply the changes to a 9-patch image without disturbing the 9-patch itself. Note that this program is mainly meant as a "proof of concept" and hopefully one of the apk managing tools will pick up the ball and integrate it. In the meantime it might be useful even as it is (with some scripting around it most likely). Or it might be just a way to prove I am fool and there is simpler way to get around this I am not familiar with
"Program" and source: http://www.sendspace.com/file/sw4atc
(its really too small and simple to be called a program)
Usage:
Code:
java copy9patch original.9.png changed.png
Will copy the changes made to the changed.png over to the original.9.png but keep the 9-patch data of the original.9.png.
Its code (also included) and the way it works is very simple: It takes the size of the original image (i.e. 19x27), without the 1 pixel border with the 9-patch codes - so in our example it will be 17x25. Now it just copied the center 17x25 pixels from the changed.png over the original's center pixels. It has some very basic boundary conditions if the image sizes do not match but this could probably be handled better, possibly just by issuing an error in these cases.
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
NOTE: I feel a bit uncomfortable posting this in the "G1 development" section but I see both apktool and apk manager are here....
erasmux said:
While working on a ROM (for the hero), I have recently tried to do some theming by small changes (i.e. color changes) to the drawables in the framework-res.apk.
It appears the both for me, and the fellow that is helping me (floomat), these 9-patch files are giving a headache. We prefer editing them in some normal app (i.e. photoshop) but this seems to mess up the 9-patch "code".
I have written a very small program to apply the changes to a 9-patch image without disturbing the 9-patch itself. Note that this program is mainly meant as a "proof of concept" and hopefully one of the apk managing tools will pick up the ball and integrate it. In the meantime it might be useful even as it is (with some scripting around it most likely). Or it might be just a way to prove I am fool and there is simpler way to get around this I am not familiar with
"Program" and source: http://www.sendspace.com/file/sw4atc
(its really too small and simple to be called a program)
Usage:
Code:
java copy9patch original.9.png changed.png
Will copy the changes made to the changed.png over to the original.9.png but keep the 9-patch data of the original.9.png.
Its code (also included) and the way it works is very simple: It takes the size of the original image (i.e. 19x27), without the 1 pixel border with the 9-patch codes - so in our example it will be 17x25. Now it just copied the center 17x25 pixels from the changed.png over the original's center pixels. It has some very basic boundary conditions if the image sizes do not match but this could probably be handled better, possibly just by issuing an error in these cases.
NOTE: I feel a bit uncomfortable posting this in the "G1 development" section but I see both apktool and apk manager are here....
Click to expand...
Click to collapse
Huh. I've been wondering if this was possible. I haven't tried this yet but if it works, nicely done! I think that this would be a huge improvement and addition to the themeporter programs that are out there. There is a high demand for this in that area and in the area of HDPI>MDPI/MDPI>HDPI conversion. I'm certainly bookmarking this!
Awesome, just checked out ur source, so simple but effective
Anyway wanted to ask if ur ok with me incorporating it into theme-porter ? Link
Wht im thinking is perhaps when "Hdpi to mdpi" is on, it would resize the .9.pngs by 66%, after which it would transfer the .9 data using this program so (9-patch) code is preserved.
Let me know. Thnx
FYI : Just gave it a whirl, works perfectly.
Daneshm90 said:
Awesome, just checked out ur source, so simple but effective
Anyway wanted to ask if ur ok with me incorporating it into theme-porter ? Link
Wht im thinking is perhaps when "Hdpi to mdpi" is on, it would resize the .9.pngs by 66%, after which it would transfer the .9 data using this program so (9-patch) code is preserved.
Let me know. Thnx
FYI : Just gave it a whirl, works perfectly.
Click to expand...
Click to collapse
Maybe my original post wasn't blunt enough, my code is just "proof of concept" because I am bit lazy in this department (themeing tools) - I'd rather spend my time compiling kernels (go figure ).
So my main goal for this post is for developers of apk managing tools and etc. to pick up the ball and go forward with this
And to be even clearer:
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
(am also adding this to the main post)
Regarding your actual resizing idea, you might want to resize it with the 9-patch "codes" (in the 1-pixel border) because you want the codes from your original HDMI files just resized. This should work, just be careful with resizing algorithms which average pixels and such. If I understand correctly the edge pixels should be either white or black (defining stretchable and context areas). Need to play around with this until it works well.
Let me know if I can be of any further assistance.
erasmux said:
Maybe my original post wasn't blunt enough, my code is just "proof of concept" because I am bit lazy in this department (themeing tools) - I'd rather spend my time compiling kernels (go figure ).
So my main goal for this post is for developers of apk managing tools and etc. to pick up the ball and go forward with this
And to be even clearer:
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
(am also adding this to the main post)
Regarding your actual resizing idea, you might want to resize it with the 9-patch "codes" (in the 1-pixel border) because you want the codes from your original HDMI files just resized. This should work, just be careful with resizing algorithms which average pixels and such. If I understand correctly the edge pixels should be either white or black (defining stretchable and context areas). Need to play around with this until it works well.
Let me know if I can be of any further assistance.
Click to expand...
Click to collapse
Hmm k i'll spend more time with it, perhaps the resizing program im using causes mishaps. Currently when i resize it completely messes stuff up even though the resolution corresponds to a mdpi device.
I'll do the good ol' trial/error n let u know. Thanks for the (proof of concept)
Edit :
Ok so upon using ur code for transferring images of diff sizes u can obviously tell whts up
So one improvement im thinking off, is if the images differ in size, it could draw the border and eliminate anything outside it. Ugh gotta brush up on my java though :S
bump
10 del al char har
bump
I tested it out and it works great! Thanks!
I really hope someone takes this idea and runs with it! If I knew how to code, I would certainly look into this. Maybe I can get one of the Vibrant Devs to look at this....
erasmux said:
While working on a ROM (for the hero), I have recently tried to do some theming by small changes (i.e. color changes) to the drawables in the framework-res.apk.
It appears the both for me, and the fellow that is helping me (floomat), these 9-patch files are giving a headache. We prefer editing them in some normal app (i.e. photoshop) but this seems to mess up the 9-patch "code".
I have written a very small program to apply the changes to a 9-patch image without disturbing the 9-patch itself. Note that this program is mainly meant as a "proof of concept" and hopefully one of the apk managing tools will pick up the ball and integrate it. In the meantime it might be useful even as it is (with some scripting around it most likely). Or it might be just a way to prove I am fool and there is simpler way to get around this I am not familiar with
"Program" and source: http://www.sendspace.com/file/sw4atc
(its really too small and simple to be called a program)
Usage:
Code:
java copy9patch original.9.png changed.png
Will copy the changes made to the changed.png over to the original.9.png but keep the 9-patch data of the original.9.png.
Its code (also included) and the way it works is very simple: It takes the size of the original image (i.e. 19x27), without the 1 pixel border with the 9-patch codes - so in our example it will be 17x25. Now it just copied the center 17x25 pixels from the changed.png over the original's center pixels. It has some very basic boundary conditions if the image sizes do not match but this could probably be handled better, possibly just by issuing an error in these cases.
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
NOTE: I feel a bit uncomfortable posting this in the "G1 development" section but I see both apktool and apk manager are here....
Click to expand...
Click to collapse
Can U just tell how to use this code for bulk images?????
pratyush.creed said:
Can U just tell how to use this code for bulk images?????
Click to expand...
Click to collapse
Hmm, haven't used this for a very long time and don't really remember whats going on here.
Still attached is the version which I have on my HD, and it does support bulk images if all the images are in a folder.
If I remember correctly (mostly going by the help that is displayed by running the program without argument):
Code:
fixResPngs drawable-mdpi drawable-mdpi.org
Will go over all drawable-mdpi/*.png files (possibly also sub dirs?! I really have no idea, sorry), and "fix" each such file. If I am not mistaken it needs a "reference" file only for 9 patch files which are identified by their ".9.png" suffix (regular pngs I think are just rewritten without any change which I found improves compatibility). In case of a 9 patch file, the original file with exactly the same name should be found under the directory given in the second argument. For example: If drawable-mdpi/aaa.9.png is processed the 9-patch data will be copied from drawable-mdpi.org/aaa.9.png.
Obviously it also still works on single files. It does *not* work on lists of files or lists of directories.
If anyone is interested in the code, I am sure I have it somewhere (I hope)....
erasmux said:
Hmm, haven't used this for a very long time and don't really remember whats going on here.
Still attached is the version which I have on my HD, and it does support bulk images if all the images are in a folder.
If I remember correctly (mostly going by the help that is displayed by running the program without argument):
Code:
fixResPngs drawable-mdpi drawable-mdpi.org
Will go over all drawable-mdpi/*.png files (possibly also sub dirs?! I really have no idea, sorry), and "fix" each such file. If I am not mistaken it needs a "reference" file only for 9 patch files which are identified by their ".9.png" suffix (regular pngs I think are just rewritten without any change which I found improves compatibility). In case of a 9 patch file, the original file with exactly the same name should be found under the directory given in the second argument. For example: If drawable-mdpi/aaa.9.png is processed the 9-patch data will be copied from drawable-mdpi.org/aaa.9.png.
Obviously it also still works on single files. It does *not* work on lists of files or lists of directories.
If anyone is interested in the code, I am sure I have it somewhere (I hope)....
Click to expand...
Click to collapse
Gr8 work...u made themin a kid's job
Sent from my GT-S5670 using XDA Premium App
???
does the original still work cause im on windows 7 64 bit and i was able to copy the changes to original but not it makes no changes at all, so the original file doesnt get the changes...
please help!!
BEFORE YOU POST HERE - Keep in mind this is now a DEV thread and only those with a glimpse of DEV knowledge should be posting.
There is other thread with the same subject open to everybody discuss it.
Please, this thread isn't related to VOIP, SIP calls or Tethering and
It's only to 3G version of Nexus 7.
What do you think is the possibility of us getting this function guys, even if its not officially supported.
I've seen it built in on the 7" samsung galaxy tab 2.
http://www.youtube.com/watch?v=wZ9RN...t=HL1351349133
At the moment we know:
1- The chipset Intel (Infineon) XMM6260 is built-in on Nexus 7 3G (the same chipset is in that rather long list of phones). It means no hardware limitations.
http://forum.xda-developers.com/showthread.php?p=34386544&highlight=6260#post34386544
http://pdadb.net/index.php?m=specs&i...exus_7_3g_32gb
http://forum.xda-developers.com/show....php?t=1483053
it also the same controller is in the following devices
- Lava XOLO X900 [Phone]
- Lenovo K800 [Tablet/Pad]
- LG-P920 (LG ?) [Phone]
- LG-P925 (LG Optimus 3D?) [Phone]
- Huawei E369 (3G Hi-Universe) [USB 3G Modem]
- Huawei MU733/MU739 [PC/CE Module]
- Samsung Galaxy Nexus (I9200) [Phone]
2- SMS texting works perfectely with the native mms.apk but MMS messages crash the app (missed mms APN + framework parameters?)
http://forum.xda-developers.com/showthread.php?t=1998702&page=4
3- Modified framework-res.apk (by modifying bools.xml entry to name="config_voice_capable">true) shows up the native dialer (phone.apk) on the UI
JB 4.2 http://forum.xda-developers.com/showthread.php?t=1958686&page=12
JB 4.2.1 http://forum.xda-developers.com/showpost.php?p=34736932&postcount=314
4- When placing calls trough the native dialer (phone.apk) with Skype app installed, it shows up a white menu asking "Do you want to complete this action using..." the options are "Mobile data" (w/ phone.apk blue icon) or "Skype" (w/ skype icon) and "Always" or "Just Once" (perhaps there is missing a "Phone" profile (or APN) as an option too)
5- If Skype is chosen, the call is complete and everything goes well, but if "Mobile data" is chosen, we get a single sound (bip) and the call is not complete.
6- Changing the DPI to 320 in build.prop file allow us to add a SIP account (SIP calls using native dialer is now possible), DPI could be restored after SIP account settings done.
http://forum.xda-developers.com/showthread.php?p=34752693&highlight=320#post34752693
Detailed informations come from the thread in XDA developers at:
http://forum.xda-developers.com/showthread.php?t=1958686
--------------------------------------------------------
UPDATE 5th Dec 2012 by Synman
ok, I hacked NetworkPolicyManager and am no longer crashing. Network time appears to be non-functional for the time-being. Network status is a little wonky too ... even though I have a good network signal the network icon never switches from gray to blue.
MMS send/receive is fully functional (with the exception of screwed up timestamps)
Pulled down master AOSP branch
Pulled down grouper binaries
working with grouper device
Modified device.mk
- use init.tilapia.rc
- use tilapia overlay
- remove SimpleSMS
- remove ro.carrier=wifi_only
Modified full-grouper.mk
- ref full_base_telephony in place of full_base
- added full apns
Modified device-common.mk
- added gsm permission
system.prop
replaced ref to libril-icera with libxgold
tilapia overlay
- removed single apn rules
- set voice-enabled
- added mms values
NetworkPolicyManager
- removed call to time.getMaxPeriod
I tried to make a summary of the whole work on the previous thread assuming it will be much more productive.
If someone has a suggestion to the OP please let me know and I change it to keep more updated as possible.
te framework linked above is for 4.2 ROM, the 4.2.1 is on page 32 ; http://forum.xda-developers.com/showpost.php?p=34736932&postcount=314
I've done a bit more digging within the 4.2.1 source and until we have the device specific portions of the build we are going to keep struggling.
Everything I'm seeing comes back to the framework.
I'm currently focusing on getting a build of Mms.apk bypassing framework and, while slow and tedious, I'm making progress.
My current line of thinking (open to discussion, please) is that the framework hooks we need are simply missing in our build.
Keep in mind this is now a DEV thread and only those with a glimpse of DEV knowledge should be posting.
Sent from my Galaxy Nexus using Tapatalk 2
I'm wondering if the parameters in line 40 have anything to do with it.
https://android.googlesource.com/de...rameworks/base/core/res/res/values/config.xmlhttps://android.googlesource.com/de...rameworks/base/core/res/res/values/config.xml
TinTin said:
I'm wondering if the parameters in line 40 have anything to do with it.
https://android.googlesource.com/device/asus/tilapia/+/bead144d1ca3f10e5ea7a93c58b35d6bc0630f80/overlay/frameworks/base/core/res/res/values/config.xml
Click to expand...
Click to collapse
Oooh Lines 183-184 are even more interesting:
Code:
<!-- This device is not "voice capable"; it's data-only. -->
<bool name="config_voice_capable">false</bool>
Or is this the variable you guys already used to enable the dialer? And that's all it does?
Yeah, we've already hacked that one... Its how we got the native dialer.
#3 in OP
Sent from my Galaxy Nexus using Tapatalk 2
Synman said:
Yeah, we've already hacked that one... Its how we got the native dialer.
Click to expand...
Click to collapse
What about line 40? Did you try changing parameters yet? to like
Code:
<item>"mobile,0,1,1,-1,true"</item>
Or other combinations.
I haven't compared them to a galaxy nexus framework yet. Is that where those came from?
Synman said:
I haven't compared them to a galaxy nexus framework yet. Is that where those came from?
Click to expand...
Click to collapse
Oh, nevermind. The Mako (Nexus 4) has the same values
0,0,0,-1,truefor "item" mobile in it's 4.2.1 config.xml, so this is not it I guess.
TinTin said:
Oh, nevermind. The Mako (Nexus 4) has the same values
0,0,0,-1,truefor "item" mobile in it's 4.2.1 config.xml, so this is not it I guess.
Click to expand...
Click to collapse
I found a thread elsewhere that could contain (parts) of the solution. Looking at the config.xml of the Mako (Nexus 4) and comparing it to the one of tilapia I see these parameters missing (line 40 ff.)
Code:
<item>"mobile_mms,2,0,2,60000,true"</item>
<item>"mobile_fota,10,0,2,60000,true"</item>
<item>"mobile_ims,11,0,2,60000,true"</item>
<item>"mobile_cbs,12,0,2,60000,true"</item
Please someone try adding them to the string-array of network-attributes (I don't have the decompiler yet). They definitely should be there. This might not be all yet though.
Those values might be connected with Verizon APN settings.
System Infrastructure
APN Manager by 81 Square -- Has a list of APNs for USA, Canadian and European mobile operators, plus you can type in your own. I enabled Verizon Internet (choices are CBS, FOTA, IMS, Internet). No visible effect. Power cycled the phone. Didn't help.
Click to expand...
Click to collapse
http://www.math.ucla.edu/~jimc/moto-droid3/apps.shtml
They appear here, too.
http://pastebin.com/NFGMVi2a
Here are the relevant Galaxy Nexus maguro values:
Code:
<string-array name="networkAttributes">
<item>wifi,1,1,1,-1,true</item>
<item>mobile,0,0,0,-1,true</item>
<item>mobile_mms,2,0,2,60000,true</item>
<item>mobile_supl,3,0,2,60000,true</item>
<item>mobile_dun,4,0,3,60000,true</item>
<item>mobile_hipri,5,0,3,60000,true</item>
<item>mobile_bluetooth,7,7,1,-1,true</item>
<item>ethernet,9,9,1,-1,true</item>
<item>wifi_p2p,13,1,0,-1,true</item>
</string-array>
<integer-array name="config_protectedNetworks">
<item>10</item>
<item>11</item>
<item>12</item>
</integer-array>
<string-array name="radioAttributes">
<item>1,1</item>
<item>0,1</item>
<item>7,1</item>
<item>9,1</item>
</string-array>
<integer-array name="config_data_usage_network_types">
<item>0</item>
<item>2</item>
<item>3</item>
<item>4</item>
<item>5</item>
<item>10</item>
<item>11</item>
<item>12</item>
</integer-array>
I found out that neither device.mk nor full_tilapia.mk inherit from a telephony package (while the Mako (Nexus4) does through the following line in full_mako.mk:
Code:
$(call inherit-product, $(SRC_TARGET_DIR)/product/full_base_telephony.mk)
This describes a similiar situation under ICS and the steps someone took to solve the problem,
this sounds like a promising way to me (The same things are missing in the Tilapia build):
http://groups.google.com/group/android-porting/msg/3a28bb754b9ba18a
now all we need are the device binaries... c'mon google
Synman said:
now all we need are the device binaries... c'mon google
Click to expand...
Click to collapse
i know, i shouldn't post here so feel free to delete my post, but are the device binaries something we just have to wait a little for google to release or are they closed source and we have to urge google to release them?
https://developers.google.com/android/nexus/drivers
only has the binaries for the grouper...
Someone wrote that the radio chipset is the same as for the galaxy nexus so shouldn't it be possible to use the gsm binaries from the galaxy nexus?
punshkin said:
i know, i shouldn't post here so feel free to delete my post, but are the device binaries something we just have to wait a little for google to release or are they closed source and we have to urge google to release them?
https://developers.google.com/android/nexus/drivers
only has the binaries for the grouper...
Someone wrote that the radio chipset is the same as for the galaxy nexus so shouldn't it be possible to use the gsm binaries from the galaxy nexus?
Click to expand...
Click to collapse
we gotta learn somehow, right?
This is the page to watch: https://developers.google.com/android/nexus/drivers
just as soon as it hits we will be able to do our own full builds and device deploys right from the master source branch.
In the meantime I've made the change inheriting telelphony to my .mk file and am in the process of making to see what all changes. I lost a ton of time today doing a maguro build hoping to salvage something from it and ultimately coming up empty.
That same line is in the maguro build. Something that I noticed is that tliapia refers to $(call inherit-product, $(SRC_TARGET_DIR)/product/full_base.mk) unlike the phones.
Have also found this at the bottom of full_base.mk
Code:
# Get everything else from the parent package
$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_no_telephony.mk)
full_base_telelphony.mk includes full_base + telephony and brings along some extra stuff for the ride such as carrier apns and voicedialer.
telelphony.mk includes Mms.apk
----
looks like that's just about everything. It's probably redundant to have both full_base_telelphony and full_base in tilapia's mk file. Probably better to just use full_base_telephony. At the very least have full_base_telephony referenced first -- comments indicate the earlier entries take precedence.
Synman said:
looks like that's just about everything. It's probably redundant to have both full_base_telelphony and full_base in tilapia's mk file. Probably better to just use full_base_telephony. At the very least have full_base_telephony referenced first -- comments indicate the earlier entries take precedence.
Click to expand...
Click to collapse
Sounds good so far. Did you go the extra bit and try what else was mentioned in the post I linked to? Adding the extra parameters (see above) to the networkAttributes string-array and checking if telephony contains:
Code:
PRODUCT_PACKAGES := \
Contacts \
ContactsProvider \
Phone \
TelephonyProvider \
UserDictionaryProvider \
Mms
PRODUCT_COPY_FILES := \
development/data/etc/apns-conf.xml:system/etc/apns-conf.xml
PRODUCT_PROPERTY_OVERRIDES := \
keyguard.no_require_sim=true \
ro.com.android.dataroaming=true
-> Clean build and build freshly
Synman said:
That same line is in the maguro build. Something that I noticed is that tliapia refers to $(call inherit-product, $(SRC_TARGET_DIR)/product/full_base.mk) unlike the phones.
Click to expand...
Click to collapse
Right, that's because most of Tilapia derives from Grouper. You'll find the same there.